Amd64 relocation R_X86_64_32S in a static lib
tg at gmplib.org
Wed Nov 6 23:06:59 CET 2013
"Exact decision for the change"? I'm not sure what you mean by 'decision'
there. If you're wondering about the _reason_ for the change (why we did
it), the answer is so that ASLR is applied not just to the code in shared
libraries but also the code in executables. If you're wondering what was
done to implement the change, the part that seems to be annoying you is
that in 5.3 the default for gcc is to pass -fpie to the C compiler and
-pie to the linker.
I am not annoyed. I am trying to understand the ABI change. Once I
have done that, I will carefully adhere to it.
The change makes be quite worried, since it *seems* to be done without
proper understanding of the issues involved. Furthermore, the ABI
change has not been properly announced, and the new ABI seems to be
That in turn makes me expect further ABI changes in future OpenBSD
releases, which will likely break our code again.
When GMP works incorrectly, then people tend to care very little whether
it is due to a GMP bug, or due to platform problems.
Yes, you can. If you look at libc.a, for example, you'll see it contains
R_X86_64_GOTPCREL and R_X86_64_PLT32 relocations. Those work both when
building a PIE executable and when building a fully static non-PIE
executable. In the latter case they are resolved by the linker when
generating the executable.
Are you telling me that the most future-proof code would be all-PIC in
the *static* GMP build? Should we perhaps stay away from R_X86_64_64
(also in a static lib)?
In the absense of documentation, could you tell which of the relocs on
page 71 of the official AMD64 ELF ABI are to be supported on OpenBSD
from now and on?
More information about the gmp-devel