This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Help understanding x86 assembly debugging with GDB
- From: Paul Pluzhnikov <ppluzhnikov at google dot com>
- To: Peter Watkins <peter_watkins at mentor dot com>
- Cc: gdb at sources dot redhat dot com
- Date: Wed, 2 Feb 2011 16:20:24 -0800
- Subject: Re: Help understanding x86 assembly debugging with GDB
- References: <4D39DEF8.3050101@mentor.com>
On Fri, Jan 21, 2011 at 11:31 AM, Peter Watkins
<peter_watkins@mentor.com> wrote:
> Looking at the present instruction...
> 0x00002af5da1b31b2 <getNextLineD_+781>: ? ?movb ? $0x0,(%rdx,%rax,1)
> ...the segmentation fault is obvious to me: I'm trying to store the
> immediate value 0x0 into memory at address 0x1 (0x1 + 0x0 * 1). Memory at
> 0x1 isn't accessible to my program, so it segfaults.
>
> What isn't obvious to me is how %rax got its zero value. In the instruction
> preceding...
> 0x00002af5da1b31ab <getNextLineD_+774>: ? ?mov ? ?0x21a17e(%rip),%rax
> ?# 0x2af5da3cd330 <line.7>
> ...I store the value at memory address 0x2af5da3cd330 into %rax. This is the
> global variable, "line". "line" is a pointer to a character:
> (gdb) whatis line
> type = char *
>
> Its value is:
> (gdb) p /a line
> $2 = 0x181a3eb0
But it's not the global "line" that is at address 0x2af5da3cd330; it's
"line.7" (which, given its illegal name, is probably a function-local
static variable).
You can confirm this by 'print &line' (which, I expect, will produce
something other than 0x2af5da3cd330) and 'info sym 0x2af5da3cd330'.
Also, 'x/gx 0x2af5da3cd330' should (I expect) show 0.
Hope this helps.
Cheers,
--
Paul Pluzhnikov