A completely different approach to EH runtime

[Richard Earnshaw]

> > 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?


No, you are forgetting that the reason the symbol version changed is 
because the ABI of that function changed.

Forget about symbol versions for a moment (for a start they only work with 
ELF, AFAIK).  Think about it as follows:

gcc v3.0 calls func(int, int)

gcc v3.1 extends the interface and now needs to call func_v3_1 (int, int, 
int)

Therefore libgcc.so for v3.0 will contain "func", while libgcc.so in v3.1 
will contain "func" and "func_v3_1".  Now, "func" needs to either handle 
the call itself, or transform its arguments into something that can be 
passed to func_v3_1.

All that symbol versioning gives us is that the illusion that both symbols 
are called "func".  In reality one is called "func@@gcc_3.0" the other 
"func@@gcc_3.1" (or whatever).  The linker has to work all this out based 
on the version that was appropriate when the original link was performed 
(or sharedlib created).

R.