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

[Richard Sandiford]

Maxim Kuvyrkov <maxim@codesourcery.com> writes:
> On 16/11/2012, at 11:39 AM, Richard Sandiford wrote:
>> <Paul_Koning@Dell.com> writes:
> ...
>>> The interesting case is where a program executes without immediately
>>> crashing, but because it uses 32-bit addresses it does some wrong things
>>> -- writing wrong data into a database, or things like that.  So this
>>> isn't a case of lecturing, it's a security improvement.
>> 
>> People who want that can still ask for it, just as people who want
>> address santisation, stack protection, PIEs, etc., can ask for
>> those features.
>
> 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.

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.

As for the first part, I agree the current address isn't terribly broken.
The one before it wasn't either though.  Both values of TEXT_START_ADDR
are valid from an ABI perspective.

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.

Richard