<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Aug 26, 2014 at 9:52 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">I would like to improve llvm-objdump.  However, many unit tests depend<br>

precisely on the current output, making the picture a little tricky.<br>
My experience is limited to ELF format objects, so experts in other<br>
formats please sanity check.<br>
<br>
Suggested changes:<br>
1) Symbolize conditional branch targets.  Currently, llvm-objdump<br>
prints branch targets numerically regardless of -symbolize.<br>
<br>
2) Make -symbolize the default behavior for human friendliness.<br></blockquote><div><br></div><div>Last I checked (which admittedly was about a year ago), -symbolize had significant performance problems on large object files. If those are still present, I think you should focus on fixing them before changing the default.</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">
<br>
3) Add new -bare option to suppress symbolizing.  Many unit tests will<br>
use -bare to preserve expected output in today's format.<br>
<br>
4) When multiple symbols exist for a given address, print all of them.<br>
Today, llvm-objdump only prints the last symbol found, but symbolizes<br>
references with the first symbol found.  So, it's a bit of a mess.<br>
<br>
5) When symbolizing code references, prefer matching symbols with type<br>
FUNC, but fall back to matches with type NOTYPE.  This matches GNU<br>
objdump behavior and many hand written assembly files don't specify<br>
.type directives anyway.<br>
<br>
How does this sound?<br></blockquote><div><br></div><div>You seem to be focusing a lot on the user-visible behavior. However, I would say that a lot of the work that needs to be done is actually internal to the code; that will make adding new functionality easier.</div>
<div><br></div><div>Here are some suggested changes:</div><div><br></div><div>1. Clean up the code, improving the usability of LLVM's C++ API's as necessary. This will benefit all LLVM users of this functionality in fact. The main thing is to clarify the core logic and reduce boilerplate.</div>
<div>2. Rip out the YAMLCFG stuff (including the corresponding library code) since it seems totally borked.</div><div><br></div><div>btw, for tools that we consider as internal testing tools, there has historically been pushback for adding user-visible features if they do not serve an immediate need within the LLVM codebase (CC'ing Rafael: does llvm-objdump fall under this category?).<br>
</div><div><br></div><div>-- Sean Silva</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">
<br>
Regards,<br>
-steve<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</blockquote></div><br></div></div>