This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: PCH bit me
On Thu, Nov 27, 2003 at 02:53:36PM +1030, Alan Modra wrote:
> 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!)
Some weeks ago, there was a discussion about tracking more properties
of the compiler in the PCH file for validation. I don't remember what
the outcome of it was, though. What should happen in your case is the
PCH file being rejected because the layout of global variables has
changed.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer