Re: Symbol reference strangeness

[Bruce Ashfield <Bruce.Ashfield@seawaynetworks.com>]

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