This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC 3.0 Release Criteria
- To: Zack Weinberg <zack at wolery dot cumb dot org>
- Subject: Re: GCC 3.0 Release Criteria
- From: Jeffrey A Law <law at cygnus dot com>
- Date: Thu, 27 Apr 2000 15:06:37 -0600
- cc: Geoff Keating <geoffk at cygnus dot com>, rth at cygnus dot com, mark at codesourcery dot com, gcc at gcc dot gnu dot org, libc-hacker at sourceware dot cygnus dot com
- Reply-To: law at cygnus dot com
In message <20000427150244.B14210@wolery.cumb.org>you write:
> On Thu, Apr 27, 2000 at 02:03:59PM -0700, Geoff Keating wrote:
> > >
> > > Assume libfoo.so links against libgcc.a, includes a half-dozen function
> s
> > > (most notably __register_frame_info and company) and re-exports them.
> >
> > Actually, this doesn't happen for __register_frame_info under linux:
> >
> > 00000000 w DF *UND* 000000e4 GLIBC_2.1.3 __cxa_finalize
> > 00000000 w DF *UND* 000000f0 GLIBC_2.0 __deregister_frame_info
> > 00000000 w DF *UND* 000000a8 GLIBC_2.0 __register_frame_info
> >
> > I don't understand why, it's something to do with their being exported
> > from libc.so.
>
> The frame functions are forcibly sucked into libc.so and reexported in
> order to prevent exactly the problem Richard describes. Or maybe I
> should say to prevent it from happening _again_, because it already
> happened in real life, around glibc-2.0.6. Look at the libc-hacker
> archives for Nov 1998-Mar 1999, I think.
Right. But these same kinds of problems happen on systems where we do not
control libc -- so we don't have the options of forcing them into libc.so
to avoid this problem.
jeff