Base address of executables - weirdness?
I'm trying to track down an odd issue with klibc on ppc32.
Until recently, binaries linked with ld defaulted to a base address of 0x10000000+SIZEOF_HEADERS. However, recently I've gotten a couple of reports -- and I've been able to confirm this on my FC5 system -- that some versions of ld links at 0x01800000+SIZEOF_HEADERS. Needless to say, this is more than a bit confusing, *especially* since "ld -verbose" still reports:
PROVIDE (__executable_start = 0x10000000); . = 0x10000000 +
SIZEOF_HEADERS;
... at the top of the linker script.
I'm rather baffled. Has anyone else seen this, and/or have any other explanation?
-hpa
Quoted 10 lines · Linas Vepstas
Quoted 9 lines · H. Peter Anvin
I'm trying to track down an odd issue with klibc on ppc32.
Until recently, binaries linked with ld defaulted to a base address of 0x10000000+SIZEOF_HEADERS. However, recently I've gotten a couple of reports -- and I've been able to confirm this on my FC5 system -- that some versions of ld links at 0x01800000+SIZEOF_HEADERS. Needless to say, this is more than a bit confusing, *especially* since "ld -verbose" still reports:
PROVIDE (__executable_start = 0x10000000); . = 0x10000000 +
SIZEOF_HEADERS;... at the top of the linker script.
Quoted 8 lines
Quoted 1 line
I'm rather baffled. Has anyone else seen this, and/or have any other explanation?
Googling "
0x01800000linux ppc" brings up some interesting but old hits.However, I swear I saw someone suggest a patch last week that changed
0x10000000to0x01800000somewhere, (vmlinux.lds??) as a proposed cure for a bug. Sorry, I deleted it.
Well, it's worse than I previously surmised. I can't seem to find any combination of options which work on both affected and unaffected binutils. This is a real mess.
-hpa
Quoted 9 lines · H. Peter Anvin
I'm trying to track down an odd issue with klibc on ppc32.
Until recently, binaries linked with ld defaulted to a base address of 0x10000000+SIZEOF_HEADERS. However, recently I've gotten a couple of reports -- and I've been able to confirm this on my FC5 system -- that some versions of ld links at 0x01800000+SIZEOF_HEADERS. Needless to say, this is more than a bit confusing, *especially* since "ld -verbose" still reports:
Quoted 7 lines
PROVIDE (__executable_start = 0x10000000); . = 0x10000000 +
SIZEOF_HEADERS;... at the top of the linker script.
I'm rather baffled. Has anyone else seen this, and/or have any other explanation?
Googling "0x01800000 linux ppc" brings up some interesting but old hits.
However, I swear I saw someone suggest a patch last week that changed 0x10000000 to 0x01800000 somewhere, (vmlinux.lds ??) as a proposed cure for a bug. Sorry, I deleted it.
--linas
Quoted 4 lines · H. Peter Anvin
Until recently, binaries linked with ld defaulted to a base address of 0x10000000+SIZEOF_HEADERS. However, recently I've gotten a couple of reports -- and I've been able to confirm this on my FC5 system -- that some versions of ld links at 0x01800000+SIZEOF_HEADERS.
You are probably using the wrong linker emulation. There are three emulations enabled when building binutils for ppc-linux, but only the elf32ppclinux emulation it the right one that uses 0x10000000 for the base address.
Andreas.
Signature · 4 lines
Andreas Schwab, SuSE Labs, [email protected] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Quoted 9 lines · Andreas Schwab
Quoted 1 line · H. Peter Anvin
Until recently, binaries linked with ld defaulted to a base address of 0x10000000+SIZEOF_HEADERS. However, recently I've gotten a couple of reports -- and I've been able to confirm this on my FC5 system -- that some versions of ld links at 0x01800000+SIZEOF_HEADERS.
You are probably using the wrong linker emulation. There are three emulations enabled when building binutils for ppc-linux, but only the elf32ppclinux emulation it the right one that uses
0x10000000for the base address.
Hm. Well, it's using the default one, but perhaps I should try to specify an explicit -m option. Sure enough, that did the trick.
THANKS!
-hpa