[LLVMdev] RFC: Improving our DWARF (and ELF) emission testing capabilities
eliben at google.com
Tue Jan 22 15:45:40 PST 2013
On Tue, Jan 22, 2013 at 3:35 PM, Daniel Berlin <dberlin at dberlin.org> wrote:
> On Fri, Jan 18, 2013 at 4:00 PM, Eli Bendersky <eliben at google.com> wrote:
>> Hi All,
>> While working on some recent patches for x32 support, I ran into an
>> unpleasant limitation the LLVM eco-system has with testing DWARF
>> emission. We currently have several approaches, neither of which is
>> 1. llvm-dwarfdump: the best approach when it works. But unfortunately
>> lib/DebugInfo supports only a (small) subset of DWARF. Tricky sections
>> like debug_frame aren't supported.
> Could you point out what you mean?
> In particular, what parts you think it does not support (since you say
> it supports a small subset).
> What do you want out of debug_frame, past simple parsing?
> Anything else requires real evaluation.
As I said, it doesn't support debug_frame, as one relevant example.
> I ask because I wrote a DWARF reader that google uses internally, and
> then was open sourced and contributed to google breakpad.
> (see http://code.google.com/p/google-breakpad/source/browse/trunk/src/common/dwarf/,
> in particular dwarf2reader.cc).
>> 2. Relying of assembly directive emissions (i.e. .cfi_*), which is
>> cumbersome and misses a lot of things like actual DWARF encoding.
> Err, .cfi_ and used because the encoding is tricky to get right, and
> assemblers are better at optimizing it.
> However, i'll point out that breakpad also has a CFI assembler
>> The long-term solution for DWARF would be to enhance lib/DebugInfo to
>> the point where it can handle all interesting DWARF sections. But this
>> is a lofty goal, since DWARF parsing is notoriously hard and this
>> would require a large investment of time and effort.
> Having written about 6 DWARF parsers, I strongly disagree it is either
> notoriously hard or a large investment of time and effort. People
> have written DWARF parsers on the weekend. One of the reasons DWARF
> is popular is because it is relatively simple to *parse*, even though
> semantic extraction is more difficult.
I do mean semantic extraction which provides a representation that's
meaningful to a user and hence can be effectively compared in a test.
But really, I gave up arguing on this topic a few messages (and heated
IRC discussions) ago. RFC retracted.
> In any case, I mention the above project (google-breakpad) because i'd
> be more than happy to get that DWARF related code relicensed to the
> LLVM license if someone wanted it.
This is utterly impossible because your code does not start variables
with a capital! Seriously though, I would expect this to be
challenging since lib/DebugInfo already has quite a bit of parsing and
infrastructure already in place, and I'm not sure how easy it would be
to merge with a completely different parser.
More information about the llvm-dev