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

[Jakub Jelinek <jakub at redhat dot com>]

On Tue, Jul 10, 2001 at 11:51:18AM +0200, Mark Kettenis wrote:
>    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.

If program nor any library it depends on is linked against libgcc_s.so.1 and
glibc does dlopen("libgcc_s.so.1", RTLD_GLOBAL) in __frame_state_for,
then libgcc_s.so.1 will come in the global search scope definitely after
glibc. So, when __frame_state_for in glibc later does
fsf = dlsym(libgcc_s_handle, "__frame_state_for");
, calls it and libgcc_s.so.1's __frame_state_for calls _Unwind_Find_FDE, it
will use the copy in libc.so.6 which comes earlier in the search scope.
If program or any library it depends on is already linked against
libgcc_s.so.1, then things depend on which of libgcc_s or libc come earlier
in the search path, but in both cases all of
register/deregister/_Unwind_Find_FDE will be resolved from the same library.
So I don't understand your concerns here.

> 
> 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.

It cannot be __frame_state_for in which you reregister things if you don't
export _Unwind_Find_FDE, since then there are problems if main binary
dlopens a libgcc_s.so.1 or some library which depends on it.

> 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.

Note that when _Unwind_Find_FDE is exported from glibc, dynamically loading
(or as a dependency of dynamically loaded object) libgcc_s works just fine.

But the idea of just moving the registration root does not seem that bad to
me. It cannot be reregister kind of interface though, because when you
dlopen new libraries, they would register with glibc again (as it comes
earlier in the search path). Also, copying of registration info is not
necessary either.
I'd think the interface could be like:
pthread_mutex_t **__get_frame_info_root (struct **punseen_object,
					 struct object **pseen_object);

This would return pointer to its unseen_object, seen_object and
object_mutex (if any) variables.
unwind-dw2-fde.c compiled with __get_frame_info_root support would need to
use indirection for seen_object/unseen_object/object_mutex variables.
Note that libgcc_s.so.1 would need to export __get_frame_info_root in that
case too, so that if libgcc_s comes earlier in the search path than
libc.so.6 (and thus registration/deregistration happens in libgcc_s),
seen_objects etc. are used from libgcc_s, not libc.
The advantage of doing this would be that GCC can change even
_Unwind_Find_FDE internals at any time it wishes, the disadvantage may be
that we're exposing some internals of unwind-dw2-fde.c (well, at least size of
struct object is already exposed, but what it exposes is that there are two
object lists (so unwind-dw2-fde.c could not create e.g. third one)).

	Jakub