[PATCH] pch: Add support for PCH for relocatable executables

[Iain Sandoe]

Hi Folks,

IMO both this series
 - which restores the ability to work with PIE exes but requires a known address for the PCH 
and the series I posted
 - which allows a configuration to opt out of PCH anyway

could be useful - for Darwin I prefer this series.

of course, it would be very nice to have a relocatable impl (or the tree streamer) .. I fear
that relying on finding a fixed hole in the VM addresses is probably fragile w.r.t OS updates.

> On 10 Nov 2021, at 20:24, Iain Sandoe <iain@sandoe.co.uk> wrote:

>> On 10 Nov 2021, at 08:14, Iain Sandoe <iain@sandoe.co.uk> wrote:
> 
>>> On 9 Nov 2021, at 12:18, Jakub Jelinek via Gcc-patches <gcc-patches@gcc.gnu.org> wrote:
>>> 
>>> On Tue, Nov 09, 2021 at 11:40:08AM +0000, Iain Sandoe wrote:
>>>> There were two issues, of which one remains and probably affects all targets.
> 
>>>> 2. This problem remains.
> 
> This problem is also present on master without making any changes to the PCH
> implementation - if one fixes up the read-in to simulate a corrupted file, cc1 hangs
> 
> (which means it’s no barrier to the revised PCH implementation)


>> That seems reasonable for the case that we call fatal_error from ggc-common, but
>> I don’t think it will work if fancy_abort is called (for e.g. a segv) - we might need to 
>> make a local fancy_abort() as well for that specific file, perhaps.
>> 
>> Or in some way defer overwriting the data until we’ve succeeded in reading/relocating
>> the whole file (not sure what the largest PCH is we might encounter).

> 
> (answering my own question) around 150Mb for largest libstdc++ and similar for an 
> Objective-C include of Foundation + AppKit etc.
> 
> The underlying reason here is that diagnostics have become much more sophisticated,
> and they do all sorts of context checking and include the libcpp stuff directly which is a lot
> of GTY(()) stuff.
> 
> I cannot immediately see any small set of state that we can save / restore around the
> PCH read in,

I was wrong about that… patch posted that fixes most of this issue.


===

To add to Jakub's two patches that do the heavy lifting - two configure changes (I have also
darwin-local changes which are under test at the moment with the intention to apply them
anyway).



-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-configure-gcc-Add-enable-pie-tools.patch
Type: application/octet-stream
Size: 3870 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc-patches/attachments/20211113/2008886a/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-configure-Add-top-level-configure-support-for-enable.patch
Type: application/octet-stream
Size: 4014 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc-patches/attachments/20211113/2008886a/attachment-0001.obj>