Relocation error in 64bit ELF object file

[TasosKL]

Hi, all
Using uasm 2.57 to assemble this code

		.DATA

String		BYTE	"0123456789"

		.CODE

Start:		MOV	RDX, 1
		MOV	AL, String[ RDX ]
		MOV	AL, String[ 1 ][ RDX ]
		XOR	RDI, RDI
		MOV	RAX, 3Ch
		SYSCALL

		END 

results in executable code that in both cases loads AL with the same value.
Searching a bit, I found that it is a relocation problem, that is, using objdump
on the produced object file gives the following output:

RELOCATION RECORDS FOR [.text]:
OFFSET           TYPE              VALUE 
0000000000000009 R_X86_64_32       String
000000000000000f R_X86_64_32       String

Assembling the same code with GNU as

		.data

String:		.ascii	"0123456789"
 
		.text

Start:		MOV	RDX, 1
		MOV	AL, String[ RDX ]
		MOV	AL, String[ 1 ][ RDX ]

		XOR	RDI, RDI
		MOV	RAX, 0x3C
		SYSCALL

		.end 

the executable code loads the correct value in AL. The output of objdump is

RELOCATION RECORDS FOR [.text]:
OFFSET           TYPE              VALUE 
0000000000000009 R_X86_64_32S      .data
000000000000000f R_X86_64_32S      .data+0x0000000000000001

which shows that the second relocation entry has an addend of 1.
Can you help?

[john-terraspace]

Hi,

I'm surprised that worked at all to be honest, VariableName[Rn*scale] type addressing is largely unsupported in 64bit in favour of using RIP relative forms - avoiding relocations as far as possible. I don't think this would even assemble for Windows 64bit as there is no relocation type for it.

Firstly I think UASM looks like it should be using the 32S relocation variant.
See: https://stackoverflow.com/questions/33318342/when-is-it-better-for-an-assembler-to-use-sign-extended-relocation-like-r-x86-64

[TasosKL]

Hi, John
Thank you for your reply.
The point is I cannot use RIP relative addressing as the data is in another section.
The example at SO is unrelated to my case, as the label in the example is in the code section.
Now, regarding my code and Windows 64bit, it does assemble and, after linking, produces
the correct code, ie AL is loaded with the correct value in both cases.
Anyway, I will do some more searching, and will be back.

[TasosKL]

Hi, John
The problem is definitely due to UASM.
I patched the addend field of the relocation entry with a hex editor and it works OK no matter what is
in the code section of the object file. So the problem is in the way the relocation entry is put in the object file,
it omits the addend.
Any ideas?

[john-terraspace]

Yep, clearly when UASM generates the relocation entry it’s just not using the addend field properly – this part is basically unchanged since JWASM days so I’ll need to dig in and have a look at where the reloc is generated and why it ignores the addend. My guess is that it pre-calculates from the EA the symbol address + immediate displacement – what I’d be curious to see, if you patch the relocation to have addend of 0 but change the location/target offset should the result not be exactly the same (at least execution wise) – from a debugger obviously it would imply something different as it probably correlates the symbol’s base address and addend to be an index from that point. From: TasosKL ***@***.***> Sent: 05 September 2024 16:42 To: Terraspace/UASM ***@***.***> Cc: John Hankinson ***@***.***>; Comment ***@***.***> Subject: Re: [Terraspace/UASM] Relocation error in 64bit ELF object file (Issue #212) Hi, John The problem is definitely due to UASM. I patched the addend field of the relocation entry with a hex editor and it works OK no matter what is in the code section of the object file. So the problem is in the way the relocation entry is put in the object file, it omits the addend. Any ideas? — Reply to this email directly, view it on GitHub <#212 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEAZAVFLXXVRD6UYDIW3K4LZVB3TXAVCNFSM6AAAAABNO7DRVKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMZSGA3TANRUGY> . You are receiving this because you commented. <https://github.com/notifications/beacon/AEAZAVH42X4CZ5FA4UTXDHDZVB3TXA5CNFSM6AAAAABNO7DRVKWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTULACJPM.gif> Message ID: ***@***.*** ***@***.***> >

[TasosKL]

Hi, John
I did the tests you suggested and the results are:

• Setting the addend to 0 and changing the location/target offset to any value has no effect, even when I used extreme values like 7FFFFFFFh or 0FFFFFFFFh.
• Setting the addend to a value like 1 or 2 and changing the location/target offset to any value, loads the value that corresponds to the addend, i.e. "2" for an addend of 1, "3" for 2 etc

Looking at the history file i found that there is the following change in JWASM:

03/02/2011, v2.05:

• ELF64 format: relocations were stored in sections of type SHT_REL. Changed to SHT_RELA.

Hope this helps.