This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [PATCH] Don't set TEXT_START_ADDR for MIPS n64
On Sun, 29 Jun 2008, Richard Sandiford wrote:
> My point is that there _is_ a negative impact for pure n64 binaries.
> As of 4.2, GCC tries to use absolute references in executables if we
> know it's safe to do so. For example:
>
> static int x;
> int get_x (void) { return x; }
>
> can use %hi/%lo-style accesses to refer to "x". It can also use
> absolute accesses to set up $gp in functions that still need it.
>
> This behaviour (selected by -mno-shared) changes the ABI of ET_REL
> objects but it does _not_ change the ABI of the final executable.
> The option simply changes internal details of the executable, such as
> whether it calls via a JAL instead of via a local GOT entry, or whether
> it loads a symbol value using %hi and %lo instead of relying on the GOT.
> GCC 4.3 and above use this mode whenever you configure for sufficiently
> recent binutils.
>
> When it comes to n64, there is little benefit to using absolute
> accesses for 64-bit symbols; it is often cheaper to load from the GOT.
> Thus -mno-shared only does something useful if you compile with -msym32.
What you are referring to is not a pure n64 binary. The ABI specifies
the use of GOT for all symbols, both local and external, by means of
%got_disp() and %got_page()/%got_ofst() relocations. As GOT entries are
64-bit, there is no visible difference resulting from the exact bit
pattern stored there. Anything beyond this is not pure n64, though
certainly it can be useful.
> So when passed "-mabi=64 -O", GCC 4.3 generates:
>
> lui $3,%hi(%neg(%gp_rel(get_x)))
> daddu $3,$3,$25
> daddiu $3,$3,%lo(%neg(%gp_rel(get_x)))
> ld $2,%got_page(x)($3)
> j $31
> lw $2,%got_ofst(x)($2)
>
> When passed "-mabi=64 -O -msym32", GCC 4.3 generates:
>
> lui $2,%hi(x)
> j $31
> lw $2,%lo(x)($2)
>
> As I said above, the second version can still produce a pure n64 binary,
> so -msym32 is already useful for such binaries. The problem is that
> you cannot link such an object with the default scripts, because the
> text address is set so high. The question then is: should the onus be
> on users of -msym32 to change the default, or should the onus be on
> those who want a +4GB start address to change the default? I think the
> former is the more user-friendly option. And I think it's the most
> friendly option even without the non-PIC support mentioned yesterday,
> although that does IMO tip the scales even more.
What I am suggesting is the use of "-msym32" should select an alternative
linker script. This way your newly-introduced ABI will not have a
negative impact on the existing one.
> Yes, changing the start address has a user-visible effect, just as
> changing the number of instructions in (say) printf() has a user-visible
> effect. I don't think either changes the ABI. Nothing should rely on
> printf() having a certain number of instructions, and nothing should
> rely on the start address being exactly 120000000. Code that wants to
> know the size of printf() should look at the symbol info, and code that
> wants to know the load addresses should read them from the program headers.
> I think the ABI simply defines a range of valid load addresses, and the
> new address is just as valid as the old one.
Well, if you *have* to change the start address (which is a valid XUSEG
address) so that the resulting binary is usable at all, then this is a
serious change of the ABI. I insist on this getting sorted out properly.
Maciej