Re: [lsb-spec] Re: Standardizing _Unwind_* error handling interfa ces found in libgcc_s.so

[Richard Henderson <rth at redhat dot com>]

On Thu, Oct 10, 2002 at 05:16:09PM -0400, Jim Wilson wrote:
> Gcc uses this
> API for all targets for stack unwinding for C++/Java exception handling.

In theory it would be used for Ada exception handling as well,
but no one's contributed code for that yet.

> The ForcedUnwind function was apparently accidentally left out of the
> original list.

The _Unwind_ForcedUnwind function is present, but it hasn't really been
tested, and I doubt it works properly.

>         _Unwind_Find_FDE
> We have an OS independent version of this function for the DWARF2 CFI-variant
> unwind ABI.  However, for the IA-64 Unwind ABI, we need OS dependent versions
> of this function.

I would say that this function is still private.  It is exported
from libgcc_s.so in order to solve a nasty backward compatibility
problem with glibc.

The function that accomplishes a similar task for IA-64 is 
_Unwind_FindTableEntry, and that function is _not_ exported.

> There is a second related place where the IA-64 Unwind API does not specify
> how to perform an operation, though it doesn't actually document this.  In
> the IA-64 Unwind ABI, unwind info uses section relative relocations.  This
> means we need some OS specific mechanism for finding section addresses in
> the unwind library at run time.  We have abstracted this into two additional
> functions:
>         _Unwind_GetDataRelBase
>         _Unwind_GetTextRelBase
> The original list says these are IA-64 specific.  This isn't strictly correct,
> though this gets a bit complicated.  These functions are specific to the IA-64
> Unwind ABI, because at present is it the only Unwind ABI that uses section
> relative relocations.

This is incorrect.  These functions are even more abstract than the
section-relative descriptions used by the IA-64 Unwind API.

Our dwarf2 cfi extension has some metadata that describes how a 
pointer is encoded within the format itself.  Encodings are desirable
so that the cfi data can be position-independent, and thus not require
runtime relocations in shared libraries.  Which encodings can be used
for a particular target depends on the relocation types provided.

Two of these encodings are "text-relative" and "data-relative", with
no specific meaning associated with either.  These two functions 
return the base to which these encodings are relative.

Incidentally, x86 uses "data-relative" encodings, where DataRelBase
is _GLOBAL_OFFSET_TABLE_.

These functions are universally present in the API provided by
gcc's unwind.h (which probably ought to get installed, but isn't).
In the case of IA-64, these functions are inlines which fall back
on the generic IA-64 EH ABI entry points so that we are ABI compatible
with other IA-64 implementations.




r~