This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: TPF unwinding broken


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" return address.
> 
> In the TPF unwinder, a fallback handler is provided that traps these
> stub addresses, updates the RA in the frame data, and returns.  The
> next iteration of the unwinding loop sees the "right" RA.
> 
> However, the CFA is used to "uniquely identify" a call frame.  Since
> the same CFA has two RAs, it is no longer unique, and the assert in
> _Unwind_RaiseException_Phase2() is triggered.
> 
> Removing the assert makes everything work just fine, since the next
> iteration of the loop finds the correct personality etc.
> 
> In the past, the RA was used to uniquely identify the frame, which
> also worked for TPF.
> 
> Any ideas on how to work around this "bug" in the tpf-specific files?

Can any of these stubs throw exceptions?  What are they used for?

My first reaction is to simply consider them invisible system frames
and ignore them when it comes to unwinding...


r~


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]