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

Nix nix@esperi.org.uk
Wed Oct 8 07:29:00 GMT 2003


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



More information about the Gdb-patches mailing list