From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23186 invoked by alias); 11 Mar 2003 17:54:36 -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 23179 invoked from network); 11 Mar 2003 17:54:35 -0000 Received: from unknown (HELO apollo.seawaynetworks.com) (216.209.86.50) by 172.16.49.205 with SMTP; 11 Mar 2003 17:54:35 -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 h2BHsV5g010347; Tue, 11 Mar 2003 12:54:31 -0500 (EST) Received: (from ashfield@localhost) by camelot-019.seawaynetworks.com (8.11.6/8.11.6) id h2BHsb425749; Tue, 11 Mar 2003 12:54:37 -0500 X-Authentication-Warning: camelot-019.seawaynetworks.com: ashfield set sender to ashfield@seawaynetworks.com using -f Date: Tue, 11 Mar 2003 17:54:00 -0000 From: Bruce Ashfield To: Daniel Jacobowitz Cc: gdb@sources.redhat.com Subject: Re: Symbol reference strangeness Message-ID: <20030311175436.GA25440@seawaynetworks.com> References: <20030306193545.GA12991@seawaynetworks.com> <20030306194213.GA24243@nevyn.them.org> <20030306195714.GA13131@seawaynetworks.com> <20030306200617.GA494@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030306200617.GA494@nevyn.them.org> User-Agent: Mutt/1.3.25i X-SW-Source: 2003-03/txt/msg00161.txt.bz2 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 (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 (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