Re: RedHat patch not found in mainline gcc

[Jakub Jelinek <jakub at redhat dot com>]

On Mon, Mar 17, 2014 at 06:12:13PM +0100, Stefan Ring wrote:
> At the company where I work, we have a large program using Boost
> Python (1.54). We do our product builds for RHEL 5 and recently
> started building using gcc 4.8 from RedHat devtoolset 2 for
> performance. This works well, except for one system where it would
> deterministically crash. I traced it to an old version of libgcc, and
> specifically this patch, which RedHat applied to its 5.5 release in
> 2009: <http://sophie.aero.jussieu.fr/distrib/Scientific%20Linux/5x/x86_64/by-pkgid/b5e52bbfb4bb11a6cbed452927fba979/files/118>.
> I built libgcc myself with and without the patch, with the program
> crashing reliably without the patch, and no crash with the patch
> applied. Unfortunately, gdb does not show a meaningful stack trace, at
> least not the old version from RHEL 5.
> 
> When trying to find out a bit more about the patch, I was rather
> surprised to see that (1) it is not applied to the mainline gcc code
> and (2) it still applies cleanly. Since I don't have a good stack
> trace, I cannot even try to build a suitable reproducer at the moment.
> 
> Is there a good reason for not having it in mainline gcc? I suppose it
> got lost or forgotten somehow, and that it would be good to have it
> applied.

I don't remember it well, but from re-reading the gcc-patches threads around
that time like:
http://gcc.gnu.org/ml/gcc-patches/2009-06/msg00368.html
it seems that the actually committed fix for the bug that the
gcc41-unwind-restore-state.patch was meant to fix was
http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00617.html committed as
http://gcc.gnu.org/r118068
The reason for not backporting that change was supposedly (my memory is
fuzzy about it) to minimize the amount of structure layout changes in what
is in the unwinder for buggy programs sometimes semi-public.  While the GCC
driver will attempt to link the unwinder preferrably only as libgcc_s.so.1
or into executables only to avoid many different copies of the unwinder,
possibly from different GCC versions, if one overrides that and exports
different versions of the unwinder from different shared libraries, there is
always a risk that e.g. a subset of the unwinder symbols from older version
of GCC unwinder comes earlier in search scope, and for the rest of symbols
(e.g. those added in a newer version of GCC unwinder, though that happens
only very rarely) they are exported from the newer GCC unwinder and then
can't communicate together because some internal data structure changed.

If you are talking about devtoolset, that compiler doesn't come with it's
own libgcc_s.so.1, uses the system one, just its own libgcc_eh.a, so e.g. if
you'd use the default -shared-libgcc (for g++), then it should make no
difference at all, because you'd be using the same system unwinder all the
time.

	Jakub