On Fri, Jan 15, 2016 at 3:41 PM, Pierre-Marie de Rodat <derodat@adacore.comwrote: > On 01/13/2016 01:17 PM, Richard Biener wrote: >> >> I wonder if you can construct a guality testcase that passes with and >> fails without >> the patch? > > > I’ve tried to first look at how guality testcases are written (thanks for > your answers on IRC, by the way :-)) and then how I could write a testcase > for my fix. It seems there are two ways: match patterns in the assembly file > or evaluate an expression in GDB. > > I already have the testcase I used during development: it’s written in Ada, > to build with -O2. The way it checks the fix is to see if GDB manages to put > a breakpoint on the Child2 symbol before executing the program (it cannot > before my fix and it can afterwards). Oh, and it requires a fairly recent > GDB version (7.10 looks good). > > I managed to get a similar GNU C99 reproducer (it’s attached): the debugging > information has the pattern that exhibits the bugfix. Namely: while the > “parent” function is inlined, the “child” function (which is in a block > inside “parent”) is not. So GDB relies on the DW_TAG_abstract_origin in the > inlined block to refer to the abstract block that contains the DIE that > materializes “child“. > > However, it looks like there is no way in GDB to refer to C nested functions > when they are not in the current scope: >> >> $ gcc -g -O2 -std=gnu99 nested_fun.c nested_fun_helpers.c >> $ gdb -n -q ./a.out >> (gdb) ptype child >> No symbol "child" in current context. >> (gdb) ptype nested_fun.parent.child >> No symbol "nested_fun" in current context. > > > On the other hand, this works with the Ada testcase: >> >> (gdb) ptype nested_fun.parent.child >> type = (false, true) > > > So I’m not sure what to do next: should I do a fragile testcase based on > scanning the assembly file? (it could break with an optimizer change) create > a guality testsuite for Ada?
Sounds like a good excuse to add a guality for Ada (which has unique needs for dwarf). Richard. >> Anyway, the patch looks ok to me but please give others a chance to chime >> in. > > > Sure. Thank you for reviewing! > > -- > Pierre-Marie de Rodat
