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.129.124]) by sourceware.org (Postfix) with ESMTPS id 9849D3858D35 for ; Fri, 5 Nov 2021 09:54:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9849D3858D35 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-103-lXTC4tyjMC6h0XcixTui3Q-1; Fri, 05 Nov 2021 05:54:19 -0400 X-MC-Unique: lXTC4tyjMC6h0XcixTui3Q-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id DABCD18D6A2C; Fri, 5 Nov 2021 09:54:17 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.193.172]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 7605467867; Fri, 5 Nov 2021 09:54:17 +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 1A59sDbZ1268661 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 5 Nov 2021 10:54:13 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.16.1/8.16.1/Submit) id 1A59sBgu1268660; Fri, 5 Nov 2021 10:54:11 +0100 Date: Fri, 5 Nov 2021 10:54:11 +0100 From: Jakub Jelinek To: Richard Biener Cc: Iain Sandoe , Iain Sandoe , GCC Patches Subject: Re: [PATCH 0/4] config: Allow a host to opt out of PCH. Message-ID: <20211105095411.GG304296@tucnak> Reply-To: Jakub Jelinek References: <20211104200218.24159-1-iain@sandoe.co.uk> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 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_H4, RCVD_IN_MSPIKE_WL, 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: Fri, 05 Nov 2021 09:54:21 -0000 On Fri, Nov 05, 2021 at 10:42:05AM +0100, Richard Biener via Gcc-patches wrote: > I had the impression we have support for PCH file relocation to deal with ASLR > at least on some platforms. Unfortunately we do not, e.g. if you build cc1/cc1plus as PIE on x86_64-linux, PCH will stop working unless one always invokes it with disabled ASLR through personality. I think this is related to function pointers and pointers to .rodata/.data etc. variables in GC memory, we currently do not relocate that. What we perhaps could do is (at least assuming all the ELF PT_LOAD segments are adjacent with a single load base for them - I think at least ia64 non-PIE binaries were violating this by having .text and .data PT_LOAD segments many terrabytes appart with a whole in between not protected in any way, but dunno if that is for PIEs too), perhaps try in a host specific way remember the address range in which the function pointers and .rodata/.data can exist, remember the extent start and end from PCH generation and on PCH load query those addresses for the current compiler and relocate everything in that extent by the load bias from the last run. But, the assumption for this is that those function and data/rodata pointers in GC memory are actually marked at least as pointers... Do we e.g. have objects with virtual classes in GC memory and if so, do we catch their virtual table pointers? Jakub