Re: [libunwind] GDB and native methods

[David Mosberger]

>>>>> On Wed, 1 Sep 2004 15:22:18 +0100, "Thomas Hallgren" <address@hidden> 
>>>>> said:

  Thomas> I have a hard time getting gdb to unwind my dynamic
  Thomas> frames. Thanks to some printf's that I hacked into a
  Thomas> gdb-6.2, I can conclude that the function
  Thomas> libunwind_frame_sniffer succeeds with unw_init_remote and on
  Thomas> native frames it also succeeds with unw_step. The unw_step
  Thomas> fails with an UNW_ENOINFO as soon as one of my dynamic
  Thomas> frames is encountered.

  Thomas> I have a local debug method that successfully prints the
  Thomas> whole stack using a libunwind cursor so there's no problem
  Thomas> doing a local unw_step. I guess that remote unw_step is
  Thomas> somewhat more demanding?

It shouldn't be.  If it finds the dynamic-unwind info list, everything
else should be like in the local case.  Having said that, gdb does
have a bug in that it assumes that the frame-chain is broken if the
stack-pointer and the IP don't change.  It doesn't look at the
backing-store pointer, which is wrong, of course.  So, if you get a
message saying something along the lines of "stack may be corrupted",
you may be running into this problem.  I have pointed out this bug to
gdb maintainers a long time ago and originally had a fix for that
problem, but in the meantime, the infrastructure was rewritten, and
the bug still isn't fixed. ;-(

        --david