<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 10, 2014 at 3:03 PM, Steve King <span dir="ltr"><<a href="mailto:steve@metrokings.com" target="_blank">steve@metrokings.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">On Wed, Sep 10, 2014 at 2:14 PM, Sean Silva <<a href="mailto:chisophugis@gmail.com">chisophugis@gmail.com</a>> wrote:<br>
><br>
> On Wed, Sep 10, 2014 at 1:38 PM, Steve King <<a href="mailto:kingshizzle@gmail.com">kingshizzle@gmail.com</a>> wrote:<br>
>><br>
>> The -bare option keeps objdump output consistent with test expectations<br>
>> regardless of host platform.  As discussed on the list, default llvm-objdump<br>
>> output could change per host:  GNU style for Linux, otools for Apple, etc.<br>
><br>
><br>
> I think this needs some discussion in LLVMDev. I don't see the point in<br>
> slaving to reproduce the system tool's output when we don't match the<br>
> command-line options.<br>
><br>
<br>
</span>Command line mismatch is a good point.  IMHO, matching the commonly<br>
used command line knobs and typical output style would be good enough.<br></blockquote><div><br></div><div>Right, you mean like otool's -d (" Display the contents of the (__DATA,__data) section") or -t ("Display  the contents of the (__TEXT,__text) section.  With the -v flag, this disassembles the text.")? ;)</div><div><br></div><div>llvm-objdump just happens to sort of resemble GNU objdump to some extent. What is your goal? From what I can gather, it seems like you just want to make llvm-objdump's default behavior match GNU objdump, which doesn't seem like a very good direction (how deep is the rabbit hole? why GNU objdump and not tool or the windows one?). I do see a lot of value in making llvm-objdump's default output be as useful as possible; I don't see much value in blindly making the default behavior as close to GNU objdump as possible. In fact, if we want a really high-quality output, taking GNU objdump as a model seems like a poor idea anyway; off the top of my head I can think of multiple ways it could be improved:</div><div><br></div><div>- put the symbol name at the beginning of the line (note that llvm-objdump already gets this right!)</div><div>- have options to disassemble sub-parts of the object file (like section ranges, or single symbols), instead of just the entire file, to avoid wasting a bunch of time printing stuff (there have been days where my workflow was bottlenecked on a minutes-long objdump call, when I was trying to just get a single function...)</div><div>- do not ever wrap "raw-insn" output.</div><div>- print section offsets in a consistent format (e.g. always the same number of digits, padding with 0's) so that they are easily searchable</div><div>- don't suck for interoperability with awk and other tools; consider this which works fine with otool's -tv format: awk '$1 ~ /foo/ {p=1} $1 ~ /:$/ && $1 !~ /foo/ {p=0} p'; a similar thing works for printing ranges. An easily-digested format is very useful for doing various sorts of analyses (instruction types, instruction length, average per-function instruction length, stack traffic analysis, instruction size distribution, etc.). There are many analyses that I haven't done due to GNU objdump's output format sucking. In general, otool's output format is extremely good in this regard, and if anything, IMO we should use *it* as a model (unfortunately otool works in such a limited set of scenarios (basically just Mac binaries); if we could have that format with llvm-objdump's disassemble-every-object-format, every-architecture capabilities, that would be great).</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
I've helped colleagues with llvm-objdump vs. GNU objdump on one past<br>
project already and the bar isn't that high.  The -bare option at<br>
least opens the door to per-host defaults.<br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
One a practical note, analyzing llvm-objdump test failures is labor<br>
intensive and a bit nerve wracking since i'm not familiar with many of<br>
the target architectures.</blockquote><div><br></div><div>If you have questions, please ask on IRC or the mailing lists. A solution that doesn't make sense from the community's point of view (like a quick hack -bare to avoid needing to look at how you are affecting tests) will get ripped out: just recently you saw me do so for a number of objdump options.</div><div><br></div><div>I recommend that you first look into changing these tests to use -filetype=asm (where possible) so that they don't even need to use objdump in the first place.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">  The -bare option allows us to change output<br>
in purely aesthetic ways without breaking tests.</blockquote></div></div><div class="gmail_extra"><br></div><div class="gmail_extra">Is it worth burdening every developer in the LLVM project to remember to use -bare in order to get consistent output for tests? We already have enough word-of mouth poorly-documented testing "best practices" (like <%s for file input to opt). I personally don't think that it's worth adding a new one just "to change output in purely aesthetic ways".<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">-- Sean Silva</div></div>