On Sat, Jun 27, 2009 at 01:57:22PM -0700, Michael Snyder wrote:
The problem is that the second "frame_id_eq" test fails in
the case where we've just stepped backward to the RET instruction
of a function which, in forward-time, had just returned.
It's possible that what we're trying to do here is work around a
bug in the i386 implementation of frame_unwind_id. When I look at
the frame_id that it returns at this point, it does not match either
the caller or the callee, and its code_addr is particularly wrong.
I wrote about this problem in my GCC summit paper. All released
versions of GCC generate unwind info that is wrong in epilogues.
I believe it's fixed in trunk GCC, although maybe for specific
platforms only.
In order to get this to work for my demo I had an epilogue-specific
unwinder for ARM. It detected common epilogue sequences and analyzed
them to find the frame ID, and was installed at higher priority than
the DWARF unwinder.
I think you're going to need the same thing here, or else use the
existing gdbarch epilogue hook somehow.