From mboxrd@z Thu Jan 1 00:00:00 1970 From: Geoff Keating To: ulfc@calypso.engr.sgi.com Cc: binutils@sourceware.cygnus.com Subject: Re: [rfc] For mips, sign-extended ecoff offsets Date: Mon, 19 Jun 2000 21:30:00 -0000 Message-id: <200006200430.VAA10600@localhost.cygnus.com> References: <394EC637.24300B87@cygnus.com> <14670.52424.697477.308492@calypso.engr.sgi.com> <200006200307.UAA10516@localhost.cygnus.com> <14670.59816.517716.492387@calypso.engr.sgi.com> X-SW-Source: 2000-06/msg00400.html > From: Ulf Carlsson > Date: Mon, 19 Jun 2000 20:48:56 -0700 (PDT) > > > > 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). > > We always have 0x87654321 in the 32-bit ELF file. It probably doesn't > matter what our internal representation is since we'll drop the upper > 32 bits when we write the ELF file in either case and the address will > be properly sign extended again when the ELF file is loaded. A similar argument was used originally to justify not forcing BFD to do the right thing. An example where it does matter is when you try to work out whether a 32-bit pc-relative operand can hold the offset from 0x10000000 to 0xA0000000, or whether there should be overflow. In GDB, it matters whenever you are comparing a value in a register to an address in the object file. -- - Geoffrey Keating