Hi,

I am linking fasmg a elf64 object file with the GNU linker to create a PIE executable, but the latter tells me that it cannot link a PIE executable because of R_X86_64_32S relocations.
How can I remove the usage of such relocation without breaking fasmg correct code generation?
(have 0 experience on the matter)

I'm guessing that:
\fasmg\packages\x86\include\format\elf64.inc
... could be modified to disable those type of relocations.

Someone more experienced with ELF might have better advice.

It seems related to a similar problem in windows.

yep, I was looking exactly at those lines of code, but beyond ELF relocation understanding, I am trying to figure out what the "check" line means. I did look at polynomials (actually, those polynomials have a max degree of 1, but can be multivars) and metadata and I was trying to understand how those concepts were used to build ELF data.
Still dunno how to work around this relocation type.

It seems the "value" has its "metadata" being a polynomial: the element seems to be "relocatable", its scale would be the section index, its constant would be its index in this very section.
breaking down:
"~ value relativeto 0" seems to mean that value is a polynomial with a non-0 variable part (at least 1 scale on its elements is non-zero)
"value relativeto 1 elementof value" seems to enforce that value has only 1 element with a non-zero scale.
"1 metadataof value" is the metadata of the first element of polynomial value. In this very case, it means the metadata of the only element with a non-zero scale of value.
"1 elementof (1 metadataof value) relativeto ELF.relocatable" seems to mean the metadata of value, which would be a polynomial, has a non-zero scaled ELF.relocatable element.

By removing that check and jump as suggested by bitRAKE you would make the instructions that need this kind of relocation to signal an error - is this what you wanted, to find out which instruction in your code needs correcting?

In general you may need to use GOT-based relocations for position independent code (fasm/fasmg implement them with the "rva" operator, see the old thread about the 32-bit case).

I don't really understand why R_X86_64_32S is not RIP relative, and if so why I have such relocations. I guess the code I am porting to fasmg does generate R_X86_64_32S. I am not supposed to use the GOT (no "global data" yet), only the PLT for the moment.
Yep, I would need to locate in the code being ported which instructions are doing just that.

missing some "mov rax, [rip+symbol]"

----

I assembled an error message in the CALM instruction, and got one of the guilty lines: indeed, the code I am porting is building some jump tables not RIP relative friendly.

That's closing the issue I guess.

thx for your help.