Symbol reference strangeness

Symbol reference strangeness

[Bruce Ashfield]

Hi all,

I'm trying to determine what's happening with the symbols for
a project I'm working one. I've completed a move from a gcc-3.0
to a gcc-3.2 based toolchain and I've also upgraded to gdb-5.3.
Ever since the switch over I've been seeing odd problems accessings
variables and other symbols in the generated images.

I've gone over the compile flags and gdb options without much 
success. I just finished trying the latest CVS snapshot of gdb
without any more luck. I'm hoping someone can slap me and point
me in the right direction. 

The most similar problems I've found to what I'm seeing on the
mailing list archives are:

http://sources.redhat.com/ml/gdb/2002-12/msg00111.html
http://sources.redhat.com/ml/bug-gdb/2000-09/msg00012.html

Which fairly closely describe what I've been seeing. So I'm 
now making sure that everything is being compiled with -gdwarf-2,
but that is only partially helping the problem, now I can see
some variables but not others, where before loading the same
symbol file multiple times would eventually get me at some 
variables.

The following capture will best describe what I'm seeing.

(gdb) p /x debugLevel
$1 = 0xfffffff
(gdb) p sealKernelMaxConsecutiveCt_g 
$3 = 3
(gdb) p /x debugLevel 
Cannot access memory at address 0x40249fc0

There are other ways of making this happen, but this is the
most simple. Very strange and I'm running out of things to try,
any suggestions would be greatly appreciated. 

Here are some point form technical details:

compiler: 3.2.2 (powerpc cross compiler, host linux)
gdb: 5.3 and latest March CVS snapshot
compiling with: -gdwarf-2 in debug mode.

Cheers,

Bruce Ashfield




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

Re: Symbol reference strangeness

[Daniel Jacobowitz]

On Thu, Mar 06, 2003 at 02:35:45PM -0500, Bruce Ashfield wrote:
> Hi all,
> 
> I'm trying to determine what's happening with the symbols for
> a project I'm working one. I've completed a move from a gcc-3.0
> to a gcc-3.2 based toolchain and I've also upgraded to gdb-5.3.
> Ever since the switch over I've been seeing odd problems accessings
> variables and other symbols in the generated images.
> 
> I've gone over the compile flags and gdb options without much 
> success. I just finished trying the latest CVS snapshot of gdb
> without any more luck. I'm hoping someone can slap me and point
> me in the right direction. 
> 
> The most similar problems I've found to what I'm seeing on the
> mailing list archives are:
> 
> http://sources.redhat.com/ml/gdb/2002-12/msg00111.html
> http://sources.redhat.com/ml/bug-gdb/2000-09/msg00012.html
> 
> Which fairly closely describe what I've been seeing. So I'm 

No, that's a completely different problem (and fixed now, though I
don't remember if the fix was in 5.3 or not).

> now making sure that everything is being compiled with -gdwarf-2,
> but that is only partially helping the problem, now I can see
> some variables but not others, where before loading the same
> symbol file multiple times would eventually get me at some 
> variables.
> 
> The following capture will best describe what I'm seeing.
> 
> (gdb) p /x debugLevel
> $1 = 0xfffffff
> (gdb) p sealKernelMaxConsecutiveCt_g 
> $3 = 3
> (gdb) p /x debugLevel 
> Cannot access memory at address 0x40249fc0
> 
> There are other ways of making this happen, but this is the
> most simple. Very strange and I'm running out of things to try,
> any suggestions would be greatly appreciated. 
> 
> Here are some point form technical details:
> 
> compiler: 3.2.2 (powerpc cross compiler, host linux)
> gdb: 5.3 and latest March CVS snapshot
> compiling with: -gdwarf-2 in debug mode.

I'd need a testcase to be able to help much.  Is that the right or
wrong address?  What does p &debugLevel say?  Where is it actually
located?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: Symbol reference strangeness

[Bruce Ashfield]

Hi,

Shoot. I was hoping they were similar, hard to tell with those
search results. Here is the additional information, I'll see if
I can put together a testcase, but I'm suspicious that part of
the problem is due to the sizes of our images.

> I'd need a testcase to be able to help much.  Is that the right or
> wrong address?  What does p &debugLevel say?  Where is it actually 
> located?   

----------

> powerpc-eabi-gdb /local/ashfield/SW5000/swy/images/ccp_dbg_nopt_nin_v.img
GNU gdb 5.3
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "--host=i686-pc-linux-gnu --target=powerpc-eabi"...
(gdb)  p /x debugLevel
$1 = 0xfffffff
(gdb)  p &debugLevel
$2 = (Uint32 *) 0x778e4
(gdb) p sealKernelMaxConsecutiveCt_g
$3 = 3
(gdb) p &sealKernelMaxConsecutiveCt_g
$4 = (Uint32 *) 0x77848
(gdb) p /x debugLevel
Cannot access memory at address 0x40249fc0
(gdb) p &debugLevel
$5 = (Uint32 *) 0x40249fc0

--------

Very strange indeed. The address is getting corrupted and I'm at a loss
to explain it. This problem didn't pop up with the gcc-3.0 and older
gdb's, which isn't that much of a surpise, with the amount of diffs.

The two variables that I'm accessing are compiled in different parts
of the system, placed in different static libraries and linked into
the final image. Once I've crossed the boundary from the .a that is 
holding debugLevel to the one with sealKernelMaxConsecutiveCt_g, there
seems to be no way back.

Let me know what else I can provide (I'll work on that testcase).

Cheers,

Bruce Ashfield


In message: Re: Symbol reference strangeness
on March 06 Daniel Jacobowitz wrote:

> On Thu, Mar 06, 2003 at 02:35:45PM -0500, Bruce Ashfield wrote:
> > Hi all,
> > 

<snip>

> > The most similar problems I've found to what I'm seeing on the
> > mailing list archives are:
> > 
> > http://sources.redhat.com/ml/gdb/2002-12/msg00111.html
> > http://sources.redhat.com/ml/bug-gdb/2000-09/msg00012.html
> > 
> > Which fairly closely describe what I've been seeing. So I'm 
> 
> No, that's a completely different problem (and fixed now, though I
> don't remember if the fix was in 5.3 or not).

<snip>

> 
> -- 
> 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

Re: Symbol reference strangeness

[Daniel Jacobowitz]

On Thu, Mar 06, 2003 at 02:57:14PM -0500, Bruce Ashfield wrote:
> Hi,
> 
> Shoot. I was hoping they were similar, hard to tell with those
> search results. Here is the additional information, I'll see if
> I can put together a testcase, but I'm suspicious that part of
> the problem is due to the sizes of our images.
> 
> > I'd need a testcase to be able to help much.  Is that the right or
> > wrong address?  What does p &debugLevel say?  Where is it actually 
> > located?   
> 
> ----------
> 
> > powerpc-eabi-gdb /local/ashfield/SW5000/swy/images/ccp_dbg_nopt_nin_v.img
> GNU gdb 5.3
> Copyright 2002 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "--host=i686-pc-linux-gnu --target=powerpc-eabi"...
> (gdb)  p /x debugLevel
> $1 = 0xfffffff
> (gdb)  p &debugLevel
> $2 = (Uint32 *) 0x778e4
> (gdb) p sealKernelMaxConsecutiveCt_g
> $3 = 3
> (gdb) p &sealKernelMaxConsecutiveCt_g
> $4 = (Uint32 *) 0x77848
> (gdb) p /x debugLevel
> Cannot access memory at address 0x40249fc0
> (gdb) p &debugLevel
> $5 = (Uint32 *) 0x40249fc0
> 
> --------
> 
> Very strange indeed. The address is getting corrupted and I'm at a loss
> to explain it. This problem didn't pop up with the gcc-3.0 and older
> gdb's, which isn't that much of a surpise, with the amount of diffs.
> 
> The two variables that I'm accessing are compiled in different parts
> of the system, placed in different static libraries and linked into
> the final image. Once I've crossed the boundary from the .a that is 
> holding debugLevel to the one with sealKernelMaxConsecutiveCt_g, there
> seems to be no way back.
> 
> Let me know what else I can provide (I'll work on that testcase).

Hrm, what's the link map for this thing look like (roughly)?  If the
two are in different parts of the system then why are they only 0x90
bytes or so apart initially?

You're on an intel-linux host; could you try using valgrind (just
google for it) on GDB to see if it shows anything interesting?


-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: Symbol reference strangeness

[Bruce Ashfield]

Hi,

I've been plugging away on trying to eliminate some of the factors
that could be causing the "Cannot access memory" errors I've been
seeing while trying to inspect variables with gdb. What I've managed
to come up with is a theory that it is the linker script we are 
using to build our image that is causing the problems. 

What I did was put together my own crt0.S to define some of the
more mundane eabi requirements and stub out some symbols that are
required for ppcboot and some other things. When I build the image
linking this .o and all of the libraries we always link, I get
the following:

(gdb) p /x debugLevel
$2 = 0xfffffff
(gdb) p /x &debugLevel
$3 = 0x187e95c
(gdb) p kernSysCall 
$4 = {int (seal_syscall)} 0x18005f4 <kernSysCall>
(gdb) p /x &debugLevel
$5 = 0x187e95c
(gdb) 

But when I put the linker script back into the mix (via -T) I 
get the strange behaviour back. The linker script that is being
used is only a slightly modified ppcboot linker script, which is
why I can't explain it. Check out the following:

There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "--host=i686-pc-linux-gnu --target=powerpc-eabi"...
(gdb) p /x debugLevel
Cannot access memory at address 0x6376e7ff
(gdb) p /x &debugLevel
$1 = 0x6376e7ff
(gdb) p kernSysCall 
$2 = {int (seal_syscall)} 0x7dc0 <kernSysCall>
(gdb) p /x &debugLevel
$3 = 0x4024a2ac

I'm at a complete loss to explain what's going on. Does this behaviour
ring any bells ? I'm trying to rip apart the linker script, but like
I said, it looks pretty standard so I'm doubtfull I'll get far.

Any tips (or slaps in the head) will be greatly appreciated.

Bruce Ashfield



In message: Re: Symbol reference strangeness
on March 06 Daniel Jacobowitz wrote:

> On Thu, Mar 06, 2003 at 02:57:14PM -0500, Bruce Ashfield wrote:
> > Hi,
> > 
> > Shoot. I was hoping they were similar, hard to tell with those
> > search results. Here is the additional information, I'll see if
> > I can put together a testcase, but I'm suspicious that part of
> > the problem is due to the sizes of our images.
> > 
> > > I'd need a testcase to be able to help much.  Is that the right or
> > > wrong address?  What does p &debugLevel say?  Where is it actually 
> > > located?   
> > 
> > ----------
> > 
> > > powerpc-eabi-gdb /local/ashfield/SW5000/swy/images/ccp_dbg_nopt_nin_v.img
> > GNU gdb 5.3
> > Copyright 2002 Free Software Foundation, Inc.
> > GDB is free software, covered by the GNU General Public License, and you are
> > welcome to change it and/or distribute copies of it under certain conditions.
> > Type "show copying" to see the conditions.
> > There is absolutely no warranty for GDB.  Type "show warranty" for details.
> > This GDB was configured as "--host=i686-pc-linux-gnu --target=powerpc-eabi"...
> > (gdb)  p /x debugLevel
> > $1 = 0xfffffff
> > (gdb)  p &debugLevel
> > $2 = (Uint32 *) 0x778e4
> > (gdb) p sealKernelMaxConsecutiveCt_g
> > $3 = 3
> > (gdb) p &sealKernelMaxConsecutiveCt_g
> > $4 = (Uint32 *) 0x77848
> > (gdb) p /x debugLevel
> > Cannot access memory at address 0x40249fc0
> > (gdb) p &debugLevel
> > $5 = (Uint32 *) 0x40249fc0
> > 
> > --------
> > 
> > Very strange indeed. The address is getting corrupted and I'm at a loss
> > to explain it. This problem didn't pop up with the gcc-3.0 and older
> > gdb's, which isn't that much of a surpise, with the amount of diffs.
> > 
> > The two variables that I'm accessing are compiled in different parts
> > of the system, placed in different static libraries and linked into
> > the final image. Once I've crossed the boundary from the .a that is 
> > holding debugLevel to the one with sealKernelMaxConsecutiveCt_g, there
> > seems to be no way back.
> > 
> > Let me know what else I can provide (I'll work on that testcase).
> 
> Hrm, what's the link map for this thing look like (roughly)?  If the
> two are in different parts of the system then why are they only 0x90
> bytes or so apart initially?
> 
> You're on an intel-linux host; could you try using valgrind (just
> google for it) on GDB to see if it shows anything interesting?
> 
> 
> -- 
> 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