Re: Segfault when dereferencing %rax after -static compiling

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Amittai Aviram <amittai.aviram@xxxxxxxx> writes:

> My program has a function to find the approximate location of the top (highest address) of the stack, by using a loop similar to what you would use for a backtrace:
>
>
>
>        uint64_t rbp = 0;
>         uint64_t raw_stack_start = 0;
>
>         asm volatile ("movq %%rbp, %0" : "=m"(rbp));
> 	while (rbp) {
>                 raw_stack_start = rbp;
>                 rbp = *(uint64_t *)rbp;
>         }
>    
> GCC compiles the loop as follows (from objdump -D):
>
> 400700:       48 c7 45 f8 00 00 00 00	movq   $0x0,-0x8(%rbp)
> 400708:       48 c7 45 f0 00 00 00 00	movq   $0x0,-0x10(%rbp)
> 400710:       48 89 6d f8            	mov    %rbp,-0x8(%rbp)
> 400714:       eb 13                  	jmp    400729 <find_stack_start+0x2d>
> 400716:       48 8b 45 f8            	mov    -0x8(%rbp),%rax
> 40071a:       48 89 45 f0            	mov    %rax,-0x10(%rbp)
> 40071e:       48 8b 45 f8            	mov    -0x8(%rbp),%rax
> 400722:       48 8b 00               	mov    (%rax),%rax
> 400725:       48 89 45 f8            	mov    %rax,-0x8(%rbp)
> 400729:       48 8b 45 f8            	mov    -0x8(%rbp),%rax
> 40072d:       48 85 c0               	test   %rax,%rax
> 400730:       75 e4                  	jne    400716 <find_stack_start+0x1a>
>
> When I compile this code without the -static flag, it runs fine and gives me a plausible address.  When I compile it with the -static flag, I get a segmentation fault, which GDB traces to instruction 0x400722 above, where I dereference %rax and store the value in %rax.  Why would this cause a segmentation faultâwith the -static flag but not without it?

There are many possible reasons.  The most likely is simply that the
memory map looks different when the program is statically linked.  You
might get more information if you look at the value of %rax which traps.
On GNU/Linux, you will also get more information by looking at
/proc/PID/maps.

Ian



[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux