[llvm-commits] [llvm-gcc-4.2] r93821 - in /llvm-gcc-4.2/trunk/gcc: llvm-convert.cpp llvm-debug.cpp llvm-debug.h llvm-internal.h

[Duncan Sands]

Hi Stuart,

> I'm sure something could be done with a mildly-toxic mixture of 
> dwarfdump and egrep, but I don't know if dwarfdump is commonly available 
> on all LLVM platforms.  (A quick Google check shows that dwarfdump has 
> been ported to Windows, but offhand I don't know if LLVM even generates 
> DWARF on Windows.)
> 
> It may be possible to write some "awesome" regular expressions to 
> examine the resulting assembly file, but these are difficult to write, 
> and I expect they would break often as LLVM evolves.
> 
> I'm pretty sure that the GDB test suite already does testing for lexical 
> blocks.  This is probably the best existing lexical block test we have.
> 
> What sort of testing did you have in mind?  How elaborate must this be?

basically I'm interested in tests that check that the frontend is
outputting correct debug info into the LLVM IR, for example correct
scoping info.  This will protect against regressions when people muck
around with llvm-gcc in the future, and for myself it will be helpful
for checking that dragonegg is producing comparable debug info.  These
kinds of tests should be much easier than checking the final assembler
or object code (though that is important too) since they only look at
the IR produced.

Ciao,

Duncan.