New issue: .unwind tables for dynamically-generated code

[Jim Dehnert]

This issue has arisen from C++ ABI discussions, although it doesn't end
up affecting C++.  I've included some recent ia64-tools discussion to
introduce the question (obliquely) and provide background -- the last
paragraph is the issue statement:

>   Kevin> One of the other problems that I've noticed is that there
>   Kevin> doesn't seem to be a symbol which refers to the unwind info.
>   Kevin> I'm trying to figure out how to find it.  (From gdb, I could
>   Kevin> find it, but the idea is for the kernel to be able to find
>   Kevin> its own unwind info.)
> 
> I didn't check on the symbol name, but some also needs to decide how
> to provide access to the unwind info in shared objects and kernel
> modules.  Any takers?

The Intel/HP assumption is that the unwind tables are in the .text
segment to which they refer.  For each .unwind/.text pair, there should
be a program header entry of type PT_IA_64_UNWIND that gives the
location and size of the .unwind table.  It can be associated with the
right .text segment (if there are more than one) by comparing address
ranges.

For shared user code, HP at least then assumes that the unwind library
obtains the start of the unwind table for the PC of interest by
querying the dynamic linker.  Assuming that the unwind library and the
dynamic linker are both parts of the system implementation, this is an
internal interface and not specified as part of the ABI.

This becomes an issue if a user program generates code and associated
unwind tables dynamically, e.g. a Java JIT compiler.  One way to deal
with this is to provide an interface to the dynamic linker to register
a new text range and its associated unwind table.  That interface
crosses the implementation/user boundary, so should be ABI-specified.

Jim

-		Jim Dehnert  x3-4272