On Wed, 6 Nov 2013, Torbjorn Granlund wrote: ... > The change makes be quite worried, since it *seems* to be done without > proper understanding of the issues involved.
Appearances can be deceiving. > Furthermore, the ABI change has not been properly announced, I guess the release announcement wasn't enough? > and the new ABI seems to be undocumented. Please file that bug upstream with GNU binutils, as they are the ones that have set the behavior of the -pie option. > That in turn makes me expect further ABI changes in future OpenBSD > releases, which will likely break our code again. Looking at the total ABI, including such things as types definitions and kernel syscalls, I can _guarantee_ that it'll change. Indeed, for 5.5 the type of time_t, clock_t, and ino_t has been changed to be long long on all archs, changing the size of many structures and rolling new syscall numbers. But I don't think that that's the level you're talking about. The low-level ABI of register use and accepted relocations changes much more rarely. We'll probably get TLS support hammered out in a way we're happy with at some point, which will affect the %fs register of course, but that's about the only thing at that level I can think of in the pipeline, and it's doesn't affect existing code anyway. > 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)? Yes, and yes. > 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? I would love to see that information from the binutils people as well. Philip