libunwind-devel
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]