[LLVMdev] llvm-objdump

Sean Silva chisophugis at gmail.com
Tue Aug 26 12:18:42 PDT 2014


On Tue, Aug 26, 2014 at 9:52 AM, Steve King <steve at metrokings.com> wrote:

> I would like to improve llvm-objdump.  However, many unit tests depend
> precisely on the current output, making the picture a little tricky.
> My experience is limited to ELF format objects, so experts in other
> formats please sanity check.
>
> Suggested changes:
> 1) Symbolize conditional branch targets.  Currently, llvm-objdump
> prints branch targets numerically regardless of -symbolize.
>
> 2) Make -symbolize the default behavior for human friendliness.
>

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.


>
> 3) Add new -bare option to suppress symbolizing.  Many unit tests will
> use -bare to preserve expected output in today's format.
>
> 4) When multiple symbols exist for a given address, print all of them.
> Today, llvm-objdump only prints the last symbol found, but symbolizes
> references with the first symbol found.  So, it's a bit of a mess.
>
> 5) When symbolizing code references, prefer matching symbols with type
> FUNC, but fall back to matches with type NOTYPE.  This matches GNU
> objdump behavior and many hand written assembly files don't specify
> .type directives anyway.
>
> How does this sound?
>

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.

Here are some suggested changes:

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.
2. Rip out the YAMLCFG stuff (including the corresponding library code)
since it seems totally borked.

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?).

-- Sean Silva


>
> Regards,
> -steve
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140826/b8d93f4f/attachment.html>


More information about the llvm-dev mailing list