Philip Guenther <guent...@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 _______________________________________________ gmp-devel mailing list gmp-devel@gmplib.org http://gmplib.org/mailman/listinfo/gmp-devel