Amd64 relocation R_X86_64_32S in a static lib
guenther at gmail.com
Tue Nov 5 08:11:22 CET 2013
On Tue, 5 Nov 2013, Torbjorn Granlund wrote:
> I am working on getting the GMP bignum library to work better on
> With current GMP sources (GMP 5.0.x, 5.1.x, and development head) a
> 'fat' build will not work on amd64 under OpenBSD 5.3 and 5.4. With
> older version of OpenBSD (I've tested 4.9, 5.0, 5.2) things work as
> The problem is related to relocs, in particlar R_X86_64_32S which we use
> in a GMP assembly file for 'fat' binaries.
> On the problem OpenBSD releases, a fat GMP build end with this error:
> libtool: link: gcc -std=gnu99 -O2 -pedantic -fomit-frame-pointer -m64 -o t-bswap t-bswap.o ./.libs/libtests.a /var/tmp/gmp-obj/hannahobsd64v53-stat-fat/.libs/libgmp.a ../.libs/libgmp.a
> /usr/bin/ld: /var/tmp/gmp-obj/hannahobsd64v53-stat-fat/.libs/libgmp.a(fat_entry.o): relocation R_X86_64_32S can not be used when making a shared object; recompile with -fPIC
> /var/tmp/gmp-obj/hannahobsd64v53-stat-fat/.libs/libgmp.a: could not read symbols: Bad value
> The error message is strange, considering that we certainly are not
> "making a shared object". We are linking a plain object with a static
Ah, but you are, sorta. In OpenBSD 5.3, platforms where the compiler and
toolchain support were for robust for it were switched to build PIE
objects and executables by default. So yes, that object _is_ expected to
be position independent. c.f. the gcc-local(1) manpage.
At least on OpenBSD, the processor will define __PIC__ and __pic__ when
building both PIC _and_ PIE objects, so you can test those to determine
whether the ASM should use position-independent code sequences.
(If you _really_ need to know whether it's building PIE (and not PIC) you
can check for __PIE__ or __pie__, but that's rarely useful. Indeed, there
are _no_ tests for those in the OpenBSD base tree right now.)
At least some Linux distributions, PIE is used for system executables and
you can build your own programs with -fpie -pie (check their docs) to
enable it in your own.
> I consider this a major deviation from the established AMD64 ELF ABI.
> It's your decision, and I will not try to make you change your minds.
> But I need to understand the decision and how you intend to proceed.
> Do you have a document describing the "AMD64 OpenBSD ABI" with which
> developers could comply?
As I understand it, it's the "standard" amd64 PIE ABI.
> * It seems R_X86_64_64 works in non-PIC code such as in the GMP example,
> and while slower than R_X86_64_32S, GMP could use it as a workaround.
> But do you intend to keep that working, or do you intend to completely
> de-support any non-GOT data references?
R_X86_64_64 is safe for use in PIC/PIE code, though I would expect %rip
relative addressing to be more efficient when it's applicable.
More information about the gmp-devel