Accessing variables in .sdata

Accessing variables in .sdata

[Bruce Ashfield]

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.

I've been searching the mailing lists and the problem described
in: http://mail.gnu.org/archive/html/bug-gdb/2001-02/msg00015.html
Sounds very similar, but I've been wrong before. 

Any ideas ?

Bruce

-- 
Bruce Ashfield         | "Thou shalt not follow the NULL pointer, for
                       |  chaos and madness await thee at its end."
                       |       - unknown

Re: Accessing variables in .sdata

[Daniel Jacobowitz]

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?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: Accessing variables in .sdata

[Bruce Ashfield]

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