Re: [PATCH][MIPS] Add linker emulation for N64 ABI with forced 32-bit symbols

[Richard Sandiford <rdsandiford at googlemail dot com>]

"Maciej W. Rozycki" <macro@codesourcery.com> writes:
> On Fri, 16 Nov 2012, Richard Sandiford wrote:
>
>> > Given that the current default for starting address for N64 ABI is not
>> > terribly broken, I don't think we should change it for the sake of
>> > unifying ABIs.
>> >
>> > On the other hand, should we consider enabling -mplt -msym32 /by
>> > default/ for N64 ABI (as there are performance advantages to that), then
>> > we would have a clear argument to simultaneously change the default
>> > starting address for N64 ABI too.
>> 
>> Sorry, I don't agree with the last part.  For one thing, there's never a
>> single default with these things.  Debian's default isn't necessarily
>> the same as FSF GCC's, for example.
>> 
>> But more importantly, -msym32 has always been a per-object compile-time
>> option rather than a link-time option.  You can link -msym32 objects
>> with non-msym32 objects.  The resulting executable needs to follow
>> "-msym32" rules if any one of its objects does.  I don't think it's
>> appropriate to use emulations for something like that, since emulations
>> have to be chosen up-front.
>
>  That's an interesting point, I haven't considered mixing -msym32 and 
> -mno-sym32 objects in a single static link.  But is it really supported 
> for Linux targets?
>
>  First, I reckon we do not support "-64 -mplt -mno-sym32" executables (do 
> we?) and -mplt are not static-link-compatible with -mno-plt objects 
> (different ABIs).
>
>  Second, do we support "-64 -mabicalls -msym32" executables?  I believe 
> that makes no sense as to do anything that'd require 32-bit GOT, and that 
> in turn would be incompatible with symbols defined in shared modules.

Yeah, we support it.  As you say, it deliberately doesn't change the GOT
size, because -msym32 on its own isn't supposed to change the ABI of the
final executable (as opposed to the ET_REL inputs).  But it's useful in
combination with -mno-shared, which has been the FSF GCC default for a
while now.  E.g. if you compile:

int x = 1;
int *foo (void) { return &x; }

with "mips64-linux-gnu-gcc -mabi=64 -msym32" you get:

        lui     $2,%hi(x)
        j       $31
        daddiu  $2,$2,%lo(x)

>> E.g. as things stand, you can't link an -msym32 archive into a project that
>> happens to be compiled without -msym32.  Your patch doesn't change that,
>> but reverting to the old TEXT_START_ADDR does.
>
>  Well, assuming that the ABIs of the -msym32 and -mno-sym32 objects are 
> somehow compatible after all, such linking will work if you use the new 
> emulation proposed here, that amounts to selecting the old address.  
> However if you find that unacceptable, then I'd be happier with the linker 
> switching between the two load addresses automagically somehow based on 
> -msym32 objects seen.  I reckon we have an ELF file header flag for that.

I wondered if someone would suggest this, and yeah, I agree it's more
acceptable than the new emulations _in principle_ (but see below).
I think a new .gnu_attribute would be more appropriate than a new ELF
flag though, since it's a link-time rather than run-time distinction.

But then the question becomes: what should be the default be if one
of the objects being linked doesn't use the new attribute?  Again,
I think the default should be the 32-bit address, since that's the
one that copes correctly with all inputs.  Users aren't going to be
served well by a toolchain that silently mislinks -msym32 objects
that lack the attribute, especially since attributes aren't things
that users should have to worry about.

So that would leave us only picking the high address if all input
objects have an attribute to say that a high address is OK.
I don't think anyone who's serious about security will want
to rely on something so indirect.  And who else would benefit?
My point in quoting the x86_64, ppc64 and s390x cases is that
there doesn't seem to be a big demand for this.  It's by no means
clear whether having the start address vary based on such attributes
is going to help more than confuse.

So I still think that the default start address should be set to
correctly link all (in this case, both) types of input.  Anyone who
wants a higher address can ask for it.  I'd be happy with a new option
to make that easier, if -Ttext is too baroque or doesn't in fact work.

Richard