A completely different approach to EH runtime

[Zack Weinberg]

On Wed, Feb 21, 2001 at 11:24:13PM -0800, H . J . Lu wrote:
> On Wed, Feb 21, 2001 at 11:18:15PM -0800, Zack Weinberg wrote:
> > On Thu, Feb 22, 2001 at 06:59:48AM +0000, Joern Rennecke wrote:
> > > > If we add symbols to libgcc_s.so, they will have a different symbol
> > > > version (GCC_3.1 or something).  The dynamic linker will be faced with
> > > > 
> > > >   binary uses: GCC_3.0 GCC_3.1
> > > >   /lib/libgcc_s.so: GCC_3.0
> > > >   /path/to/other/lib/libgcc_s.so: GCC_3.0 GCC_3.1
> > > > 
> > > > I don't know if it is intelligent enough, in this context, to link
> > > > only the libgcc_s.so in /path/to/other/lib.  However, it will pick one
> > > 
> > > Couldn't you make the binary use only GCC_3.1 ?
> > > Would that make it unambigous what to link?
> > 
> > It's not necessary.  If your binary needs only things like __muldi3,
> > you'd like it to work with the old libgcc_s.so.
> > 
> > It is unambiguous which library to load, IMO; I just don't know if
> > ld.so gets it right.
> 
> The ld.so in glibc will check GCC_3.0 and GCC_3.1 AFTER libgcc_s.so
> is loaded, not before.

Mm, but couldn't it notice that it loaded the wrong one, unload it,
and look for another one?  It's not like we only notice ages later
when it tries to lazily bind a missing symbol.  It knows the symbols
are missing as soon as the wrong library is loaded.

zw