Amd64 relocation R_X86_64_32S in a static lib

[Torbjorn Granlund]

  "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
undocumented.
  
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?

-- 
Torbjörn