Details of gdb memory access complaint

I have an object file compiled using as (from assembler code).

If I bind it with ld when I try to execute stepi (or nexti ), gdb complains about memory access at 0x0. If I link it to gcc, everything will be fine.

I assume the problem is caused by ld, which produces fewer partitions compared to the result of gcc binding.

Is there a way to configure gdb in more detail so that I can understand what happened to the executable?

(gdb) b main Breakpoint 1 at 0x100000f8e (gdb) r Breakpoint 1, 0x0000000100000f8e in main () (gdb) x/10i $pc 0x100000f8e <main>: fbld 0x6c(%rip) # 0x100001000 <data1> 0x100000f94 <main+6>: fimul 0x7a(%rip) # 0x100001014 <data2> 0x100000f9a <main+12>: fbstp 0x60(%rip) # 0x100001000 <data1> 0x100000fa0 <main+18>: mov0x0 $0x2000001,%rax 0x100000fa7 <main+25>: mov $,%rdi 0x100000fae <main+32>: syscall (gdb) si Cannot access memory at address 0x0 0x0000000100000f94 in main () 

PS: the executable itself works as expected in both versions.

Edit later: the commands I used to compile:

 as -arch x86_64 src.s -o src.o ld -e _main -arch x86_64 src.o -o src gcc -o src src.o 
+6
gas ld gdb macos
source share
2 answers

gdb has a show debug command that provides various internal debugging options. For example. "set debug target 1" will enable tracing for gdb to interact with the target process. You can experiment with each of their flags (there are not many of them).

+2
source share

GCC does not actually bind, it just calls ld on your behalf. The options that it provides must be different from the ones you use.

In this thread:

How to get GCC linker command?

You should see the ld invocation command line by running gcc -v. This should tell you how to change your ld command line so that everything works for you.

+1
source share

All Articles