Re: [Libunwind-devel] x86-64 libunwind status?

[Curt Wohlgemuth]

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