This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: GCC 3.0 Release Criteria


On Wed, Apr 26, 2000 at 01:56:43PM -0700, Mark Mitchell wrote:
> Richard, would you mind summarizing the problems with the current
> scheme and how you making libgcc.so a shared library will help? 

Assume libfoo.so links against libgcc.a, includes a half-dozen functions
(most notably __register_frame_info and company) and re-exports them.

Assume three such libraries do this.  The version of __register_frame_info
chosen at runtime depends on the order in which the dso's appeared on the
link line, and any dependancies between them.

Now introduce a new version of gcc.  Make a change to __register_frame_info,
one that preserves backwards compatibility, but is not forward compatible.
The old dso's must be re-linked, otherwise you risk choosing the wrong
version of the function at runtime.

Even more subtly, introduce a __register_frame_info_2 function (or whatever).
This is a new interface that does similar things to the original, but, say,
takes its data in a different form.  (Not dissimilar to __register_frame vs
__register_frame_info.)  Consider what happens when symbol resolution 
chooses __register_frame_info from a dso linked to an older libgcc and
__register_frame_info_2 from a dso linked to a newer libgcc.  Now we've
got two EH implementations not sharing private data.  Things will work fine
until an exception gets thrown from someplace using the "wrong" EH
implementation.

All of this is solved by having a single version of libgcc in any
one process, and that by making libgcc itself shared.

> Also, what negative consequences are likely?

Getting the shared library installed in a place that gets searched by
ld.so is hard.  It's one of the main reasons we've put this off for so
long.  (Actually, didn't we try a libgcc.so in the deep dark past, ran
into issues with this, and gave up?)

Making sure that we've got the right version of libgcc is hard.  Some
of the uncertainty can be avoided by using symbol versioning, but that
is only available on (some late version of) Solaris and Linux (glibc 2.1+).



r~

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]