[PATCH] D82858: [llvm-objdump] Detect note section for ELF objects

James Henderson via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Jun 30 06:28:34 PDT 2020


jhenderson added a reviewer: grimar.
jhenderson added a comment.

In D82858#2122464 <https://reviews.llvm.org/D82858#2122464>, @rochauha wrote:

> In D82858#2122431 <https://reviews.llvm.org/D82858#2122431>, @jhenderson wrote:
>
> > Could you more clearly clarify what the motivation here is? Is this working towards some missing GNU compatibility or similar? If so, could you paste an example of what GNU objdump produces, please.
> >
> > Note that .note sections can be dumped using llvm-readelf in GNU style, just not as part of the disassembly.
>
>
> GNU compatibility is not a goal here. The idea is to support disassembling everything that appears in a binary. Right now almost every entity is disassembled as instructions (even notes). This is not very helpful to the user.
>
> Let us consider the example of notes. A user has to use llvm-readobj to look at notes and then use llvm-objdump to look at instructions. There is //some// overlap between the functionality llvm-readobj and llvm-objdump as well. For example, both also support only looking at symbols. I guess this divide between both tools is not necessary.
>
> llvm-objdump is more 'feature rich' in the sense that it allows to look at target specific parts of the code as well. Right now the plan is to add some of the missing functionality to llvm-objdump. The final goal would be to support re-assemblable disassembly after we are able to disassemble all contents of a binary.
>
> At the time of writing, no mainstream tool supports re-assemblable disassembly. The ones which do are mostly proprietary.


If that's the motivation, I don't think I can support it for various reasons:

1. Having multiple tools to do the same job is not a good idea - each requires its own maintenance, the behaviour can diverge, bugs might require fixing in two places/support for new things etc etc etc. In an ideal world, we'd merge all the binary tools (GNU and LLVM) into a single tool, or redistribute functionality somehow, so that we don't have duplicate functionality like we already do. This takes us further away from that ideal.
2. Decoding the .note section in a special manner takes us further away from GNU compatibility. It's not clear to me that GNU would want to add this functionality themselves.
3. I'm not convinced people actually find dumping all sections in an interpreted form at once useful. Do you actually have any users for that? I think most people are interested in the disassembly of their code, but are unlikely to want this information in the same output as note information.
4. I don't quite follow whether you're saying that one motivation is to make things re-assembleable, but if it is, the .note section is not the place to start - there are other sections where this would be more useful (e.g. data sections).
5. I'm not sure I follow your "feature rich" comment. llvm-readelf for example has just as much access to the object as a whole and so is able to use target-specific information where appropriate (for example, it knows about various target-specific flags, can parse the target-specific attributes section etc).


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D82858/new/

https://reviews.llvm.org/D82858





More information about the llvm-commits mailing list