Kevin, On 07/23/2015 02:39 AM, Kevin Buettner wrote: > I had to make the following change in order to obtain a clean build > using your patches: > > diff --git a/gdb/dwarf2read.c b/gdb/dwarf2read.c > index e20aead..d6e3d55 100644 > --- a/gdb/dwarf2read.c > +++ b/gdb/dwarf2read.c > @@ -11457,7 +11457,7 @@ read_func_scope (struct die_info *die, struct dwarf2_cu *cu) > > newobj = pop_context (); > /* Make a block for the local symbols within. */ > - block = finish_block (newobj->name, &newobj->static_link, > + block = finish_block (newobj->name, newobj->static_link, > &local_symbols, newobj->old_blocks, > lowpc, highpc); Huh, I actually have a warning I did not notice but not an error, so I guess you built GDB as C++. Anyway, this is a big mistake that should have broken the feature I intend to add: quite bad! Thank you very much for pointing me at it. I had a look at why testsuite was clean even with this error, and I realized that all my testing was with the wrong compiler[1]: this part of the code was actually not exercized... So I picked the proper compiler and this time I saw this was not working! This time I fixed the feature, built in C++ mode just to be sure. Here's the updated patch: - I fixed yacc parsers in all languages so that block information from symbol lookups are properly transmitted to returned expressions. - I fixed the usage of hash table to save static link (I do mappings in objfiles.c, not sets so my usage of htab was invalid). So this time, tested both with a GCC release and a patched GCC: no regression on x86_64-linux. I kept the "static link" terminology because I'm waiting for a consensus before changing everything. ;-) [1] In nested functions, an unpatched GCC creates local variables that are references to the non-local ones, so the feature works at the user level, but not using the static link machinery. The aim of my change is to make GDB work even without these "fake" local reference variables. -- Pierre-Marie de Rodat