On 06/24/2011 11:19 AM, Agner Fog wrote: > > On 24-06-2011 10:23, Andrew Haley wrote: >> >>> Why does it make 32 bit absolute addresses when I specify >>> -mcmodel=medium? >> Small symbols are placed in the lower 2G. > So I would have to replace all variables with very big arrays in order > to prevent 32 bit addresses in 64 bit mode :-( What problem are you trying to solve? I don't get it. Why would you want to avoid 32-bit absolute addresses? > Is there no way to avoid 32 bit absolute addresses in 64 bit mode other > than -fpic which has the undesired effect of using GOT and PLT entries? > > This is weird: > -fpic doesn't make position-independent code as the name implies - it > makes code that fits into a shared object. That's right. PIC has always been something of a misnomer. > My test code compiled with -fpic or -fPIC still has absolute > references in virtual tables and in the exception handler section in > both 32 and 64 bit mode. PIC code never has writable text sections, but it does have writable data sections. Maybe that's what you're seeing. > -Bsymbolic doesn't seem to do anything. At least it doesn't prevent GOT > entries > > Interestingly, it all works in 32 bit mode. I can compile without -fpic > and make an absolute reference to a global variable with no GOT entry > and no PLT in a shared object and I get no warnings or errors. It just > works. Also, there is no exception handler section even though I did not > turn off exceptions. > > Why is 64 bit mode so different? It's a historical thing. The 32-bit ABI was designed back in the stone age when shared libraries were not always compiled PIC. There is a hack in ld.so that detects a relocation in a shared library, remaps a local copy of the page, and rewrites it. Of course this is pretty gross, since every process that opens the library has its own copy of those relocated pages rather than sharing them. Andrew.
