From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by sourceware.org (Postfix) with ESMTPS id E9AC53857001; Tue, 22 Jun 2021 14:54:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E9AC53857001 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id EE78521970; Tue, 22 Jun 2021 14:54:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1624373687; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=28Oalk/wDYAgrSmvHTRTE35QXhZcs1SYHaR3EOZ1tAk=; b=VTUoKD6P2GKwu5SlAStjRGLWf20g2KVZB6EOWLwLDC1JYBpSJfKBdEsi78JBUdpBB+YBeY r0vEoL5Q5Bxfh2HIEtang1Xs9Hd62iQHVS4OVRzQmnZOtlcTqLYIFmNRMfIiOfjiBpLAVZ YJZTw7Nk/csUdry+RmWsHI7olwJbAZ4= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1624373687; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=28Oalk/wDYAgrSmvHTRTE35QXhZcs1SYHaR3EOZ1tAk=; b=DIzKtmIiiGA9VjvxQQ/wmhZPOoAPXxBVa9SlFaRLXVky+tShKlrUIkUZ7dscGJ8HlK91dB zuHSnoV0D7YbeXCw== Received: from wotan.suse.de (wotan.suse.de [10.160.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id 168DFA3BAC; Tue, 22 Jun 2021 14:54:47 +0000 (UTC) Received: by wotan.suse.de (Postfix, from userid 10510) id 0C76D6537; Tue, 22 Jun 2021 14:54:47 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by wotan.suse.de (Postfix) with ESMTP id 0B3946361; Tue, 22 Jun 2021 14:54:47 +0000 (UTC) Date: Tue, 22 Jun 2021 14:54:47 +0000 (UTC) From: Michael Matz To: "H.J. Lu" cc: =?UTF-8?Q?F=C4=81ng-ru=C3=AC_S=C3=B2ng?= , llvm-dev@lists.llvm.org, GCC Development , GNU C Library , GNU gABI gnu-gabi , Binutils Subject: Re: [llvm-dev] RFC: Add GNU_PROPERTY_UINT32_AND_XXX/GNU_PROPERTY_UINT32_OR_XXX In-Reply-To: Message-ID: References: <20210617193825.zzjyoybttajksw5x@google.com> <20210618000600.c7yh6twgbukmyouj@google.com> User-Agent: Alpine 2.22 (LSU 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gnu-gabi@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gnu-gabi mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2021 14:54:50 -0000 Hello, On Tue, 22 Jun 2021, H.J. Lu wrote: > > > The issue is that libfoo.so used in link-time can be different from > > > libfoo.so at run-time. The symbol, foobar, in libfoo.so at link-time > > > has the default visibility. But foobar in libfoo.so at run-time can be > > > protected. ld.so should detect such cases which can lead to run-time > > > failures. > > > > Yes, but I think we can _unconditionally_ give an error in this case, even > > without a marker. I view restricting visiblity of a symbol in furture > > Unconditionally issuing an error can be an option, but mandatory. > Otherwise working binary today will fail to run tomorrow. Like a binary that's working today will fail tomorrow if the updated shared lib simply removes a symbol from it's export without proper versioning. I don't see a material difference. > > versions of shared libraries to be an ABI change, hence it has to be > > something that either requires a soname bump or at the very least symbol > > To support existing binaries, we need a soname bump. > > > versioning with the old version staying on default visibility. > > Symbol versioning doesn't work here since both symbols are at > the same address. I don't see why the address should matter. My point was that in the end the exported symbol table for such shared lib (where foobar was changed from default to protected visiblity) should have 1: 12345 42 FUNC GLOBAL DEFAULT 1 foobar@Old 2: 12345 42 FUNC GLOBAL PROTECTED 1 foobar@@New This might require new GAS directives and compiler attributes (or might be expressible already). References from within the shared library would need to continue going via the default visiblity symbol, so that it supports old binaries containing copy relocs, which just again points out that it's a bad idea to restrict visibility after the fact. AFAICS your scheme also doesn't support old binaries with newly protected symbols in newer shared libs, so an (unconditional) error in such situation seems appropriate. IOW: which scenario do you want to not error on when you want to make the error conditional? Ciao, Michael.