This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: PATCH: Share the dwarf2 unwind code between glibc and gcc 3.0


   Date: Mon, 9 Jul 2001 13:24:01 -0700
   From: Richard Henderson <rth@redhat.com>

   > - on platforms which need it __frame_state_for too.

   What if glibc's implementation of __frame_state_for dlopen'ed
   libgcc_s and called the implementation therein?

Hmm, how is libgcc's __frame_state_for going to get at the frame
info?  Unless I'm mistaken, calling _Unwind_Find_FDE won't work, since
the version in libgcc is used, while the data was registered in glibc.

I just thought about this in the shower, and I think the solution is
to re-register the frame info when dlopen'ing libgcc.  That way we
can even avoid exporting _Unwind_Find_FDE from libc.  We'd have our
own versions of __register_frame* and __deregister_frame* in libc,
that do nothing but recording the location of the info and base
addresses.  The __frame_state_for in libc would then call
__register_frame_bases in libgcc for all previously registered
objects.

We might take this one step further.  If we let libc export a function
(say __reregister_frame_info), that takes care of the reregistering
process, and call that from the initializer function for libgcc, we
can even allow for libgcc to be dynamically loaded (as a dependency of
a dynamically loaded object).  In that case we probably want to mark
libgcc as undeletable.

Mark


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]