Re: GCC-3.0.1 can't compile Glibc-2.2.4

["H . J . Lu" <hjl at lucon dot org>]

On Mon, Sep 24, 2001 at 07:05:01PM +0200, Jakub Jelinek wrote:
> On Mon, Sep 24, 2001 at 09:52:00AM -0700, H . J . Lu wrote:
> > Jakub's change is almost ok to me. My only objection is dlopening 
> > libgcc_s.so.1. I don't think it should be included unless it has
> > been verified to work as intended. But it seems noone has tested if
> > it works when the ABI of libgcc_s.so.1 changes, which is the main
> > purpose of dlopening libgcc_s.so.1, and someone believes the ABI change
> 
> Nope, the main purpose of dlopening libgcc_s.so.1 is to catch when
> unwind-dw2.c's internals (as opposed to the ABI of the functions which glibc
> calls) change, which is likely to happen (think about adding new DWARF2.*
> opcodes etc. - e.g. current unwind-dw2.c does not handle opcodes like
> DW_OP_calli, DW_OP_push_object, DW_OP_piece if I name a few; current unwind-dw2.c
> will abort() on them, libgcc_s.so from say gcc 3.2 might handle them and
> that gcc might emit them).
> 

Ok, I will buy that. But it was not clear to me what dlopening
libgcc_s.so.1 could do and wouldn't do. Assuming what you said is true,
I have some questions on its effectiveness. When it happens, your
scheme will only work when libgcc_s.so.1 is also upgraded to the
compatible one which is used to compile the C++ applications. I'd like
to ask

1. How often is it true?
2. If libgcc_s.so.1 is upgraded and we don't do dlopening libgcc_s.so.1
in glibc, how often won't the functions in libgcc_s.so.1 be used?

I have an impression that for most cases, the functions in libgcc_s.so.1
will be used anyway regardless if you do dlopening libgcc_s.so.1 or not.


H.J.