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

David Daney ddaney.cavm@gmail.com
Thu Nov 15 22:49:00 GMT 2012

On 11/15/2012 02:22 PM, Paul_Koning@Dell.com wrote:
> On Nov 15, 2012, at 5:08 PM, Richard Sandiford wrote:
>> ...
>> Huh.  I'm very much against the original change to the n64 TEXT_START_ADDR.
>> See this previous discussion on the topic:
>>     http://sourceware.org/ml/binutils/2008-06/msg00285.html
>> The justification for changing TEXT_START_ADDR from a 32-bit value to a
>> larger value was that it would show users if their code was non-portable,
>> because anything that assumed 32-bit addresses would now fault.  But that
>> seems to me like the tools lecturing to the user.  As I said in that thread,
>> I think users who want to smoke out such portability problems (by making
>> sure that the lower 4GB aren't mapped) should be the ones who need to do
>> something special.
>> I think we should simply revert to a 32-bit TEXT_START_ADDR for all
>> n64 emulations.  This time I'm even in a position to approve it :-)
> Isn't this an OS question more than an OS-independent tools question?

Not really.  The OS loads the program headers wherever the ELF file 

> Also, I disagree with your description as "lecturing".  The interesting case isn't the one where a correctly working program that happens to misuse 32 bit addresses is turned into a broken one by the current start address rule.

This is a problem.  I think it might be worth considering somehow 
tagging objects that have been compiled with -msym32 and having the 
linker throw an error if any relocations are processed for symbols 
outside of the 32-bit address space.

If we simply move TEXT_START_ADDR back into the 32-bit address space, we 
will have the possibility of silently emitting bad code from the linker.

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

I think this is a real issue.  Imagine a program larger than 2GB, any 
relocations against symbols beyond the 2GB boundary, are silently 
truncated.  The resulting erroneous addresses could easily be pointing 
into validly mapped parts of the program image.

David Daney


More information about the Binutils mailing list