[llvm-dev] [RFC][binutils] Machine-readable output from Binutils - possible GSOC project?

[Jordan Rupprecht via llvm-dev]

On Fri, Jan 10, 2020 at 3:56 AM James Henderson <
jh7370.2008 at my.bristol.ac.uk> wrote:

> Are people still interested in this? If so, what is the typical use case
> you’d use the result of this project for? Why would this be better than the
> existing llvm-readobj output (if applicable)?
>
llvm-readobj produces human readable output, which is not always great for
being machine readable. json comes to mind as a more machine-parse-friendly
format, although it may not be the best one.
I'm not sure we have a need *right now* -- we have tools that parse
binutils output and work fine -- but if this tool existed, we would surely
tell people they could use it instead of trying to parse a human readable
tool for any new uses. Or if they scratch their heads trying to update a
regex that parses a binutil, tell them to switch.


> Which tool(s) and feature(s) would you most want this for? I personally
> think this should just be another output style for llvm-readobj. Does
> anybody have any different opinion there?
>
I mean... almost every single binutil this might replace (readelf, objdump,
nm, size, strings) could be described as "a program to read object files".
So a different output style for llvm-readobj sounds fine. "llvm-readobj
--machine"?

How might this interact with obj2yaml? Could the new output ultimately be
> used to replace it?
>
I see this as very separate from obj2yaml -- I view that and yaml2obj as a
1:1 mapping between object files and text; in theory you can pipe back and
forth forever and always get the same result (modulo unimportant bit
differences), whereas llvm-readobj --machine should be an inspection tool
that can be filtered/adjusted accordingly (only query certain types of
sections, only print relocations, etc.)


> Is there a priority for a specific format (e.g. ELF, DWARF, COFF)?
>
Is DWARF support necessary since llvm-dwarfdump already exists?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200113/8f91887f/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4849 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200113/8f91887f/attachment.bin>