From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22240 invoked by alias); 8 Oct 2003 07:29:14 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 22211 invoked from network); 8 Oct 2003 07:29:11 -0000 Received: from unknown (HELO mail.esperi.org.uk) (194.247.41.52) by sources.redhat.com with SMTP; 8 Oct 2003 07:29:11 -0000 Received: from esperi.org.uk (1000@amaterasu.srvr.nix [192.168.14.14]) by mail.esperi.org.uk (8.12.10/8.12.10) with ESMTP id h987T7JR001451; Wed, 8 Oct 2003 08:29:07 +0100 Received: (from nix@localhost) by esperi.org.uk (8.12.10/8.12.10/Submit) id h987T5ri032263; Wed, 8 Oct 2003 08:29:05 +0100 To: Christian Joensson Cc: GDB list , gdb-gnats@sources.redhat.com, gdb-patches@sources.redhat.com Subject: Re: build/955: build failure with GDB-5.3: sparc-nat.c structure redefinition errors with sparc64-linux, glibc-2.2.x References: <20030427150800.19859.qmail@sources.redhat.com> <20030427153321.GA3394@nevyn.them.org> <20030510095712.A19164@u1sparc.j-son.org> <20030510153527.A5854@u1sparc.j-son.org> <20030825085704.A14976@u1sparc.j-son.org> From: Nix X-Emacs: because you deserve a brk today. Date: Wed, 08 Oct 2003 07:29:00 -0000 In-Reply-To: <20030825085704.A14976@u1sparc.j-son.org> (Christian Joensson's message of "Mon, 25 Aug 2003 08:57:04 +0200") Message-ID: <87wubggpby.fsf@amaterasu.srvr.nix> User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Rational FORTRAN, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-10/txt/msg00198.txt.bz2 On Mon, 25 Aug 2003, Christian Joensson uttered the following: > uhm, just tried gdb cvs HEAD, as of Sun Aug 24 12:01:38 UTC 2003, same thing: I'm back, at last. > In file included from /usr/include/asm/reg.h:7, > from /home/chj/src/gdb/sparc-nat.c:38: > /usr/include/asm-sparc64/reg.h:49: error: redefinition of `struct fpu' sparc64? Are you trying to build a 64-bit gdb? > /home/chj/src/gdb/sparc-nat.c: In function `fetch_inferior_registers': > > /home/chj/src/gdb/sparc-nat.c:101: warning: cast from pointer to integer of different size > /home/chj/src/gdb/sparc-nat.c:105: warning: implicit declaration of function `memcpy' > /home/chj/src/gdb/sparc-nat.c:108: error: structure has no member named `r_ps' > /home/chj/src/gdb/sparc-nat.c:110: error: structure has no member named `r_pc' > /home/chj/src/gdb/sparc-nat.c:112: error: structure has no member named `r_npc' > /home/chj/src/gdb/sparc-nat.c:134: warning: cast from pointer to integer of different size > /home/chj/src/gdb/sparc-nat.c: In function `store_inferior_registers': > > /home/chj/src/gdb/sparc-nat.c:259: error: structure has no member named `r_ps' > /home/chj/src/gdb/sparc-nat.c:261: error: structure has no member named `r_pc' > /home/chj/src/gdb/sparc-nat.c:263: error: structure has no member named `r_npc' > /home/chj/src/gdb/sparc-nat.c:269: warning: cast from pointer to integer of different size > /home/chj/src/gdb/sparc-nat.c:285: warning: cast from pointer to integer of different size > /home/chj/src/gdb/sparc-nat.c: In function `fetch_core_registers': > > /home/chj/src/gdb/sparc-nat.c:319: error: structure has no member named `r_ps' > /home/chj/src/gdb/sparc-nat.c:320: error: structure has no member named `r_pc' > /home/chj/src/gdb/sparc-nat.c:321: error: structure has no member named `r_npc' > make[1]: *** [sparc-nat.o] Error 1 > make[1]: Leaving directory `/usr/local/src/gcc-binutils/trunk/objdir-gdb/gdb' > make: *** [all-gdb] Error 2 This is *not* related to the earlier bug in sparc-nat.c / the Linux kernel headers / the glibc headers that the earlier patch from Daniel Jacobowitz was for. That patch works (Debian uses it). Using GDB-6.0-release, I now see gcc -c -O2 -mcpu=ultrasparc -mtune=ultrasparc -m32 -g -pipe -D__NO_STRING_INLINES -D__NO_MATH_INLINES -D_FILE_OFFSET_BITS=64 -I. -I. -I./config -DLOCALEDIR="\"/usr/share/locale\"" -DHAVE_CONFIG_H -I./../include/opcode -I./../readline/.. -I../bfd -I./../bfd -I./../include -I../intl -I./../intl -DMI_OUT=1 -DTUI=1 -I./tui -Wimplicit -Wreturn-type -Wcomment -Wtrigraphs -Wformat -Wparentheses -Wpointer-arith -Wuninitialized sparc-nat.c sparc-nat.c: In function `fetch_inferior_registers': sparc-nat.c:115: error: structure has no member named `r_ps' sparc-nat.c:117: error: structure has no member named `r_pc' sparc-nat.c:119: error: structure has no member named `r_npc' sparc-nat.c: In function `store_inferior_registers': sparc-nat.c:266: error: structure has no member named `r_ps' sparc-nat.c:268: error: structure has no member named `r_pc' sparc-nat.c:270: error: structure has no member named `r_npc' sparc-nat.c: In function `fetch_core_registers': sparc-nat.c:326: error: structure has no member named `r_ps' sparc-nat.c:327: error: structure has no member named `r_pc' sparc-nat.c:328: error: structure has no member named `r_npc' make[1]: *** [sparc-nat.o] Error 1 building on an UltraSPARC via the sparc32 personality. ... further investigation shows that at some time in the distant past, something, somehow replaced the sparc32 reg.h in my copy of the kernel sources with the sparc64 one. (Probably it was me in an earlier debugging run, by accident.) Because my kernel is sparc64 and nothing much other than GDB uses this header in userspace, I'd not noticed. Putting the sparc32 reg.h back, combined with code to use the right kernel headers for the target (i.e. sparc32) made everything work. If your bug has similar causes to mine --- at least one sparc64 header being picked up instead of a sparc32 one, in a 32-bit userspace --- I'd call this user error. I'd also call the sparc64 reg.h header `not ready for gdb' since symbols present since at least 1989 which gdb relies on are not there. (It probably makes sense to replace the kernel headers in /usr/include/asm with something like the multi-personality jiggery-pokery normally used to build glibc, i.e. autogenerated headers looking like #ifndef __MULTIUNIVERSE__REG_H__ #define __MULTIUNIVERSE__REG_H__ #ifdef __arch64__ #include "sparc64/reg.h" #else #include "sparc/reg.h" #endif #endif /* !__MULTIUNIVERSE__REG_H__ */ and all the sparc64 and sparc32 headers in the appropriate subdirectories. If you've not done that, you could also find yourself picking up sparc64 headers instead of sparc32 ones, and getting bitten by this. If you're using a Linux distro of some kind, I'd imagine they've already done this.) -- `If you want a vision of the future, it is a wireless broadband network feeding requests for foreign money-laundering assistance into a human temporal lobe, forever. With banner ads.' --- John M. Ford