Re: A completely different approach to EH runtime

[Richard Earnshaw <rearnsha at arm dot com>]

> HJ writes:
> > 1. The gcc people have to agree that a shared libgcc fiasco is waiting
> > to happen on Linux.
> 
> It is clear that there is the potential for problems with libgcc on
> systems that use gcc as the main compiler (I don't see why GNU/Linux is
> unique here), if care is not taken.  It's not clear to me why systems
> that use glibc should have a difficulty that, say, the BSD people will
> not have.  With libstdc++ we have extra problems because glibc and
> libstdc++ share data structures for standard I/O.  But with glibc and
> libgcc, there is no sharing of this type going on; things are much more
> orthogonal.

I can't speak for the other *BSD's but on NetBSD, the basic (re-entrant) 
functions in libgcc are normally built into libc.  No attempt was made to 
link in the other routines, such as exception handling code.  So a shared 
libgcc will probably co-exist with the system libc without problems 
(haven't worked out how to build a shared libgcc on NetBSD yet, and I 
can't find any documentation on it either -- *grumble*)

> 
> > 2. The gcc people have to ask for feedbacks/solutions from the glibc
> > people.
> 
> OK, glibc people, consider yourselves asked.  However, I *also* would like
> to hear from maintainers of the C library on BSD systems as to what
> problems *they* forsee (since they would also have a shared libgcc to deal
> with).  There is nothing special about glibc here, though the glibc people
> do have lots of valuable experience with symbol versioning and the like.

As I see it, the nightmare scenario is that a shared library is installed 
that brings down the system and prevents it from rebooting because 
critical system processes depend on that shared library in some way.  
Again, on NetBSD this can normally be recovered by bringing the machine up 
single user and removing the buggy library (assuming that the old one 
wasn't blown away -- a good versioning policy will solve this).  We can do 
this because the critical programs in /bin and /sbin are all statically 
linked.  Of course, a sensible sysadmin would have tested his new 
libraries first before installing them :-)

Simply installing a new shared library in /lib shouldn't bring the system 
down if it has been well engineered, provided the inode of the old library 
isn't overwritten (use install not cp).