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 12:07:19PM -0700, H . J . Lu wrote:
> 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?

I think the key is _Unwind_Find_FDE in libc.so has to be used in
this case. Otherwise, I don't think it will work. I still don't like
the idea of the dependency on libgcc_s.so.1. Personally, I think it
is a bad idea.


H.J.