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: libgcc_s.so.1 ASIS won't work with glibc.


On Tue, Jul 03, 2001 at 12:12:37PM +0200, Jakub Jelinek wrote:
> On Mon, Jul 02, 2001 at 05:36:40PM -0700, H . J . Lu wrote:
> > I don't believe it will ever work since __register_frame,
> > __register_frame_table, __register_frame_info_table and
> > __register_frame_info have different ABIs in libgcc_s.so.1 and
> > libc.so.6. You cannot use the same version, GLIBC_2.0, in
> > libgcc_s.so.1. libgcc_s.so.1 should use GCC_3.0 for its verion of
> > those functions since the ones in libgcc_s.so.1 won't work with
> > the existing binaries compiled with g++ v2 dwarf2 frame based EH.
> > glibc somehow has to provide the GLIBC_2.0 version of those functions
> > if we want to support them in glibc compiled with gcc 3.0. One
> > way to get it to work is we provide the backward compatible g++ v2
> > dwarf2 frame based EH in libc.so.6 and let libgcc_s.so.1 provide the
> > g++ v3 dwarf2 frame based EH. Did I miss something?
> 
> What do you mean by different ABIs?
> Say __register_frame() is a function with void * which you should call
> once for each library loaded with __EH_FRAME_BEGIN__, how can that be
> possibly different?
> Similarly __register_frame_info (although it takes struct object pointer,
> you are not supposed to do anything with it after you passed it to that
> function, the memory area pointed to by that pointer will be owned by
> __register_frame_info implementation.

I don't think it works that way. Those frame functions have different
ABIs in g++ v2 and g++ v3. You cannot expect they will work in cases
with binaries which get

1. The g++ v2 EH from libgcc.a in g++ v2. And
2. The frame functions in glibc linked against libgcc.a in g++ v2.

When you recompile glibc with g++ v3, your binaries get

1. The g++ v2 EH from libgcc.a in g++ v2. And
2. The frame functions in glibc linked against libgcc.a in g++ v3.

I don't believe it works ASIS since the fame functions have different
ABIs, at least the data stuctures are differeent. It may be possible
to make the ones in g++ v3 binary compatible with g++ v2. But I am not
sure if it is worth the effort.

I think one way to fix it is

1. Fix the version name in libgcc_s.so in g++ v3.
2. Put the frame functions from libgcc.a in g++ v2 into glibc.
3. We build glibc with the frame functions from libgcc.a in g++ v2
and libgcc.a int g++ v3.

That means

1. The shared glibc is not linked against libgcc_s.so.
2. The shared glibc has the frame functions from a `libgcc' directory
taken from libgcc.a in g++ v2.
3. The shared glibc has NO EH functions from libgcc in g++ v3.

All the existing binaries should work fine. The EH stuff in the
binaries compiled with g++ v3 will come from libgcc_s.so or libgcc.a
in g++ v3.


H.J.


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