<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Mon, Feb 27, 2017 at 11:47 AM Adrian Prantl <<a href="mailto:aprantl@apple.com">aprantl@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br class="gmail_msg">
> On Feb 27, 2017, at 11:13 AM, David Blaikie <<a href="mailto:dblaikie@gmail.com" class="gmail_msg" target="_blank">dblaikie@gmail.com</a>> wrote:<br class="gmail_msg">
><br class="gmail_msg">
> I tend to think it's more legible if we include the values there, even if no bytes were required to produce them. I don't generally look at the abbreviations when reading a dump & expect to see the data in the debug_info/debug_types output.<br class="gmail_msg">
<br class="gmail_msg">
I'm pretty sure we want the implicit attributes to show up in the dump (perhaps with a comment that they are implicit in the abbreviation where we normally show [DW_FORM...] in the output.<br class="gmail_msg">
<br class="gmail_msg">
Tools like llvm-dwarfdump are used by different audiences. Eventually we probably want something like a --brief mode (that could even be the default like in Darwin's dwarfdump) that just shows the high-level contents of the debug_info section without all the low-level details like forms and abbreviations, and then we could have a verbose mode that shows the actual encoding of the data. Personally, most of the times I'm using dwarfdump I typically don't care about how an attribute was encoded.<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
Side note: I don't think that this commit was really NFC.<br class="gmail_msg"></blockquote><div><br></div><div>This is most assuredly not NFC. It changes the output of text so it's definitely "functional".</div><div><br></div><div>-eric</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br class="gmail_msg">
-- adrian<br class="gmail_msg">
</blockquote></div></div>