From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ralf Baechle To: ulfc@calypso.engr.sgi.com, ac131313@cygnus.com, alan@linuxcare.com.au, binutils@sourceware.cygnus.com, gdb-patches@sourceware.cygnus.com, geoffk@cygnus.com Subject: Re: [rfc] For mips, sign-extended ecoff offsets Date: Sun, 25 Jun 2000 14:13:00 -0000 Message-id: <20000625224009.A3529@bacchus.dhis.org> References: <394EC637.24300B87@cygnus.com> <14670.52424.697477.308492@calypso.engr.sgi.com> <200006200307.UAA10516@localhost.cygnus.com> <20000620034102.18244.qmail@daffy.airs.com> X-SW-Source: 2000-06/msg00531.html On Mon, Jun 19, 2000 at 08:41:02PM -0700, Ian Lance Taylor wrote: > > On a 64-bit MIPS processor 32-bit addresses are of course sign > > extended, but this shouldn't concern the 32-bit BFD backend for MIPS > > in any way. Whether we sign extend the addresses or not shouldn't > > make any difference except in our internal representation of the > > bfd_vma. I may be wrong though! > > The 64-bit MIPS machines often use the 32-bit ELF format, typically > because they have 32-bit memory addresses (I forget whether trying to > access 0x0000000087654321 gives you 0xffffffff87654321 or a trap). > > I think the real reason this happens is historical--because we didn't > have a 64-bit MIPS format when we started supporting 64-bit MIPS > chips. I don't think there is any particularly legitimate reason to > use a 32-bit format for a 64-bit chip. We do that for Linux/MIPS64. Originally I came up with this due to the incredible brokeness of ld for 64-bit MIPS ELF. It allows us to generate 64-bit code that is more compact than standard 64-bit code because dla get expanded to only 2 instructions like in 32-bit code. All it takes is proper placement of the code into the 32-bit address space. We still have kept the advantages of 64-bit code. Ralf