Re: GCC-3.0.1 can't compile Glibc-2.2.4

["H . J . Lu" <hjl at lucon dot org>]

On Tue, Oct 02, 2001 at 08:22:51PM +0200, Jakub Jelinek wrote:
> > If we really don't care this case, why not just build libc.so with
> > -lgcc_s when we build glibc with gcc 3? We don't have to include any
> > real libgcc functions in libc.so. We just leave some stubs in glibc
> > which call the real thing in libgcc_s.so.1. Did you try to avoid
> > loading libgcc_s.so.1 as much as you could? That may not be a bad
> > idea. In that case, why do we even put those real functions in libc.so?
> > At least, _Unwind_Find_FDE and __frame_state_for come to my mind.
> 
> I think we talked about this way back.
> Yes, I want to avoid loading libgcc_s.so.1 into every single program when
> they don't need it at all (think about all C programs).
> The real functions are in libc.so, because every library, be it C or C++
> one, registers its .eh_frame.
> If you don't want the __frame_state_for fallback implementation for glibc
> compiled with gcc3+ (it is necessary for glibc compiled with pre-gcc3), it

I may have missied something. _frame_state_for calls uw_frame_state_for
which calls _Unwind_Find_FDE. But _Unwind_Find_FDE references local
variables, seen_objects and unseen_objects, which are defined in
unwind-dw2-fde.c. They are setup by __register_frame_info_table_bases
and __deregister_frame_info_bases, which are in libc.so. How does
__frame_state_for in libgcc_s.so.1 get the right data defined in
libc.so?



H.J.