This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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



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




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]