This is the mail archive of the
mailing list for the binutils project.
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:
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
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.