Relocating Static Local Variables BUG?

["Richard Schmitt" <rschmitt at bluepeach dot com>]

I've spent a bit of time trying to debug an issue we're having and, to be
honest, I'm completely lost in the symbol table creation of GDB.  Before I
throw my hands up, say some nasty little things that'd make even the most
cynical engineer blush, and vow to never look at the symbol handling in
GDB again without some form of chemical assistance, I thought I'd post to
this group and see if anyone can explain what's happening.

The problem is easy to reproduce and demonstrate.  It has to do with
relocating of static local variables.  Meaning, the symbols never get
relocated.  Our target is a remote ARM processor, but I can reproduce the
problem in linux or cygwin on a local program as well which has led me to
conclude that the problem isn't related to remote debugging, nor is is
platform specific.

To illustrate the problem, here's a simple program:

static int test1 ;

int main (void)
{
  static int test2 ;
  int test3 ;

  test3 = 1 ;
  test2 = test3 ;
  test1 = test2 ;
}

If we compile this program, generate an elf, and load the symbols into gdb
as follows:

$ gdb
gdb> # Add the symbol table for the test.  We won't load the code although
gdb> # we could, except since all we want to show is issues with symbol
gdb> # relocation
gdb> add-symbol-file test.elf 0x10000 -s .bss 0x20000
gdb> # Now let's look at the static global
gdb> print &test1
$1 = (int *) 20008
gdb> # Now let's look at a static local
gdb> print &main::test2
$2 = (int *) 0x804955c

If you do an object dump of the elf file, both test2.0 is located at
offset 0x04 in the .bss section and test1 is located at offset 0x08 in
.bss.   I presume the '.0' is appended because it is defined local to
block 0.

Through some debugging, I've shown that when looking up the symbols in the
routine 'lookup_symbol_aux_symtabs' in symtab.c, after the call to
fixup_symbol_section, the sym->section for test1 is set to 21, yet the
sym->section for test2 is set to 0.  It is for this reason that the symbol
test2 does not get relocated.

So, why is the section for test2 0?  Well, fixup_symbol_section looks up
the symbol in the minimal_symbol_table.  The problem is that since test2
is local to a block, it is actually in the minimal symbol table as
test2.0.  Looking it up as test2 never finds it.  It's too bad 'cause it
is in the minimal symbol table with the right section.

So the next step for the lookup code is to try to find it within blocks
using the routine lookup_block_symbol.  This searches through
'dictionaries' created by reading in the debug (dwarf) info from the elf
file.  The symbol is in there but the dwarf info does not have any section
info so the section number is returned as zero.

So the question is: Should the dwarf info have section info or should
there be some other algorithm used so we find the symbol in the minimal
symbol table.  When the dictionaries are created, should there be some
attempt to pair up the dwarf symbol with a minimal symbol.  I hope there
is someone who can help point me in the right direction?

Thanks,
Rich

-- 
Richard Schmitt
CTO
Blue Peach Solutions
Phone: 877.BLU.PEACH (877.258-7322) x 704
Fax: 508.302.6183
http://www.bluepeach.com