[LLVMdev] Writing unit tests for DWARF?

[Devang Patel]

On Mar 17, 2011, at 7:12 AM, Jan Sjodin wrote:

> Could dwarfdump --verify be used to check the debug info?

Yes, it could be used to validate DWARF structure of debug info. It does not check whether the information communicated through dwarf is correct or not. E.g. if dwarf info says variable is at frame pointer + x offset then you need debugger to verify that, dwarfdump won't help you.

-
Devang


> 
> - Jan 
> 
> From: Devang Patel <dpatel at apple.com>
> To: Talin <viridia at gmail.com>
> Cc: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu>
> Sent: Thu, March 17, 2011 9:41:10 AM
> Subject: Re: [LLVMdev] Writing unit tests for DWARF?
> 
> Talin,
> 
> If there is a magic wand, I would be interested to know!
> 
> DIDescriptor.Verify() is not suitable for you needs. It checks structure of encoded debug info after optimizer has modified the IR. Its main goal is inform Dwarf writer, at the end of code gen, which IR construct it should ignore.
> 
> If you want to test code gen you have to link compiled code and run it regularly. That's what various build bots for llvm does. Same way, if you want to validate generated debug info you have to go through the debugger.
> 
> That said, there is a new unit test harness available. All it needs is more unit tests...
> 
>     http://llvm.org/docs/TestingGuide.html#quickdebuginfotests
> 
> -
> Devang
> 
> On Mar 16, 2011, at 11:40 PM, Talin wrote:
> 
> > 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
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu        http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 
> _______________________________________________
> 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/20110317/989b1124/attachment.html>