Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
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


  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