Amd64 relocation R_X86_64_32S in a static lib

[Torbjorn Granlund]

Philip Guenther <guenther at gmail.com> writes:

  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.
  
I am aware of that people have started using "PIE" as a novel term for
PIC, sometimes with a subtle difference in meaning, sometimes with the
exact same meaning.  It is however evident that you're making some much
larger distinction.  Which one?

  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.
  
Now I get really confused.  You disallow R_X86_64_32S which is of the
type S + A but allow R_X86_64_64 which is also of the type S + A.  That
simply makes no sense at all.

If you allow R_X86_64_64 in a relocatable executable, that you will need
load-time patching, which precludes any sharing.  That's bad.  But then
why not allow R_X86_64_32S too?

Now we have (at least) two OpenBSD ABIs for AMD64, pre 5.3 and now 5.3,
5.4.  To make sense of things, I would not be surprised to see
R_X86_64_64 banned from 5.5 and on, creating a 3rd OpenBSD AMD64 ABI.

What was the exact decision for the change in 5.3.  Is it spelled out
somewhere for me to read?  As I wrote, the "seems to work" approach
isn't good for me, I prefer to do software engineering in a slightly more
analytical manner.

Is there some code which will work for all OpenBSD AMD64 releases?
E.g., can I count on a PLT and GOT always?  I really don't want to
support many ABIs for one OS, such support tend to be fragile.

Torbjörn