Message board for the users of flat assembler.
> Linux > [fasmg][elf64] PIE and R_X86_64_32S
sylware 20 Aug 2021, 16:16
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)
|20 Aug 2021, 16:16||
bitRAKE 20 Aug 2021, 19:23
I'm guessing that:
... could be modified to disable those type of relocations.
@@ -488,12 +488,12 @@ calminstruction calminstruction?.asm? line& assemble buffer end calminstruction calminstruction dword? value compute value, value (1 metadataof value) relativeto ELF.relocatable +; check ~ value relativeto 0 & value relativeto 1 elementof value & 1 elementof (1 metadataof value) relativeto ELF.relocatable +; jyes r_32
Someone more experienced with ELF might have better advice.
It seems related to a similar problem in windows.
¯\(°_o)/¯ The hardcore cynic mistakes good for guile.
|20 Aug 2021, 19:23||
sylware 20 Aug 2021, 20:07
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.
"~ 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.
Last edited by sylware on 20 Aug 2021, 20:54; edited 2 times in total
|20 Aug 2021, 20:07||
Tomasz Grysztar 20 Aug 2021, 20:44
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).
|20 Aug 2021, 20:44||
sylware 20 Aug 2021, 21:19
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.
|20 Aug 2021, 21:19||
< Last Thread | Next Thread >
Copyright © 1999-2023, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.
Website powered by rwasa.