Re: DWARF EH for PPC

[hjl@lucon.org (H.J. Lu)]

> 
> 
> I might add that this sort of problem is not just related to glibc,
> egcs or C++.
> 
> For instance, on my machine there is a library routine in libgcc.a
> "__divdi3", which (I think) performs division of 'long long's.  The
> shared library "libext2.so.2" currently uses it, and so (because like
> all shared libraries it is linked with libgcc.a) it defines it:
> 
> 0001038c g    DF .text  000005b4  Base        __divdi3
> 
> But this means that any application program linked with this library
> will _not_ include this routine, because it is in the shared library
> which is linked before libgcc.a.  Now, suppose the library is changed
> so that it no longer requires this routine.  Then all those
> applications would break.

It won't happen. That is one reason we keep those old __register_frame
functions in frame.c even though egcs doesn't use them anymore. With
shared library, you may not remove any functions from libgcc.a and 
you cannot change their ABIs. It is trivial to make sure __divdi3 will
be in libfoo.so on Linux. Just add

	extern void __divdi3 ();
	__divdi3 ();

to crtstuff.c around line 375. You will see those codes are never
reached. But it ensures those symbols will be included in libfoo.so.

> 
> Alternatively, I think Zack proposed a solution where libgcc.a was
> linked to every object before any shared objects.  This would work,
> because it would ensure that any executable that needed it had a copy
> of (say) __divdi3 of its own.  I recommend this solution.
> 

I haven't studied it in details. I don't know if you can cover all
permutations allowed by gcc, like:

# gcc .... foo.o -lbar bar.o



-- 
H.J. Lu (hjl@gnu.org)