[LLVMdev] Writing unit tests for DWARF?

[Renato Golin]

On 17 March 2011 14:56, Devang Patel <dpatel at apple.com> wrote:
> In other words, someone is changing target independent code generation and expects llvm regression tests to catch all bugs. If that's true, we don't need any build bots linking and executing and running llvm generated code.

Ok, that was a bad example... ;)


> Again, you're mistaken.  llvm-gcc and dragon-egg still uses DIFactory and debug info quality has remained same. This says the IR used to encode debug has not been impacted by DIBuilder vs. DIFactory.

I see, so that comes back to my original point. I couldn't build a
complete debug infrastructure with DIFactory because I was lost on
many implementation details of the order and types of metadata
information in each IR statement. That's probably the reason why, in
my case (and probably Talin's), it all blew up.


> Note, DIBuilder etc.. are utilities sued to produce IR, not the interface defined by the IR.  In other words, replacement of of OldIRBuilder interface with NewIRBuilder has nothing to do with stability of llvm IR documented by LangRef.html.

Yes, I know. I'm more concerned with the 'what' and not the 'how'. For
me, an up-to-date documentation on what's strictly needed to produce
legal Dwarf with a clear, short, explanation for each field and how
they relate to each other (as this is more important for debug than
instructions), are of a higher priority than a full-blown validation
system.


> dwarfdump --verify will do this.

Is this being used in LLVM tests? This is an idea.

I had a look at your debug tests in clang and they're similar to what I do here.

The problem with debug tests is that it doesn't depend only on the
compiler, but on the debugger for each host/target platform
combinations. Though, dwarfdump could help us grep out the basic stuff
without the need to resort to a debugger to check for Dwarf structure,
just correct locations and line information.

I'm using LIT to also check Dwarf structure, but I have to say that my
success is limited. While I could get far by creating variables on
metadata lines and checking they point to the right types, every time
one tiny thing changes, I have to refactor most of the tests.

I did the same with Dwarf, checking for addresses of types and later
seeing if the variable refers to it, checking if the location points
to debug_loc or is just an expression, etc. But debug information is
far too volatile to make that approach reasonable in the long run...
:(

cheers,
--renato