Hi all,
I was giving some thought as to possible project ideas I could propose for this year’s Google Summer of Code, with regards to the LLVM Binutils. One idea that I had was something discussed at last year’s Euro LLVM developer meeting, namely machine-readable output from the LLVM Binutils. Before I actually start advertising this as an open project, I wanted to ask a few questions:
Thanks in advance for the comments!
James
_______________________________________________
LLVM Developers mailing list
llvm...@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
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)?
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?
How might this interact with obj2yaml? Could the new output ultimately be used to replace it?
Is there a priority for a specific format (e.g. ELF, DWARF, COFF)?
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?
I wonder if machine-readable output from the tools is actually the
correct approach. When I have needed something similar, for example
when parsing traces from a CPU debug interface and mapping them to
places in the object code, I have used the same underlying libraries
that these tools use in LLVM to get much richer output.
When I have done so, I have found that there is a huge amount of
boilerplate involved. I would be much more interested in moving a lot
of the logic in these tools into some higher-level (API-stable) library
abstractions (with scripting-language bindings) and then reimplementing
the tools in terms of those libraries.
If at all possible, I'd rather not use these via a serialisation format.
For example, consider the disassembly bit. There are three steps:
1. The binary encoding of the instruction.
2. The semantic decoding of the operation, the input and output
operands, including information about the kind of instruction (e.g.
branch, load, store).
3. The text representation.
A lot of the things where I've wanted machine-readable objdump output,
I've wanted part of 2. Consider this line from objdump:
16bed: 48 83 c3 01 add $0x1,%rbx
It has an address in the binary, the hex of the instruction, and the
formatted assembly for the instruction. The first two are pretty easy
to encode in something like YAML, but would the last bit be just a
string? A format string with some more explicit values? Would that be
sufficient to know that this is an operation that reads and writes %rbx,
uses a constant as another operand, and does not modify memory or
control flow?
David
Binding for scripting language sounds nice but it is often not enough to prevent the people from taking the shortcut (try to avoid building llvm or add extra dependencies, or allow them to use the language of their choice).
If you want to start working on this, I will suggest starting with something like architectures/symbol table/section info. Those are more commonly parsed by regex than some other information like disassembly.
Steven
> On Jan 14, 2020, at 3:24 AM, David Chisnall via llvm-dev <llvm...@lists.llvm.org> wrote: