From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 4DABB3858D39 for ; Tue, 9 Nov 2021 09:44:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4DABB3858D39 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-106-IhTOxi2DNPm683-aSp0VpA-1; Tue, 09 Nov 2021 04:44:56 -0500 X-MC-Unique: IhTOxi2DNPm683-aSp0VpA-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id ACB451023F4D; Tue, 9 Nov 2021 09:44:55 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.192.54]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 346025DA61; Tue, 9 Nov 2021 09:44:51 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.16.1/8.16.1) with ESMTPS id 1A99ilfY1405610 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Tue, 9 Nov 2021 10:44:48 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.16.1/8.16.1/Submit) id 1A99ijGg1405609; Tue, 9 Nov 2021 10:44:45 +0100 Date: Tue, 9 Nov 2021 10:44:45 +0100 From: Jakub Jelinek To: Richard Biener Cc: Iain Sandoe , gcc-patches@gcc.gnu.org, John David Anglin , Aldy Hernandez , Andrew MacLeod Subject: Re: [PATCH] pch: Add support for PCH for relocatable executables Message-ID: <20211109094445.GN2710@tucnak> Reply-To: Jakub Jelinek References: <20211104200218.24159-1-iain@sandoe.co.uk> <20211105095411.GG304296@tucnak> <20211105152515.GK304296@tucnak> <20211108114604.GI2710@tucnak> <20211108194807.GJ2710@tucnak> <6n83494-274o-4r5r-552n-8195p08748o7@fhfr.qr> MIME-Version: 1.0 In-Reply-To: <6n83494-274o-4r5r-552n-8195p08748o7@fhfr.qr> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-5.7 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2021 09:44:59 -0000 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... Jakub