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] |
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?
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.
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.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |