0

I am writing a compiler and codegen the following code with an error. The question is mov [esi+4], DWORD temp_fun_2 gives a relative address like 0xc5 using gdb, while the real address is something like 0x555f55c5. When I call this address, it gives me a segment error. So how can I solve this problem?

The environment is x86

Thanks in advance.

section .text
extern print
extern error
extern equal
global our_code_starts_here
our_code_starts_here:
  mov esi, [esp+4]
  add esi, 8
  and esi, 0xFFFFFFF8
  push ebp
  mov ebp, esp
  sub esp, 4
  jmp near temp_after_1
temp_fun_2:
  push ebp
  mov ebp, esp
  sub esp, 0
  mov ecx, [ebp+8]
  mov eax, [ebp+12]
  and eax, 1
  cmp eax, 0
  jne near error_non_int
  mov eax, 10
  and eax, 1
  cmp eax, 0
  jne near error_non_int
  mov eax, [ebp+12]
  add eax, 10
  jo near overflow_check
  mov esp, ebp
  pop ebp
  ret
temp_after_1:
  mov [esi+0], DWORD 1
  mov [esi+4], DWORD temp_fun_2
  mov eax, esi
  add eax, 5
  add esi, 8
  mov [ebp-4], eax
  mov eax, [ebp-4]
  and eax, 7
  cmp eax, 5
  jne near error_non_fun
  mov eax, [ebp-4]
  sub eax, 5
  mov eax, [eax+0]
  cmp eax, 1
  jne near arity_non_equal
  push DWORD 12
  mov eax, [ebp-4]
  sub eax, 5
  push eax
  mov eax, [eax+4]
  call eax
  add esp, 8
  mov esp, ebp
  pop ebp
  ret
overflow_check:
  push DWORD 3
  call error
error_non_int:
  push DWORD 1
  call error
error_non_bool:
  push DWORD 2
  call error
error_non_pair:
  push DWORD 4
  call error
error_too_small:
  push DWORD 5
  call error
error_too_large:
  push DWORD 6
  call error
error_index_non_int:
  push DWORD 7
  call error
error_prim1_non_int:
  push DWORD 8
  call error
error_non_fun:
  push DWORD 9
  call error
arity_non_equal:
  push DWORD 10
  call error
handora
  • 559
  • 5
  • 14
  • Are you disassembling an unlinked object file? Or are you disassembling a position-independent executable from disk without running it? A PIE executable needs runtime fixups for absolute symbol addresses, so the machine code on disk just has offsets. Show us how you build this code with NASM + `gcc -m32` or whatever, and actual disassembly output, to make this a [mcve]. (But if you're using gcc, [probably you want `gcc -m32 -no-pie -fno-pie` to make a position-dependent executable](https://stackoverflow.com/questions/43367427/32-bit-absolute-addresses-no-longer-allowed-in-x86-64-linux).) – Peter Cordes May 25 '18 at 04:16
  • The assembly code is generated by my toy compiler, while when I linked it to a c program(just for printing the result returned from assembly), it reports a segment fault. The question is that I move a label(`temp_fun_1`) into a register, and I call this register later which is a relative address viewed from gdb. How can I fix this? – handora May 25 '18 at 05:33
  • The code in the question doesn't include `temp_fun_1`, and it moves `temp_fun_2` to memory, not a register. Do you mean you single-stepped your code and used `x /2w $esi` and found the dword at `[esi+4]` was `0xc5`? That means your code was somehow linked incorrectly, so **how did you compile/assemble and link your code**? Include that in the question to make it a [mcve]. `mov [esi+4], DWORD temp_fun_2` is the right NASM syntax for storing a label address to memory. – Peter Cordes May 25 '18 at 07:26
  • Sorry, I write it incorrectly. It's `temp_fun_2`, I write it into memory and later write back to register. You can look this `mov eax, [ebp-4] sub eax, 5 push eax mov eax, [eax+4]` just after put it into memory. And I link it to a c program just call 'our_code_starts_here' for linking – handora May 25 '18 at 07:29
  • I use gdb to read the `temp_fun_2` in `mov [esi+4], DWORD temp_fun_2`, it's `0xc50`(which is not the real address but the relative address of section). It annoys me a lot. – handora May 25 '18 at 07:53
  • So you're just disassembling the machine code? Have you started the process yet, or is this before you do `run`? If so, re-read my very first comment. And *please* actually make this question a [mcve] by showing *exactly* what you're doing. It certainly sounds like you're using `gdb` wrong. It feels like I'm wasting my time trying to help you when you won't tell me exactly *what* gdb commands you're using to see this `0xc50` you keep talking about, or how you assemble+link your code. – Peter Cordes May 25 '18 at 07:57

0 Answers0