Unwind Table Location

[Christophe de Dinechin]

Eli Boling wrote:
> 
> >   7) D-12:  Unwind table location.

[...]

> The updated proposal seems to handle most of my concerns, but I'd still
> like to see the PC map hidden, so that language implementors can do as they
> see fit with this.

The idea is precisely that the PC-map is not language specific. Tools like
debuggers will work better with a consistent way to access it. Similarly, C++ EH
can work accross languages because the unwind table is language-independant.


> I would like to see the unwind tables registered with the _Unwind library,
> and referenced only through callbacks, like this:
> 
> typedef __personality_routine (*_Unwind_IPLookupFn)(uint64 IP,
> void **pImplementationData);
> 
> int _Unwind_RegisterIPLookup(_Unwind_IPLookupFn LookupFn,
> uint64 StartAddr, uint64 EndAddr);
> 
> void _Unwind_UnregisterIPLookup(_Unwind_IPLookupFn LookupFn);
> 

I don't like this for a few reasons. First, it makes unclear who "owns" the IP
lookup. In the proposed design, the "system" (== the system vendor) owns it. The
actual format of the table doesn't matter so much, what matters is the
_Unwind_XXX series of functions.

Another thing I don't like is the risk of becoming unable to throw from a static
object constructor or destructor because the above registration did not occur
yet / was undone already.


> The second function lets you uninstall a lookup function.  That's for when
> you're unloading, and you don't want to leave bad fn pointers floating.
> Yes, the RTL for the language does have to cooperate, or things can go
> south a considerable time after a module unloads.

Which is what I don't like :-) Again, this seems unnecessarily difficult for a
debugger to get right when loading/unloading your app.


Could you indicate a reason for doing this? Can you see a real performance issue
with the current layout of the IP table?


Regards
Christophe