Incorrect function address calc (maybe?)

[Zeno343]

I hit a segfault issue trying to change up my build process a bit.

Long story short, I've narrowed the problem down to the first function call to anything linked from outside the main obj file. In this case, moving my function from the same file as main() to a different .o introduces a segfault on the call instruction and the calculated address looks wrong to me, but that's where my knowledge runs dry. it seems like the address of all the call instructions are off by a few bytes but I could be misreading or misinterpreting GDB output.

Relevant, my debugging symbols are borked per #14 and the stack trace is frankly dizzying without them.

If you give me a hint I can probably figure out the fix and PR it, I've been using this thing a bit and I want to better understand it, would enjoy contributing.

[Zeno343]

Here's the main fn from my Rust produced object file, up to the offending call instruction:

Disassembly of section .text.main:

0000000000000000 <main>:
   0:	55                   	push   %rbp
   1:	41 57                	push   %r15
   3:	41 56                	push   %r14
   5:	41 55                	push   %r13
   7:	41 54                	push   %r12
   9:	53                   	push   %rbx
   a:	48 83 ec 18          	sub    $0x18,%rsp
   e:	48 8d 3d 00 00 00 00 	lea    0x0(%rip),%rdi        # 15 <main+0x15>
			11: R_X86_64_PC32	.L__unnamed_1-0x4
  15:	48 8d 35 00 00 00 00 	lea    0x0(%rip),%rsi        # 1c <main+0x1c>
			18: R_X86_64_PC32	.rodata..L__unnamed_2-0x4
  1c:	ba 05 00 00 00       	mov    $0x5,%edx
  21:	ff 15 00 00 00 00    	call   *0x0(%rip)        # 27 <main+0x27>
			23: R_X86_64_GOTPCREL	_ZN3_643sys5utils7LinuxFd5write17hdc3d517057bbf3a1E-0x4

the debug symbols in gdb are borked but:

   0x104e0 <rust_eh_personality>:	push   %rbp
   0x104e1:	push   %r15
   0x104e3:	push   %r14
   0x104e5:	push   %r13
   0x104e7:	push   %r12
   0x104e9:	push   %rbx
   0x104ea:	sub    $0x18,%rsp
   0x104ee:	lea    0xdb(%rip),%rdi        # 0x105d0 <main+208>
   0x104f5:	lea    0xdc(%rip),%rsi        # 0x105d8 <main+216>
   0x104fc:	mov    $0x5,%edx
   0x10501 <main+1>:	call   *-0x77(%rip)        # 0x10490 <_ZN3_646window6Window4swap17h5b85cb1280007f74E>

Checking out that address it's definitely not the 0x10490 where the write syscall starts.

(gdb) x/8 0x10501 - 0x77
   0x1048a:	add    %cl,(%rdi)
   0x1048c:	(bad)  
   0x1048d:	add    %r8b,(%rax)
   0x10490 <_ZN3_646window6Window4swap17h5b85cb1280007f74E>:	push   %rax
   0x10491 <_ZN3_646window6Window4swap17h5b85cb1280007f74E+1>:	mov    (%rdi),%edi
   0x10493 <_ZN3_646window6Window4swap17h5b85cb1280007f74E+3>:	mov    $0x1,%eax
   0x10498 <_ZN3_646window6Window4swap17h5b85cb1280007f74E+8>:	syscall 
   0x1049a:	mov    %rax,%rcx

[PoroCYon]

Oof, I somehow never noticed this issue, sorry for that. Are you still having this issue now?

[Zeno343]

Oh hi there 🤣

It's been a while but if I remember correctly it was a stack alignment issue and fiddling with the relevant flags fixed it

[PoroCYon]

Alright, guess I'll close it hten.