> I'm a bit confused as to how the fallback handler can find the correct
> RA but the "normal" unwind path can't.
The fallback knows what address range corresponds to the stubs. It's
"magic".
> How do all these things fit on the stack?
Every stack frame has room for two return addresses.
The
On 05/11/12 08:45, DJ Delorie wrote:
> If the fallback handler borks the cfa by, for example, just
> subtracting 1 from it, will that confuse the unwinder? Or will it
> "just work".
FYI this isn't entirely dis-similar to the solution we're currently
using for mips16 stubs. See CALL_STUB_RET in l
On 05/11/12 08:45, DJ Delorie wrote:
> That's what we're trying to do, but the CFA corresponds to the
> "normal" cfa but with a different (wrong) return address. The
> fallback handler corrects the RA and the next iteration sees the
> corrected frame.
I think some ascii art or a pointer to a manu
> Can any of these stubs throw exceptions? What are they used for?
I suspect they're simple thunks. I can ask what they do.
> My first reaction is to simply consider them invisible system frames
> and ignore them when it comes to unwinding...
That's what we're trying to do, but the CFA corres
On 05/09/12 17:15, DJ Delorie wrote:
> A TPF stack frame has up to two return addresses in it. The second
> one is used when the call crosses a shared object domain, where a stub
> is between the two functions. The stub does not change the stack, but
> it does eventually chain to the "correct" re
A TPF stack frame has up to two return addresses in it. The second
one is used when the call crosses a shared object domain, where a stub
is between the two functions. The stub does not change the stack, but
it does eventually chain to the "correct" return address.
In the TPF unwinder, a fallba
