[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Libunwind-devel] x86-64 libunwind status?
From: |
Curt Wohlgemuth |
Subject: |
Re: [Libunwind-devel] x86-64 libunwind status? |
Date: |
Wed, 17 Oct 2007 14:35:24 -0700 |
User-agent: |
Mutt/1.5.6i |
Hi Arun:
On Mon, Oct 15, 2007 at 05:10:52PM -0700, Arun Sharma wrote:
> On 10/15/07, Curt Wohlgemuth <address@hidden> wrote:
> >
> > Related to this, and exposing my ignorance of the architecture, I'm
> > confused by register values returned by gdb during the attach case
> > above. The value of "$rbp" is 0x7ffff9f3bf40; the value of "$fp" is
> > 0x7ffff9f3bf00. I thought that RBP holds the frame pointer; what would
> > "$fp" be then, and why would it be different? The value at address "$fp
> > + 0x8" is actually the return address I'm expecting (0x402923).
>
> $fp seems to be a variable gdb maintains to track the frame pointer.
> When you use -fomit-frame-pointer on x64, $rbp becomes a scratch register
> for the compiler (this is the default with gcc -O2 and higher).
> Otherwise, $fp and $rbp should be equal.
Okay, thanks.
As to the original problem I was having: there seems to be a bug in
src/os-linux.h
The memcpy() in maps_next() around line 243 of the above file should be a
memmove() call instead, given that there might be overlap between the source
and target. When I changed this call (and the memcpy() at line 231, just in
case), my use of test-ptrace now works as expected for
test-ptrace -v /bin/sleep 1
on both my x86-64 systems.
I've never submitted a patch before, for review or otherwise. What
procedure is generally used?
Thanks,
Curt
Re: [Libunwind-devel] x86-64 libunwind status?, David Mosberger-Tang, 2007/10/15