[LLVMdev] Writing unit tests for DWARF?

Devang Patel dpatel at apple.com
Thu Mar 17 07:56:59 PDT 2011


On Mar 17, 2011, at 7:29 AM, Renato Golin wrote:

> On 17 March 2011 13:48, Devang Patel <dpatel at apple.com> wrote:
>> I think you are mistaken here. I maintain and support debug info for two front ends (llvm-gcc and clang). Go ahead and check svn archives for last one year and see how many times I had to update llvm-gcc FE.
> 
> Hi Devang,
> 
> First, I'm not attacking anyone.

I understand. But you're missing the point of my comment :)  If the IR used to encode debug is changing rapidly, as you say, then I'd be force to frequently modify llvm-gcc FE. However, I have not modified llvm-gcc FE in last year or so, so I'd say the encoded IR has been stable. In last 6+ months, llvm-gcc build bot running gdb testsuite is consistently reporting same number of passes and fails (if you ignore inherent gdb testsuite stability issues).

> I said before and will say again: the
> work you've done is great. I know how complex it is to build something
> stable and keep it that way, and my comments were about how hard it
> was for me to help you in that matter.
> 
> Take my last patch on Dwarf. I've run the tests, added my own, tested
> on a Mac and still, we found a problem only after the commit. I'm not
> saying that things like this won't happen, but it was really hard for
> me to test it and make sure the patch would actually work.

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.

> 
>> In last 5 or so llvm releases, encoded debug info representation in llvm IR has changed only once (using metadata, instead of global variables). All other changes are incremental *and* backward compatible.
> 
> Not entirely true. The metadata style is the same, but the mechanism
> used to build it (DIBuilder) was changed (instead of DIFactory)
> without warning in Clang. That, per se, wouldn't be a problem, if the
> metadata generated by both of them were identical, which they were
> not.

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. 

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.

> What I'm proposing is a simple rule-set, enforced by a validation
> pass, that will reject dubious metadata. We could start as an optional
> pass, being very restrictive and failing most known code and unit
> tests. With time, we can extend and add corner cases to this
> validation until we're comfortable and turn it on by default. I
> personally think that it's much easier to relax strict asserts than to
> rely on gdb for testing.

dwarfdump --verify will do this.
-
Devang



More information about the llvm-dev mailing list