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

James Henderson via llvm-dev llvm-dev at lists.llvm.org
Tue Jan 14 01:59:38 PST 2020


Thanks for the comments Jordan!

On Mon, 13 Jan 2020 at 18:01, Jordan Rupprecht <rupprecht at google.com> wrote:

>
> 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"?
>
Yeah, that was my thoughts mostly, although I'd probably go with
"--output-stlye=json" or whatever, and deprecate "--elf-output-style". That
would a) avoid any weird interactions between the --elf-output-style switch
and the --machine (or whatever) switch, and b) allow other languages to be
added later if the need arose.


> 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.)
>
If we adopted YAML as the machine readable format, should there ultimately
be any difference between obj2yaml and llvm-readobj --output-style=yaml
--all? It seems to me not really, hence the thought. But maybe others have
a different overall thought on what the latter might produce.


> Is there a priority for a specific format (e.g. ELF, DWARF, COFF)?
>>
> Is DWARF support necessary since llvm-dwarfdump already exists?
>
Indeed, llvm-dwarfdump already exists, but like llvm-readobj, its output
isn't always that amenable to machine-reading (see for example --debug-line
output). Hence my question.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200114/3d25c3da/attachment.html>


More information about the llvm-dev mailing list