Dropping the DW_ prefix from names in dwarfdump

Hey guys,

Frederic is introducing the expression dumping support and in the interests of tersity is skipping the “DW_” in every “DW_OP” (heck, we could even skip the “OP” given the context - nothing else textual can appear there, right?)

Any thoughts on skipping the “DW_” (maybe even the AT/TAG/FORM too) in the rest of dwarfdump? (skipping the AT/TAG (FORM would be relatively easy I think) would be a bit trickier, but still identifiable/solvable) I haven’t tried it to see how it looks/reads.

I think we should have a switchable level of verbosity. I think that the Darwin dwarfdump utility could serve as an example (at least to fuel the discussion):
Here is Darwin’s dwarfdump output with the default settings

Hey guys,

Frederic is introducing the expression dumping support and in the interests of tersity is skipping the “DW_” in every “DW_OP” (heck, we could even skip the “OP” given the context - nothing else textual can appear there, right?)

I think it always depends on what you are debugging. When I’m interested whether the encoding is correct, I think I’d prefer to have all these details in there, even if they are redundant. When I’m debugging, e.g., the source location associated with a function argument, I wouldn’t care about which Form is used to encode the information.

– adrian

Hey guys,

Frederic is introducing the expression dumping support and in the
interests of tersity is skipping the "DW_" in every "DW_OP" (heck, we could
even skip the "OP" given the context - nothing else textual can appear
there, right?)

I think it always depends on what you are debugging. When I’m interested
whether the encoding is correct, I think I’d prefer to have all these
details in there, even if they are redundant. When I’m debugging, e.g., the
source location associated with a function argument, I wouldn’t care about
which Form is used to encode the information.

Well all I was suggesting was dropping the prefixes - this wouldn't result
in any information loss, but possibly readability loss.

apart from that, I think we could drop some verbosity too - just like we
now print constants, file/directory names, without their form, etc, etc -
we could probably do the same for strings (printing out the offset in the
string table all the time is mostly excessive) and probably other types.
That would actually be a loss of information that would certainly need a
flag.

As I said in the review thread, I dropped the DW_ prefix for expressions as they can be multiple of them on the same line. I have no strong feeling one way or another for Attributes or Tags.

One of the next things I wanted to do was to drop the FORM display by default. This would actually save a lot more horizontal space than the DW_ prefixes and in my experience you nearly never need it. Of course there needs to be a flag to get it back, because ‘nearly never’ ain’t ‘never :-).

Fred

As I said in the review thread, I dropped the DW_ prefix for expressions as they can be multiple of them on the same line. I have no strong feeling one way or another for Attributes or Tags.

One of the next things I wanted to do was to drop the FORM display by default. This would actually save a lot more horizontal space than the DW_ prefixes and in my experience you nearly never need it. Of course there needs to be a flag to get it back, because ‘nearly never’ ain’t ‘never :-).

Like if you’re looking for the actual enum constant :wink:

That said, I like the ideas. I’m good with it.

Thanks!

-eric

Hear hear. DW_ adds no readability but AT_/TAG_/OP_/etc do.

Dropping the FORM entirely is fine; I view that as a mechanical encoding thing, not relevant to the informational content. If you’re debugging the encoding then it would matter, but for a random string-value attribute it really doesn’t matter which of the 3 (4?) different forms was used as long as the actual string shows up correctly.

–paulr

Hear hear. DW_ adds no readability but AT_/TAG_/OP_/etc do.

Why do you find that AT/TAG/OP adds to readability?

From the context they should be pretty clear, I hope. TAGs have offset

prefixes, attributes don't, and OPs appear inside attribute values, not at
the top level. (I think of this like HTML - tag and attribute names don't
have prefixes, they're just differentiated based on context)

Ø Why do you find that AT/TAG/OP adds to readability?

I’m usually not reading all of the dump output, I’m skimming it to find things in context, and my eye can easily pick out the uppercase TAG more easily than it can pick out a mumble_type in the middle of all that other lowercase text.

Ø From the context they should be pretty clear, I hope.

I’m not saying they add to the information content of the dump; clearly they don’t. But they do make it easier to eyeball.

–paulr