From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14899 invoked by alias); 20 Mar 2003 14:54:51 -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 14885 invoked from network); 20 Mar 2003 14:54:49 -0000 Received: from unknown (HELO apollo.seawaynetworks.com) (216.209.86.50) by sources.redhat.com with SMTP; 20 Mar 2003 14:54:49 -0000 Received: from camelot-019.seawaynetworks.com (camelot-019 [10.10.1.19]) by apollo.seawaynetworks.com (8.12.8/8.12.8) with ESMTP id h2KEsmiR016311 for ; Thu, 20 Mar 2003 09:54:48 -0500 (EST) Received: (from ashfield@localhost) by camelot-019.seawaynetworks.com (8.11.6/8.11.6) id h2KEstY22689 for gdb@sources.redhat.com; Thu, 20 Mar 2003 09:54:55 -0500 X-Authentication-Warning: camelot-019.seawaynetworks.com: ashfield set sender to ashfield@seawaynetworks.com using -f Date: Thu, 20 Mar 2003 14:54:00 -0000 From: Bruce Ashfield To: gdb@sources.redhat.com Subject: Re: Accessing variables in .sdata Message-ID: <20030320145454.GA22639@seawaynetworks.com> References: <20030312175317.GA2464@seawaynetworks.com> <20030312182804.GA26459@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030312182804.GA26459@nevyn.them.org> User-Agent: Mutt/1.3.25i X-SW-Source: 2003-03/txt/msg00299.txt.bz2 Hi, In message: Re: Accessing variables in .sdata on March 12 Daniel Jacobowitz wrote: > On Wed, Mar 12, 2003 at 12:53:17PM -0500, Bruce Ashfield wrote: > > Hi all, > > > > I've been trying to characterize the types of variables I > > can't access when using a linker script during the construction > > of our bootable image. The linker script in question is a > > slightly modified one from ppcboot and I can't see any > > fundamental problems with the script. > > > > I've been dumping the map file during the link and comparing > > the one that the linker internally generates to the one that > > results from our supplied linker map. I'm seeing a different > > location for the .text,.bss,.data segments and some other > > ordering differences, but again nothing fundamentally wrong. > > > > But my problem persists. If I use a linker script and try to > > print the value of a variable in a .sdata I'm presented with > > the gdb error "Cannot access memory at address 0x...". Where > > address 0xABCD.. is no where near where the map file says > > that section and variable should be found. It's like gdb is > > missing the offset of the sections. > > > > I've also tried using add-symbol-file to force gdb to recognize > > the start address for the various sections, but at best I see > > the error address moving around. > > > > I've been told from people around the office that if they load > > the symbol file multiple times the error address changes and > > they can breakpoint functions, but not usually inside a > > function. > > This sounds like the sdata offset is uninitialized for some reason. I > don't know why it would affect breakpoints, though. Did you try > valgrind? Do you have a smaller testcase working yet based on this new > insight? Just wanted to summarize what I've done to fix the problem, in case anyone else wanders by and sees the thread. It turned out that my problem was in fact directly related to the use of a linker map. When the linker map was removed, gdb had no problems accessing the correct location for any symbols. The gotcha was that we needed the linker map to boot our chip :) While dumping the maps during linking I noticed that the .gnu.linkonce sections were being dumped in strange places. We make *heavy* use of pragma interface/implementation to the final image is riddled with the linkonce sections. The linker map that was being used didn't include any specific instructions on where to put these sections, so the linker was making the call. When I moved *(gnu.linkonce.t*) into the .text section of the link map, gdb was able to get the correct offsets for the variables in questions. I've since added many more explicit instructions to the linker map about the linkonce sections. We can now boot and debug, which is a good thing. Thanks for your patience. Bruce Ashfield > -- > Daniel Jacobowitz > MontaVista Software Debian GNU/Linux Developer -- Bruce Ashfield | "Thou shalt not follow the NULL pointer, for | chaos and madness await thee at its end." | - unknown