[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 16:05:53 -0700 |
User-agent: |
Mutt/1.5.6i |
Hi Arun:
> > I've never submitted a patch before, for review or otherwise. What
> > procedure is generally used?
>
> The same as Linux kernel. You should be able to find some examples in
> the list archives.
Okay, thanks. I'll look into this and try to send a patch in the next day
or two.
In the meantime, I'm doing more debugging, and my own use of unw_step() on
x86-64 (not tests/test-ptrace, which seems to work for me) seems to return 0
-- stack bottom -- for many cases where there are clearly more stack frames
to be unwound.
I'm hoping someone can help me understand the following lines in
x86_64/Gstep.c:
line 142: /* Heuristic to recognize a bogus frame pointer */
ret = dwarf_get (&c->dwarf, rbp_loc, &rbp1);
if (ret || ((rbp1 - rbp) > 0x4000))
rbp_loc = DWARF_NULL_LOC;
This is the case when
- dwarf_step() failed
- we're not in a signal frame
- RBP is non-zero
In my case, RBP seems valid (e.g., 0x7fff8a9008e0), and rbp1 also seems
valid to me (e.g., 0x47168b9f). Because of the unsigned type for rbp/rbp1,
the test for
(rbp1 - rbp) > 0x4000
is true here; rbp_loc is set to NULL, and it thinks we're at stack bottom.
Where did this heuristic come from? Is it really only trying to test if
*RBP is _greater_ than (RBP + 0x4000), or _within_ 0x4000?
If I debug a simple himom program on my system, with a breakpoint at main(),
I have
(gdb) p/x $rbp
$1 = 0x7fff97519570
(gdb) x/1g $rbp
0x7fff97519570: 0x0000000000400550
which are similar values to what I'm seeing. Why would this be recognized
as a "bogus frame pointer?"
Thanks,
Curt
Re: [Libunwind-devel] x86-64 libunwind status?, David Mosberger-Tang, 2007/10/15