flat assembler
Message board for the users of flat assembler.

Index > Linux > [fasmg][elf64] PIE and R_X86_64_32S

Author
Thread Post new topic Reply to topic
sylware



Joined: 23 Oct 2020
Posts: 57
Location: Marseille/France
sylware
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)
Post 20 Aug 2021, 16:16
View user's profile Send private message Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 3290
Location: vpcmipstrm
bitRAKE
I'm guessing that:
\fasmg\packages\x86\include\format\elf64.inc
Code:
@@ -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    
... 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.

_________________
¯\(°_o)/¯ unlicense.org
Post 20 Aug 2021, 19:23
View user's profile Send private message Visit poster's website Reply with quote
sylware



Joined: 23 Oct 2020
Posts: 57
Location: Marseille/France
sylware
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.


Last edited by sylware on 20 Aug 2021, 20:54; edited 2 times in total
Post 20 Aug 2021, 20:07
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7925
Location: Kraków, Poland
Tomasz Grysztar
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).
Post 20 Aug 2021, 20:44
View user's profile Send private message Visit poster's website Reply with quote
sylware



Joined: 23 Oct 2020
Posts: 57
Location: Marseille/France
sylware
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.
Post 20 Aug 2021, 21:19
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.

Website powered by rwasa.