Unwind table location

[Jim Dehnert]

> From cary at cup.hp.com  Thu Jan 20 09:40:51 2000
> 
> The first bullet you listed is the intended method. Both the unwind table 
> and the unwind info blocks are intended to be in the same segment as the 
> text with which they're associated. Thus, any segment-relative addresses 
> in those tables are understood to refer to locations in the same segment.
> 
> ...
> 
> The advantages to this scheme are that there are no dynamic relocations 
> for any unwind information (except function pointers in the GOT created 
> by LTOFF_FPTR), and that the unwind information does not cause any 
> increase in the application's per-process data space.
> 
> In order to unwind correctly, it's important that there is a one-to-one 
> relationship between text segments and unwind tables. The dynamic loader 
> needs to keep track of these relationships, so that the unwinder can find 
> the appropriate unwind table, given a pc value.
> 
> Instead of a table of triples, there is a PT_UNWIND program header table 
> entry that locates the unwind information for a load module; this entry 
> is intended to refer to a subset of the text segment. It's through this 
> entry that the dynamic loader finds the unwind table.

My concern with this comes from the possibility of generating multiple
text segments.  In such a case, if an implementation wants to put the
unwind information in a separate segment from text, there's no longer a
trivial way to find the associated text segments for fixup.  And
although I have no objection to putting these in text today for C++,
I'm concerned that a future requirement for C++ or some other language
might make it desirable to put them in data.  If there's a simple way
of making this work, I'd like to pursue it.

Does the ABI require that the segment table be allocated?
Easy to find?  As I recall, the runtime doesn't generally have easy
access to the file itself -- I think in Irix we generally use dynamic
tags to find things instead of the program header table for that reason.
But I don't know the details.

Jim

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