From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29438 invoked by alias); 23 Apr 2004 16:03:15 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 29408 invoked from network); 23 Apr 2004 16:03:13 -0000 Received: from unknown (HELO server.bluepeach.com) (66.189.17.154) by sources.redhat.com with SMTP; 23 Apr 2004 16:03:13 -0000 Received: from server.bluepeach.com [10.0.1.2] by server.bluepeach.com (AppleMailServer 10.2.3.0) id 11980 via TCP with SMTP; Fri, 23 Apr 2004 12:03:28 -0400 Received: from 10.0.1.2 (SquirrelMail authenticated user rschmitt) by mail.bluepeach.com with HTTP; Fri, 23 Apr 2004 12:03:28 -0400 (EDT) Message-ID: <55879.10.0.1.2.1082736208.squirrel@mail.bluepeach.com> Date: Fri, 23 Apr 2004 16:10:00 -0000 Subject: Relocating Static Local Variables BUG? From: "Richard Schmitt" To: gdb@sources.redhat.com Cc: rishi75@hotmail.com Reply-To: rschmitt@bluepeach.com User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-SW-Source: 2004-04/txt/msg00145.txt.bz2 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