From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 95177 invoked by alias); 18 Oct 2019 12:56:08 -0000 Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org Received: (qmail 95167 invoked by uid 89); 18 Oct 2019 12:56:07 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-6.0 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 spammy=s390x X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 18 Oct 2019 12:56:06 +0000 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 301FF10CC1F9; Fri, 18 Oct 2019 12:56:05 +0000 (UTC) Received: from oldenburg2.str.redhat.com (dhcp-192-200.str.redhat.com [10.33.192.200]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 6AC0360BF1; Fri, 18 Oct 2019 12:56:04 +0000 (UTC) From: Florian Weimer To: Segher Boessenkool Cc: Josef Wolf , gcc-help@gcc.gnu.org Subject: Re: Propagating addresses from linker to the runtie References: <20191016131759.GA11171@raven.inka.de> <5b75d9aa-9f33-2ec6-ff46-713b113b3539@gmail.com> <20191017113157.GC11171@raven.inka.de> <20191018090705.GF11171@raven.inka.de> <87d0euv2hh.fsf@oldenburg2.str.redhat.com> <20191018094353.GG11171@raven.inka.de> <8736fquy7e.fsf@oldenburg2.str.redhat.com> <20191018125138.GM28442@gate.crashing.org> Date: Fri, 18 Oct 2019 12:56:00 -0000 In-Reply-To: <20191018125138.GM28442@gate.crashing.org> (Segher Boessenkool's message of "Fri, 18 Oct 2019 07:51:38 -0500") Message-ID: <87mudyrz4s.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2019-10/txt/msg00081.txt.bz2 * Segher Boessenkool: > On Fri, Oct 18, 2019 at 12:47:49PM +0200, Florian Weimer wrote: >> > #define symbol_set_declare(set) \ >> > extern char const __start_##set[] __symbol_set_attribute; \ >> > extern char const __stop_##set[] __symbol_set_attribute; >> > >> > Due to symbol_set_declare, those symbols expand to two unrelated >> > symbols. Using unrelated symbols for pointer arithmetic again violates the >> > standard. >> >> Ah. So we need more uintptr_t casts here. > > Using reserved names (like those starting with two underscores) is UB > already. And those particular names actually clash with names GNU LD > already creates! Well, those names are created by BFD ld for us as well. But that doesn't mean that GNU C will do anything sensible with them. You do not need C language extensions for that. Some of them an non-controversial, others less so. >> > Thus, the issue that Martin mentioned applies here, too. >> > >> > To get this conforming, the linker would need to export a symbol to the start >> > of the section and the length of the section, IMHO. >> >> Right, but we do not have that today. 8-( > > We have had it since over 25 years: > > Thu Aug 18 15:37:45 1994 Ian Lance Taylor (ian@sanguine.cygnus.com) > > Make the ELF linker handle orphaned sections reasonably. Also, > define __start_SECNAME and __stop_SECNAME around sections whose > names can be represented in C, for the benefit of symbol sets in > glibc. > > You just need to have linker scripts that do not sabotage this :-) But it doesn't work on s390x if the section has a size that is not a multiple of 2 because all global symbols must have alignment 2 or more on that architecture (of course __alignof (symbol) may still say 1 because *that* has to reflect C semantics). Thanks, Florian