Re: [libunwind] remote unwinding and dynamically-generated code

[David Mosberger]

>>>>> On Mon, 20 Dec 2004 13:39:57 -0600 (CST), Todd L Miller <address@hidden> 
>>>>> said:

  Todd> int dyn_register( unw_addr_space_t as, unw_word_t addr, void *
  Todd> arg );
  >>
  Todd> where addr is the address of the unw_dyn_info_t in the addess
  Todd> space 'as', or should it be something else, perhaps another
  Todd> function in the accessors?

  >>  The interface looks fine to me, but since it'll need to be
  >> implemented as part of libunwind-ptrace, the name should be
  >> _UPT_dyn_register() (and the prototype should go in
  >> include/libunwind-ptrace.h).

  Todd>         I'm not convinced it needs to use ptrace() explicitly;
  Todd> my intention was to use access_mem()* from the addr_space's
  Todd> accessors in a machine-independent routine, so that we _know_
  Todd> the local and remote registration routines are in synch (since
  Todd> they're the same).

Ah, I see now what you mean.  In that case, it would have to be called:

        unw_dyn_register()

I suppose we would have to complement this with unw_dyn_cancel() and
deprecating _U_dyn_register()/_U_dyn_cancel().

The only uneasiness I have with this is that the synchronization model
would be different depending on whether you're doing the registration
locally or remotely.  Perhaps that argues for keeping separate
_U_dyn_register()/_U_dyn_cancel() functions, but it's something that
doesn't seem terribly elegant.

  Todd> * I'm not sure why the fetch() routines are defined in
  Todd> include/remote.h; it may just be because a situation where
  Todd> oblivousness to local or remote memory hadn't come up before.

Well, they're accessing "remote" memory.  Mostly they have to be in a
separate header so we don't pollute files needlessly with the routines
when --enable-debug is turned on (in that case, "inline" is a no-op
and all the "inline" routines are compiled into the files that include
remote.h).

        --david