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
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
On Mar 17, 2011, at 8:44 AM, Renato Golin wrote:>> dwarfdump --verify will do this. > > Is this being used in LLVM tests? This is an idea.It is not used in llvm/test tests.> 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.Yes, It'd be good to have a setup to build SingleSource and MultiSource tests with debug info and run dwarfdump --verify on them. - Devang