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~
