Unwind table location

[Cary Coutant]

>As I understand it, on ia64 (as on hppa) there is no guarantee that the
>text and data segments will be at a fixed offset from each other, so it is
>not feasible to use GP-relative offsets to refer to code locations.

Correct.

>I'm
>guessing that .rdata is allocated with .data.  Or to be more general, that
>all sections with the CODE attribute are allocated in one group, and those
>with the DATA attribute are in another, such that self-relative references
>work within a group but not between them.  Is this accurate?

No. The grouping is intended to be based on the writable attribute: all 
read-only sections are grouped in the text segment, and all writable 
sections are grouped in the data segment.

It is correct that self-relative references will work only within a 
segment, and not between segments.

>Therefore, the EH info that refers to absolute code locations (i.e. the
>start and end of the procedure fragment) must be in a CODE section.

It doesn't have to, but that's a good place for it. It's always best to 
maximize the amount of shareable data in the program, so I've tried to 
put as much as possible in read-only data, including all unwind and 
exception handling info.

You can, however, refer to absolute code locations from a data section, 
but the pointers would carry dynamic relocations, slowing down the load 
time. You can also use LTVs (link-time virtual addresses), which would 
not carry dynamic relocations, provided the Unwind/EH library has 
sufficient information to perform the relocation on the fly, but then you 
could move the data back to read-only memory.

>The LSDA starts with a pointer to the beginning of the landing pad;
>conceivably this could be made relative to the fragment start, allowing the
>LSDA to go into data, but I see no reason to prefer that.

We've intended to make references from the Unwind/EH info to code 
locations using either 

1. Segment-relative offsets (as the unwind table entries are already 
defined); or

2. Fragment-relative offsets where the compiler can determine the offset 
statically (without the aid of a relocation) and where the Unwind/EH 
library can identify the base address of the fragment from context. (Here 
I'm making an assumption about what you mean by "fragment.")

>In the case of non-contiguous text segments (such as for embedded systems,
>as Jim suggested yesterday), it seems to makes sense to have separate
>tables for each.  A system that requires something like this could define
>its own means of accessing the different tables, though we still need to
>define how that works for the normal case.

Yes. In this case, we would treat each text segment (each including its 
own unwind/EH tables) as a separate load module from the point of view of 
the unwind library. In an embedded system where there is no dynamic 
loader, one could provide a dlmodinfo equivalent that consults static 
tables prepared by the linker.

-cary