D-12 Unwind table location

[Jim Dehnert]

I'm afraid I still haven't made my position clear.  So I'll try once
more, briefly.  I want to have a definition that will _allow_ an
implementation to put the various unwind tables in arbitrary segments,
without changing their format (and therefore without modifying anything
in the compiler except the segment choice).

I am not suggesting that this ABI select any location other than that
proposed, and believe that the currently proposed choices are fine.
But if we can achieve the above objective at little or no cost, I think
it's a benefit, from the point of view of having a more widely
applicable model, and being able to use a compiler like gcc in a wide
variety of environments without unnecessary changes.  And I believe
that we can do this with little or no cost.

> From ddd at cup.hp.com  Tue Feb 15 17:46:23 2000
> 
> 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.

I don't think we need to understand the reason for a future requirement
in order to make allowances for it.  I wouldn't want to introduce
significant cost for it, but I don't believe there is one.

> 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.

No, your position is that we have the flexibility to do what you want
to do, and that you don't see a need for additional flexibility.  I
can't put LSDA in data with the current definition.  That's the
flexibility I want, as long as it's not expensive.

> >  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.

This is the key.  Where is the cost?  Suppose that the unwind table has
associated with it two segment pointers, for the unwind info table and
the text segment.  Then the unwind info pointers in the unwind table
can be relative to the first (not so important since that's under the
covers), and the LPStart pointers can be relative to the second).  If
the unwind library puts them in the exception object each time it
locates a new frame, then we have a small number of cache hits per
frame, all happening in parallel with other memory references that
often won't be hits.  I think that cost is somewhere between zero and
negligible.

Jim
-	    Jim Dehnert		dehnert at sgi.com
				(650)933-4272