llvm dev - Feb 2013 - [LLVMdev] RFC: Improving our DWARF (and ELF) emission testing capabilities

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
>> great:
>>
>> 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
>
(http://code.google.com/p/google-breakpad/source/browse/trunk/src/common/dwarf/cfi_assembler.cc)
>
>>
>> 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.

Eli

On 23.01.2013 00:45, Eli Bendersky wrote:
> 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.
I actually hit the same predicament for COFF. The few tests that are
there usually use coff-dump.py whose output is quite limited (many tests
just compare a binary dump), does not include unwind information, and is
very different from elf-dump. Then there's llvm-objdump, which does
resolve relocations and show parts of unwind information. And then
there's also obj2yaml, but that seems to support even less. And neither
tool, IMO, produces FileCheck-friendly output.

So even though you retracted your post, I think this issue still stands
and shouldn't be ignored.

-Nico

Ideally for things that are not dwarf you should create a tool similar to
llvm-dwarfdump that is friendly to FileCheck and use that for your
testcases. For things that are dwarf you should use and extend
llvm-dwarfdump.

-eric


On Sun, Feb 3, 2013 at 2:42 PM, Nico Rieck <nico.rieck at gmail.com>
wrote:
> On 23.01.2013 00:45, Eli Bendersky wrote:
> > 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.
>
> I actually hit the same predicament for COFF. The few tests that are
> there usually use coff-dump.py whose output is quite limited (many tests
> just compare a binary dump), does not include unwind information, and is
> very different from elf-dump. Then there's llvm-objdump, which does
> resolve relocations and show parts of unwind information. And then
> there's also obj2yaml, but that seems to support even less. And neither
> tool, IMO, produces FileCheck-friendly output.
>
> So even though you retracted your post, I think this issue still stands
> and shouldn't be ignored.
>
> -Nico
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130204/47cd44eb/attachment.html>