Bug#696506: error on using a pch: had text segment at different address

[Stephan Schreiber <info@fs-driver.org>]

Package: src:gcc-4.6
Version: 4.6.3-11
Severity: serious



The gcc/g++-compiler has a bug that prevents a precompiled header  
(pch) from being used. It occurred on all ia64 Debian buildds while  
building the qt4-x11 package. Bug#696096 is already filed for that.
The log reads:

g++ -c -include .pch/release-shared/QtCore -Winvalid-pch -g -O2  
-Wformat -Werror=format-security -D_FORTIFY_SOURCE=2  
-I/usr/include/freetype2 -pthread -I/usr/include/glib-2.0  
-I/usr/lib/ia64-linux-gnu/glib-2.0/include -O2 -fvisibility=hidden  
-fvisibility-inlines-hidden -Wall -W -D_REENTRANT -fPIC -DQT_SHARED  
-DQT_BUILD_CORE_LIB -DQT_NO_USING_NAMESPACE -DQT_NO_CAST_TO_ASCII  
-DQT_ASCII_CAST_WARNINGS -DQT3_SUPPORT -DQT_MOC_COMPAT  
-DQT_USE_QSTRINGBUILDER -DELF_INTERPRETER=\"/lib/ld-linux-ia64.so.2\"  
-DQLIBRARYINFO_EPOCROOT -DQT_USE_ICU -DHB_EXPORT=Q_CORE_EXPORT  
-DQT_NO_DEBUG -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE  
-I../../mkspecs/linux-g++ -I. -I../../include -I../../include/QtCore  
-I.rcc/release-shared -Iglobal -I../../tools/shared  
-I../3rdparty/harfbuzz/src -I../3rdparty/md5 -I../3rdparty/md4  
-I.moc/release-shared -o .obj/release-shared/qlibraryinfo.o  
global/qlibraryinfo.cpp
cc1plus: warning: ./.pch/release-shared/QtCore.gch/c: not for GNU C++  
[enabled by default]
cc1plus: warning: ./.pch/release-shared/QtCore.gch/c++: had text  
segment at different address [enabled by default]
cc1plus: error: one or more PCH files were found, but they were invalid
cc1plus: fatal error: .pch/release-shared/QtCore: No such file or directory
compilation terminated.


When you are using precompiled headers (pch), you invoke gcc/g++ at  
least twice. The first time to create the pch file - to write out the  
file. Second time to use the pch file - to read it in. Gcc expects  
that its binary image is always mapped at the same address in the  
virtual address space of the process. But when gcc's image is mapped  
to another address when reading in the pch than it was on writing out  
the pch, it reports the seen message.

The source code file src/gcc/c-family/c-pch.c of the src:gcc-4.6 gives  
more details:


/* Check the PCH file called NAME, open on FD, to see if it can be
   used in this compilation.  Return 1 if valid, 0 if the file can't
   be used now but might be if it's seen later in the compilation, and
   2 if this file could never be used in the compilation.  */

int
c_common_valid_pch (cpp_reader *pfile, const char *name, int fd)
{
...
  /* If the text segment was not loaded at the same address as it was
     when the PCH file was created, function pointers loaded from the
     PCH will not be valid.  We could in theory remap all the function
     pointers, but no support for that exists at present.
     Since we have the same executable, it should only be necessary to
     check one function.  */
  if (v.pch_init != &pch_init)
    {
      if (cpp_get_options (pfile)->warn_invalid_pch)
	cpp_error (pfile, CPP_DL_WARNING,
		   "%s: had text segment at different address", name);
      return 2;
    }

...
}


It is experienced on ia64 here, but the bug affects any arch.

Stephan