[LLVMdev] Writing unit tests for DWARF?

[Talin]

One problem that has been vexing me of late: It seems that whenever I run
into a problem that requires debugging one of my programs in gdb, before I
can do that I have to fix my frontend's broken generation of debugging info.

The code that generates debugging information is quite fragile - you have to
generate metadata for each of your files, classes, and functions, and do so
without error, because if you do make a mistake, the only way you'll find
out is because gdb refuses to debug your program. And as I work on the code,
occasionally bugs creep in, either from my side or occasionally from the
LLVM side. The problem is, that I don't always check if the debug
information is valid, so several weeks can go by and I don't notice
something broke.

What is needed is some way to write a unit test for DWARF information, so
that if I broke something I would notice it immediately and could either fix
it or roll back. Unfortunately, the various DIDescriptor.Verify() methods
are nowhere near strict enough - you can create completely nonsensical DIEs
that still pass through Verify(). And even if the Verify() methods were 100%
reliable, they only test whether the LLVM metadata is valid - they don't
test whether the actual DWARF embedded in the final executable is correct.

I suppose you could do something with dwarfdump -ka, although it would be
better to have something that worked on all platforms. Even dwarfdump itself
has different option syntax on Linux vs. OS X. And I don't think it's
possible right now to generate code that passes through dwarfdump with zero
error messages, or at least, I've never been able to figure out how to do
it.

I was thinking that since lldb needs to know how to interpret all this stuff
anyway, perhaps there could be a way to use the same code to validate the
debug information for an executable. I know lldb doesn't run on every
platform yet, but I suspect that the parts of lldb which decode DWARF are
fairly generic.

-- 
-- Talin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110316/a7d25b91/attachment.html>