This is the mail archive of the gcc-patches@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]
Other format: [Raw text]

PATCH: Robustify PCH on ia64-hp-hpux


On ia64-hp-hpux11.22, every single V3 test has been failing for a
while.

The problem is that the PCH system makes an assumption which is in
valid on HP-UX.  In particular, PCH assumes that, for a given
executable, the addresses of functions will always be at the same
location when the executable is run.  That's not true on HP-UX; for
example, adding stuff to the environment can change the address of a
function in the executable.

I'm not sure if there are other systems on which this assumption is
invalid, but there certainly could be.  If your ELF executable is PIC,
then the dynamic loader can put it wherever it wants.

This problem is theoretically soluble: you have to keep track of every
function pointer, and swizzle it on PCH-reload.  But, I didn't try to
implement that.

Instead, I augmented PCH validity-checking to notice this problem and
treat the PCH file as invalid.

Tested on i686-pc-linux-gnu and on ia64-hp-hpux11.22.

--
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com

2003-10-22  Mark Mitchell  <mark@codesourcery.com>

	* c-pch.c (struct c_pch_validity): Add pch_init field.
	(pch_init): Set it.
	(c_common_valid_pch): Check it.
	(get_ident): Bump the PCH version number.

Index: c-pch.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/c-pch.c,v
retrieving revision 1.15
diff -c -5 -p -r1.15 c-pch.c
*** c-pch.c	21 Oct 2003 23:28:05 -0000	1.15
--- c-pch.c	22 Oct 2003 15:43:50 -0000
*************** struct c_pch_validity
*** 46,55 ****
--- 46,56 ----
  {
    unsigned char host_machine_length;
    unsigned char target_machine_length;
    unsigned char version_length;
    unsigned char debug_info_type;
+   void (*pch_init) (void);
  };
  
  struct c_pch_header 
  {
    unsigned long asm_size;
*************** pch_init (void)
*** 111,120 ****
--- 112,122 ----
    v.host_machine_length = strlen (host_machine);
    v.target_machine_length = strlen (target_machine);
    v.version_length = strlen (version_string);
    
    v.debug_info_type = write_symbols;
+   v.pch_init = &pch_init;
    if (fwrite (get_ident(), IDENT_LENGTH, 1, f) != 1
        || fwrite (&v, sizeof (v), 1, f) != 1
        || fwrite (host_machine, v.host_machine_length, 1, f) != 1
        || fwrite (target_machine, v.target_machine_length, 1, f) != 1
        || fwrite (version_string, v.version_length, 1, f) != 1)
*************** c_common_valid_pch (cpp_reader *pfile, c
*** 280,289 ****
--- 282,303 ----
        if (cpp_get_options (pfile)->warn_invalid_pch)
  	cpp_error (pfile, DL_WARNING, 
  		   "%s: created with -g%s, but used with -g%s", name,
  		   debug_type_names[v.debug_info_type],
  		   debug_type_names[write_symbols]);
+       return 2;
+     }
+ 
+   /* 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.  */
+   if (v.pch_init != &pch_init)
+     {
+       if (cpp_get_options (pfile)->warn_invalid_pch)
+ 	cpp_error (pfile, DL_WARNING, 
+ 		   "%s: had text segment at different address", name);
        return 2;
      }
  
    /* Check the preprocessor macros are the same as when the PCH was
       generated.  */


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