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 07:29:00 -0000 [thread overview]
Message-ID: <87wubggpby.fsf@amaterasu.srvr.nix> (raw)
In-Reply-To: <20030825085704.A14976@u1sparc.j-son.org> (Christian Joensson's message of "Mon, 25 Aug 2003 08:57:04 +0200")
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
next prev parent reply other threads:[~2003-10-08 7:29 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20030427150800.19859.qmail@sources.redhat.com>
2003-04-27 20:45 ` Daniel Jacobowitz
2003-04-27 22:03 ` c.christian.joensson
2003-05-10 7:57 ` Christian Joensson
2003-05-10 13:35 ` Christian Joensson
2003-05-10 21:30 ` Nix
2003-08-25 6:57 ` Christian Joensson
2003-10-08 7:29 ` Nix [this message]
2003-10-08 7:40 ` Christian Joensson
2003-10-08 9:03 ` Nix
2003-10-09 0:47 ` Michael Snyder
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87wubggpby.fsf@amaterasu.srvr.nix \
--to=nix@esperi.org.uk \
--cc=c.christian.joensson@comhem.se \
--cc=gdb-gnats@sources.redhat.com \
--cc=gdb-patches@sources.redhat.com \
--cc=gdb@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox