This is the mail archive of the gdb-prs@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: build/955: build failure with GDB-5.3: sparc-nat.c structureredefinition errors with sparc64-linux, glibc-2.2.x


The following reply was made to PR build/955; it has been noted by GNATS.

From: Nix <nix@esperi.org.uk>
To: Christian Joensson <c.christian.joensson@comhem.se>
Cc: GDB list <gdb@sources.redhat.com>, 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
Date: Wed, 08 Oct 2003 08:29:05 +0100

 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]