D-12 Unwind table location

[Christophe de Dinechin]

Jim Dehnert wrote:
> 
> However, I also believe in maximizing flexibility and generality,
> at least when it's nearly free, and particularly when there are
> anticipatable uses for it.  Now, I can anticipate two departures
> from HP's assumptions that are relevant here:
> 
>   - Multiple text segments.  This is common in the embedded world,
>     where the reasons for them often also prevent their being adjacent
>     in the address, and probably also sometimes prevent the inclusion
>     of extraneous data with each text segment.

If you have multiple segments, then your local equivalent of 'dlmodinfo' must be
able to deal with the IP->.text segment. We do that today for multiple text
segments from different load modules, but there is no reason this could not work
for multiple load modules loaded at the same time. So I don't see an objection
here. dlmodinfo reads info from the ELF files, as long as there is an ELF
representation for multiple text segments and your dlmodinfo supports it, you
are fine.

I see the requirement of multiple .text segments as legitimate. We can support
it. On the other hand, I still do not understand what situation would require to
split .unwind from the .text for the corresponding procedure fragment. I am not
saying there is no case where it makes sense, just that if there is such a case,
I don't know it or I did not understand it.


>   - LSDA somewhere besides the associated .text segment.  See the
>     above, or imagine a language/implementation that decides to put a
>     lot of runtime-relocated data in it.

That's why we have a 'TTBase'. The type information contains runtime relocated
data in it. So we need to access it through extra indirections. But we don't pay
the price for any data for which we managed to avoid relocation (in particular
call-site and action tables).

 
> These possibilities, even though I don't anticipate them for IA-64
> mainstream C++, lead me to ask the question:  Can we provide the
> flexibility to support them at little or no cost to our own needs?

My position is that we do have the flexibility today. What you want to do can be
done within the existing framework. It is just slightly non-uniform: the LSDA is
in text. If you want to refer to data that requires relocation, you need a
pointer from that LSDA to your data, which is typically GP-relative.

> 
>  3) The unwind info table contains unwind descriptor references
>     relative to the text fragment, handled in the unwind library,
>     and the LSDA, handled by the personality routine.  The latter
>     includes:
> 
>     ** LPStart, an offset currently relative to its own location,
>     which requires that unwind info be in the associated text segment.

Correct. As I said, this makes this representation efficient both from a
run-time and load-time point of view. Since I don't see any use of splitting
.unwind from .text, I am not willing to pay an extra penalty
accessing/relocating LPStart for no purpose.

> 
>     ** TTBase, an offset currently relative to its own location,
>     which requires that the type table be in the unwind info segment.

What you describe is the projection of the current HP mechanims to our new
typeinfo. I acknoledged that this needs to be changed. In the HP case, TTbase
does not point to the typeinfo, but to structure containing (among others) a
pointer to the typeinfo. Even if the typeinfo are "COMDAT-ed' between load
modules, the structures are not (they are statics that exist only in the data
space associated to the .text, so they can be accessed GP-relative).

We can keep that, having just a pointer to a pointer to the typeinfo. Or we can
invent something smarter. In all cases, if we want to keep typeinfo pointer
comparison, TTBase cannot be GP-relative, I agree with that.


> 
>     Other references to call sites and landing pads, as offsets
>     relative to the address calculated from LPStart.
> 
>  4) The type table contains RTTI references, relative to GP for the
>     current text fragment, handled by the personality routine.
> 
>     ** This requires that the RTTI be in the data segment containing
>     GP, and prevents address-only RTTI comparisons, since it does not
>     support preemption.

See the comment on TTBase above. In today's HP implementation, this is not a
pointer to the RTTI info, but a pointer to a pointer to RTTI info. GP-relative
is fine in that case. We need to devise something else, just keeping in mind
that we want to reduce the number of relocations.

 
> The potentially problematic references are those with (**), which make
> assumptions about the locations of tables AND are handled by the
> personality routine above-the-covers.  (The under-the-covers mappings
> can use unspecified collaboration between the system and unwind
> library.)

> The unwind info references could be "fixed" by making them relative to
> segment addresses identified by the unwind library (more
> under-the-covers mappings) and passed to the personality routine, e.g.
> via routines like _Unwind_GetIP.

As I said, I believe there is no real reason to change the unwind info. Please
feel free to convince me otherwise :-)


> The type table requirement that RTTI be in the segment with GP could be
> fixed in the same way; the inability to deal with address-only
> comparisons cannot.

As I said, my proposal is pointer to pointer, the first pointer being
load-module private, GP-relative, the second one being the actual typeinfo
pointer, load-time relocated, pointing to the COMDAT-ed typeinfo.

There may be a better way to do that, but I could not figure it out.




Thanks for your comments
Christophe