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

[Maciej W. Rozycki]

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.

 Have I missed anything?

> 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.

> The patch is posted isn't OK because the new emulation has no test
> coverage.  Adding extra emulations also has an overhead in terms of
> testsuite maintenance.

 That's true, I agree.

  Maciej