[libunwind] filling in unw_dyn_region_info_t

[Todd L Miller]

        I'm dynamically generating code for instrumentation of the form

alloc r43=ar.pfs,27,19,8;;
mov.m r43=ar.unat;;
adds r12=-8,r12;;
st8 [r12]=r43,-8;;
st8.spill [r12]=r1,-8;;
st8.spill [r12]=r2,-8;;

followed by more integer register spills.  I'm guessing that the proper
sequence of unwind operations would be something like

_U_dyn_op_add( region->op[0], _U_QP_TRUE, 6, UNW_REG_SP, -8 );
_U_dyn_op_spill_sp_rel( region->op[1], _U_QP_TRUE, 12, UNW_IA64_GR + 1, 0 );
_U_dyn_op_add( region->op[2], _UQ_TRUE, 15, UNW_REG_SP, -8 );
_U_dyn_op_spill_sp_rel( region->op[3], _U_QP_TRUE, 12, UNW_IA64_GR + 2, 0 );
_U_dyn_op_add( region->op[2], _UQ_TRUE, 15, UNW_REG_SP, -8 );

and so on, but I can't find documentation discussing what libunwind
expects.  The example I've seen would use a save_reg operation on ar.pfs
for the alloc, but I don't think it applies, since I immediately overwrite
the target register. (Likewise for the UNAT move.)

        I'm looking for a pointer to documentation about this, or insight
into what and how much to tell libunwind.  For instance, does it need to
know where I'm stashing R2?  If I spilled R12 to the stack first, how
could I tell libunwind that the stack pointer is on the stack?  (Would it
infer that from an op_spill() of register 12?)  Would it be easier to tell
libunwind what's going on if I generated code that used some register
other than 12?  (If, for instance, I started using r2 as the stack once
I'd spilled it.)

        I also can't find information about the
UNW_INFO_FORMAT_TABLE[_REMOTE] types.  Is this something a library user
should worry about?  I'm particularly concerned because I need to tell
libunwind about code generated in _remote_ processes, and I can't find
examples of how to do that.

        More generally, while libunwind seems unphased when you use it
with multiple remote processes (and good work on that!), I don't see a
mechanism for telling libunwind that I'm registering dynamic code for only
one particular process.  If there isn't one, I think I can work around
it*, but, of course, it'll be ugly.

        Thanks for your time.

- Todd L Miller

* Every time I switch between unwinding remote processes, I can
_U_dyn_cancel() the other process's code and _U_dyn_register() the new,
right?  (As I understand it, caching doesn't apply to remote processes?)