This is the mail archive of the
gdb-patches@sourceware.cygnus.com
mailing list for the GDB project.
Re: [rfc] For mips, sign-extended ecoff offsets
- To: Alan Modra <alan at linuxcare dot com dot au>
- Subject: Re: [rfc] For mips, sign-extended ecoff offsets
- From: Andrew Cagney <ac131313 at cygnus dot com>
- Date: Tue, 20 Jun 2000 12:23:04 +1000
- CC: BINUTILS Patches <binutils at sourceware dot cygnus dot com>, GDB Patches <gdb-patches at sourceware dot cygnus dot com>
- Organization: Cygnus Solutions
- References: <Pine.LNX.4.21.0006201128050.12273-100000@front.linuxcare.com.au>
Alan Modra wrote:
>
> On Tue, 20 Jun 2000, Andrew Cagney wrote:
>
> > > I'm worried about what happens if things like PDR.adr get changed from
> > > 0xa0000000 to 0xffffffffa0000000.
> >
> > Thats why I'm asking :-) Remember though, on the MIPS platform, if
> > ``PDR.adr'' is an address then, the canonical form of the value
> > ``0xa0000000'' obtained from an elf32 binary is 0xffffffffa00000000.
> > GDB and BFD have, for too many years, been bribed and cajoled into
> > perpetuated the lie that MIPS doesn't sign extend addresses. GDB's now
> > decided to come clean on this matter (and purge an amazing amount of
> > bogus code :-).
>
> Well, it's the likelihood of other "bogus code" existing in binutils that
> assumes addresses are _not_ sign extended that worries me. If you work to
> the "You break it, you fix it" rule, then you may be taking on quite a bit
> of work :-)
I can help to an extent, however, to be honest, I'm having enough fun
just re-stablizing the the GDB side of the MIPS. Consequently I'd be
focusing on GDB specific problems. People on the BFD/MIPS side will
need to be willing to help if there is fallout.
> > Any way I've attached a revised patch. I wasn't ruthless enough the
> > first time.... With this revision the linker appears to work :-)
> > Testing is continuing.
>
> There's an ECOF_ typo still in a comment.
Thanks.
> > I guess the question for BFD people is, is this the correct approach to
> > fixing this bug?
>
> I'd like to hear Ian's comments on this before you check it in.
Ian has a long memory (Nick does to :-) and both would be very familar
with the underlying problems and the very long history that is behind
this :-)
Andrew