Unwind table location

[Cary Coutant]

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

Re. multiple text segments...

Our position is that we would only need more than one text segment in a 
single load module where we need to establish different access 
permissions for some text pages than for others. In such a case, we 
consider them to be separate -- but contiguous -- text segments from the 
loader's point of view, and a single text segment from the unwinder's 
point of view. Therefore, we still need only one unwind table per load 
module.

This points out the hazy definition of "segment" and "program header 
table entry" in the ELF specification. Some program header table entries 
describe segments that are disjoint from all other segments, while others 
(like PT_DYNAMIC and PT_UNWIND) describe "sub-segments" that are really 
part of another segment.

Re. unwind tables in data...

The performance bigots here would *never* let me put the unwind tables in 
the data segment. Nevertheless, if some language-specific data really 
needs to be in data, it can be arranged by putting "LTV" pointers in the 
language-specific data that point to an auxiliary block of info in the 
data segment. A much earlier version of our C++ exception handling tables 
in fact did just that.

("LTV" pointers are "link-time virtual" addresses. At link time, an LTV 
relocation works just like the corresponding DIR relocation, except that 
no dynamic relocation is generated, so the associated word can be placed 
in a read-only segment. The consumer of that pointer must, at run time, 
figure out what segment the link-time virtual address refers to and apply 
the appropriate relocation factor to the address. The required 
information can be obtained from the dynamic loader. Note that this 
scheme requires that the linker-assigned addresses for all of the 
loadable segments do not overlap.)

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

No, but the dynamic loader does have access to it. When we need to find 
an unwind table, we ask the dynamic loader: given a pc value, its 
dlmodinfo() entry point locates the load module containing that text 
segment, and returns a struct load_module_desc, which contains, among 
other things, a pointer to the unwind table for that load module.

-cary