> On Monday 10 November 2003 3:52 pm, Richard Earnshaw wrote:
> > However, there are functions in libgcc (specifically those related to 
> > exception handling) that are definitely NOT pure by this definition.  The 
> > exception handling code, for example, has to maintain a list of all the 
> > unwind areas in an application: this code must be registered with a single 
> > libgcc function into a single list/table/whatever, which is then searched 
> > when an exception is thrown.  If there are multiple definitions of these 
> > functions, then they will not create a single list and hence exception 
> > unwinding will be broken.
> [...]
> 
> This is exactly the problem I fixed when I removed libgcc_pic from LIBGCC_SPEC 
> to close PR 22673.

Having a libgcc_pic is not necessarily wrong.  However, having libgcc_pic 
that defines those functions that access writable private static data is 
wrong.  In other words, libgcc_pic != libgcc built as pic; it must be a 
subset of it.

> 
> > Then functions should be allocated as follows:
> > 
> > pure standard functions should be built into libc{.so,.a,_p.a} etc.
> > functions sharing static data should be in libgcc.so (this will probably 
> > only be needed for c++).
> > The rest should be .hidden and built into libgcc.a, which should be linked 
> > into every application and every shared library (libgcc_pic.a).
> 
> Can't we extract these using (an updated) mknative?
> 

I'm sure we can.  It's just a matter of setting it all up correctly.

As for PR 22452, then my first comment is that the SH abi is probably 
somewhat misguided in insisting that these functions not exist behind a 
shared-library interface, but I can understand the reasoning, especially 
if many registers may be clobbered by a function call (on ARM we are 
careful to only clobber one register, so the impact is minimal).  
Notwithstanding this, we could handle these situations as well by building 
libgcc for sh with all the support functions and making the definitions in 
libc.so weak.  Since gcc will always add libgcc to the link list before 
libc this should ensure that the static versions are always found in 
preference to the dynamic versions.  The dynamic versions will still exist 
to ensure that we haven't broken backwards compatibility (though why we 
need bother given that all applications using them are probably broken is 
another discussion point here).

R.