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
On 17 March 2011 18:45, Devang Patel <dpatel at apple.com> wrote:> Yes, It'd be good to have a setup to build SingleSource and MultiSource tests with debug info and run dwarfdump --verify on them.I tried some dwarfdump on a few examples I had and the comparison with codesourcery's gcc is impossible, the resulting Dwarf is very different. For instance, GCC declares the types at the beginning of the tree while LLVM only does when needed (metadata-style). The relocation sections in GCC are huge and they also use debug_loc in many more cases than LLVM, for instance extern functions, global variables and the cases I mentioned in my example before. Of course, Dwarf produced by Armcc is also different (though, closer to what GCC does, for obvious reasons). One way we could do this, slowly and painfully, but surely, is to generate Dwarf, use the debugger to make sure that Dwarf actually produces what GDB is expecting (you probably have many cases already) and take a snapshot of that Dwarf. Once we understand how that Dwarf works and what are the required tags, we create a dwarfdump test that will FileCheck on those. This is more or less how I'm doing my local IR/Dwarf/GDB tests. It takes a while, but have saved me from some regressions already... ;) -- cheers, --renato http://systemcall.org/ Reclaim your digital rights, eliminate DRM, learn more at http://www.defectivebydesign.org/what_is_drm
Renato, On Mar 17, 2011, at 2:00 PM, Renato Golin wrote:> On 17 March 2011 18:45, Devang Patel <dpatel at apple.com> wrote: >> Yes, It'd be good to have a setup to build SingleSource and MultiSource tests with debug info and run dwarfdump --verify on them. > > I tried some dwarfdump on a few examples I had and the comparison with > codesourcery's gcc is impossible, the resulting Dwarf is very > different.I did not mean comparing dwarfdump output. It is never going to work. Sorry for the confusion. I meant letting dwarfdump verify the structure of dwarf info.> For instance, GCC declares the types at the beginning of the tree > while LLVM only does when needed (metadata-style). The relocation > sections in GCC are huge and they also use debug_loc in many more > cases than LLVM, for instance extern functions, global variables and > the cases I mentioned in my example before. Of course, Dwarf produced > by Armcc is also different (though, closer to what GCC does, for > obvious reasons).You'll find that dwarf produced by llvm-gcc and clang is also different (even from the days when clang used DIFactory). And guess what clang generate DIE (Debug Info Entries) ordering is likely to change again in near future!> One way we could do this, slowly and painfully, but surely, is to > generate Dwarf, use the debugger to make sure that Dwarf actually > produces what GDB is expecting (you probably have many cases already) > and take a snapshot of that Dwarf. Once we understand how that Dwarf > works and what are the required tags, we create a dwarfdump test that > will FileCheck on those.Instead, isn't it easier and straight forward to do a FileCheck on debugger output in the first place ? - Devang