<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 11, 2014 at 12:11 AM, 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Wed, Sep 10, 2014 at 8:29 PM, Sean Silva <<a href="mailto:chisophugis@gmail.com">chisophugis@gmail.com</a>> wrote:<br>
><br>
> Right, you mean like otool's -d (" Display the contents of the<br>
> (__DATA,__data) section") or -t ("Display  the contents of the<br>
> (__TEXT,__text) section.  With the -v flag, this disassembles the text.")?<br>
> ;)<br>
><br>
<br>
</span>I've never used otools, but presumably Kevin has some idea here.<br>
<br>
<br>
> What is your goal?<br>
<br>
A symbolizing disassembler with at least the possibility to tune<br>
output to match existing norms per host platform.<br>
<span class=""><br>
<br>
> From what I can gather, it seems like you just want to<br>
> make llvm-objdump's default behavior match GNU objdump, which doesn't seem<br>
> like a very good direction (how deep is the rabbit hole? why GNU objdump and<br>
> not tool or the windows one?).<br>
<br>
</span>What I personally need is a just symbolizing disassembler.  What my<br>
colleagues will expect is a fair approximation of GNU objdump because<br>
that's what they already know.  Kevin piped up early that he wanted<br>
otools style output, so we ended up at the goal above.<br>
<span class=""><br>
<br>
> I do see a lot of value in making<br>
> llvm-objdump's default output be as useful as possible; I don't see much<br>
> value in blindly making the default behavior as close to GNU objdump as<br>
> possible.<br>
<br>
</span>Right, I'm not suggesting this either.<br>
<span class=""><br>
<br>
> In fact, if we want a really high-quality output, taking GNU<br>
> objdump as a model seems like a poor idea anyway; off the top of my head I<br>
> can think of multiple ways it could be improved:<br>
><br>
> - put the symbol name at the beginning of the line (note that llvm-objdump<br>
> already gets this right!)<br>
> - have options to disassemble sub-parts of the object file (like section<br>
> ranges, or single symbols), instead of just the entire file, to avoid<br>
> wasting a bunch of time printing stuff (there have been days where my<br>
> workflow was bottlenecked on a minutes-long objdump call, when I was trying<br>
> to just get a single function...)<br>
> - do not ever wrap "raw-insn" output.<br>
> - print section offsets in a consistent format (e.g. always the same number<br>
> of digits, padding with 0's) so that they are easily searchable<br>
> - don't suck for interoperability with awk and other tools; consider this<br>
> which works fine with otool's -tv format: awk '$1 ~ /foo/ {p=1} $1 ~ /:$/ &&<br>
> $1 !~ /foo/ {p=0} p';<br>
<br>
<br>
</span>I wish I had the chops to consider this awk line :-)<br>
<span class=""><br>
<br>
>  a similar thing works for printing ranges. An<br>
> easily-digested format is very useful for doing various sorts of analyses<br>
> (instruction types, instruction length, average per-function instruction<br>
> length, stack traffic analysis, instruction size distribution, etc.).<br>
<br>
<br>
</span>I am really with you here.  I've hatched more than a few Perl scripts<br>
to chew objdump output.<br>
<span class=""><br>
<br>
> There<br>
> are many analyses that I haven't done due to GNU objdump's output format<br>
> sucking. In general, otool's output format is extremely good in this regard,<br>
> and if anything, IMO we should use *it* as a model<br>
<br>
<br>
</span>Disassemblers are down and dirty tools often needed by folks with weak<br>
software backgrounds, e.g. hardware designers.  For this crowd,<br>
elegant output matters less than dispensing with software tasks the<br>
way they already know how.  Offering familiar behavior by default is a<br>
win, but that doesn't mean we can't produce better output with a<br>
command line option, argv[0] check or whatever.<br>
<span class=""><br>
<br>
><br>
> If you have questions, please ask on IRC or the mailing lists. A solution<br>
> that doesn't make sense from the community's point of view (like a quick<br>
> hack -bare to avoid needing to look at how you are affecting tests) will get<br>
> ripped out: just recently you saw me do so for a number of objdump options.<br>
><br>
<br>
</span>Right, I'm invested in building a consensus.  I'll disagree with you<br>
that -bare is a hack -- how else will tests handle default behavior<br>
changes per platform?<br></blockquote><div><br></div><div>Don't have default behavior change per platform. Instead, have a -format=foo option (or one of Rafael's suggestions, like argv[0] checking, or simply having separate tools).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
<br>
> I recommend that you first look into changing these tests to use<br>
> -filetype=asm (where possible) so that they don't even need to use objdump<br>
> in the first place.<br>
><br>
<br>
</span>I'm trying to avoid more mission creep when I have an alternative,<br>
e.g. -bare.  This engagement is already a heck of lot bigger than when<br>
first stuck my nose in here :-)<br></blockquote><div><br></div><div>This is a fact of life for any real-world software development.</div><div><br></div><div>-- Sean Silva</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
<br>
>><br>
>>   The -bare option allows us to change output<br>
>> in purely aesthetic ways without breaking tests.<br>
><br>
><br>
> Is it worth burdening every developer in the LLVM project to remember to use<br>
> -bare in order to get consistent output for tests? We already have enough<br>
> word-of mouth poorly-documented testing "best practices" (like <%s for file<br>
> input to opt). I personally don't think that it's worth adding a new one<br>
> just "to change output in purely aesthetic ways".<br>
><br>
<br>
</span>I hear you, but again, how do we allow per platform defaults without<br>
breaking tests?  Maybe you disagree that we should have per-platform<br>
defaults?<br>
</blockquote></div><br></div></div>