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

Jakub Jelinek jakub@redhat.com
Tue Nov 9 09:44:45 GMT 2021

On Tue, Nov 09, 2021 at 08:12:05AM +0100, Richard Biener wrote:
> > So, here is 1), 2), 3) implemented.  With this patch alone,
> > g++.dg/pch/system-2.C test ICEs.  This is because GCC 12 has added
> > function::x_range_query member, which is set to &global_ranges on
> > cfun creation and is:
> >   range_query * GTY ((skip)) x_range_query;
> > which means when a PIE binary writes PCH and a PIE binary loaded
> > at a different address loads it, cfun->x_range_query might be a garbage
> > pointer.  We can either apply a patch like the attached one after
> > this inline patch, but then probably callback is misnamed and we should
> > rename it to relocate_and_skip or something similar.  Or we could
> > e.g. during gimplification overwrite cfun->x_range_query = &global_ranges.
> I think struct function allocation should initialize it to NULL and
> the init to &global_ranges be done only when we do init_tree_ssa?
> In fact x_range_query could be moved to the gimple_df substructure
> to make that clear.

Agreed, Andrew/Aldy, what do you think?

> Hopefully PCH happens before init_tree_ssa.

I think it does.

> I'm not keen on further life support for PCH, but then if the work is
> done it's hard to reject it...
> Note there might be still platforms not supporting PCH and so Iains
> patches still look useful to me.

Sure, I think it is fine to opt out of PCH support if needed, just that
PIE shouldn't automatically imply that.

> I also wonder whether we want to require active marking of types
> with PCH support and assert when PCH write runs into objects without?

At least for scalar types I'd prefer not to mark them.
For aggregates, why not, but my gengtype knowledge is very limited,
it has been a pain to add the TYPE_CALLBACK stuff in there already...


More information about the Gcc-patches mailing list