Re: [PATCH] Fix PR target/16344

["John David Anglin" <dave at hiauly1 dot hia dot nrc dot ca>]

> >>  don't tell it how to spell "mmap" it falls back to "malloc".  The 
> >> keys to making PCH more portable would be to (a) write code to remap 
> >> pointers, if necessary, and (b) to avoid storing the addresses of 
> >> functions or of variables that are not part of the compiler.  (For 
> >> example, you wouldn't want to store the address of "stdin", since it 
> >> might move.)  Another option would be to swizzle them too, on 
> >> readback.  The EDG implementation of (a) is actually quite fast, due 
> >> to the fact that their tree-walking routines are better than ours.
> >
> >
> > We already do (b).  I disbelieve that any implementation of (a) is 
> > faster than *not* remapping pointers, but if you wish to work on (a) I 
> > won't stop you; we can have a bake-off.
> 
> I think I was insufficiently clear.  The "are not part of the compiler" 
> phrase was meant to apply only to "variables".  I meant that we should 
> avoid writing out any function pointers whatsoever.  That's definitely 
> doable, but it would take some work.

The problem is the PLT is moving from one invocation of cc1plus to
another.  I'm not sure why.  Currently, function descriptors live in
the PLT.  So, if it moves, the PCH is dead even if the text is in the
same location as it was when the PCH file was written.  If this can't
be fixed, then the only solution is to avoid writing out any function
pointers.

This is on hppa-unknown-linux-gnu.  I could easily imagine the same
problem exists on the 32-bit hpux port as it has a similar function
pointer implementation.  The 64-bit hpux port uses a .opd section
which might be immune to these vagaries.

The SEGV might be avoided by doing explicit function pointer
canonicalization using backend support.  The current check is simply
wrong for ports that require function pointer canonicalization.
However, there isn't much point in fixing this problem given the
PLT problem.

The mmap problem is different.  The hpux and 2.4 linux kernels for
PA-RISC don't honor the START operand of mmap without MAP_FIXED.
The symptom is the failure of the largefile.c pch test.  We also
don't get consistent load addresses using malloc.

I tried the -Winvalid-pch with libstdc++.  However, this always
results in a warning from either O0 or O2 about different flags.
This causes all tests to fail.  So, it can't be enabled while
running the v3 testsuite.

It seems PCH is pretty much broken on all the major PA-RISC targets.
I gather from Mark's comments that there must be somewhat similar
problems with ia64 on hpux.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)