Re: PCH bit me

[Geoff Keating <geoffk at geoffk dot org>]

Alan Modra <amodra@bigpond.net.au> writes:

> Yesterday I ran into lots of errors in the libstdc++ testsuite, all due
> to segfaults.
> 
> The scenario was:
> 1) full bootstrap in clean dir, run testsuite.
> 2) patch a few things, rebuild, run testsuite looking for regressions.
> I forget now exactly how I did the rebuild, probably just with plain
> "make".  It certainly wasn't in a clean dir, as the changes I made were
> relatively minor and I didn't want to wait hours for a bootstrap to
> complete.  (Actually, the "patch a few things" was reverting back to
> a clean tree.)
> 
> The segfaults were due to size_htab->hash_f being set to some location
> inside size_htab_hash rather than to the start of the function.  As you
> can imagine, this messed up the stack.  A little snooping with gdb
> revealed hash_f being changed:
> 
> 0x0ff249ac in memcpy () from /lib/libc.so.6
> (gdb) bt
> #0  0x0ff249ac in memcpy () from /lib/libc.so.6
> #1  0x0ff16358 in _IO_file_xsputn () from /lib/libc.so.6
> #2  0x0ff17258 in _IO_sgetn () from /lib/libc.so.6
> #3  0x0ff09838 in fread () from /lib/libc.so.6
> #4  0x10259fe0 in gt_pch_restore (f=0x1)
>     at /src/gcc-ppc64-34/gcc/ggc-common.c:576
> [snip]
> 
> So, the question is, am I just a sorry loser in expecting this scenario
> to work, or is pch restoring things it shouldn't?  (or both!)

Sounds like a missing dependency in the libstdc++ Makefiles; the PCH
files depend on the compiler executable.

(Of course, every built object depends on the compiler executable; but
for PCH files, it's a bit more critical.)

It'd be possible to make PCH more robust against this sort of thing,
but it'd only really be useful for GCC maintainers, and it would
surely take more time than it would save.

-- 
- Geoffrey Keating <geoffk@geoffk.org>