From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from nikam.ms.mff.cuni.cz (nikam.ms.mff.cuni.cz [195.113.20.16]) by sourceware.org (Postfix) with ESMTPS id AC8A53860017 for ; Wed, 26 Aug 2020 11:27:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org AC8A53860017 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=ucw.cz Authentication-Results: sourceware.org; spf=none smtp.mailfrom=hubicka@kam.mff.cuni.cz Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id 24A1D2829D6; Wed, 26 Aug 2020 13:27:42 +0200 (CEST) Date: Wed, 26 Aug 2020 13:27:42 +0200 From: Jan Hubicka To: Martin =?iso-8859-2?Q?Li=B9ka?= Cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH 2/2] IPA symver: support visibility and static symbols. Message-ID: <20200826112742.GB37801@kam.mff.cuni.cz> References: <720d542574f9630244856d44da8ba70139d66fb9.1598348469.git.mliska@suse.cz> <20200825184604.GA94997@kam.mff.cuni.cz> <49fec957-c424-3e14-f1cd-2d649f2b8b29@suse.cz> <20200826092237.GA18355@kam.mff.cuni.cz> <40b8e05f-6d39-ce89-d6dc-c7b8c56b5b81@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40b8e05f-6d39-ce89-d6dc-c7b8c56b5b81@suse.cz> User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Status: No, score=-12.9 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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: Wed, 26 Aug 2020 11:27:47 -0000 > On 8/26/20 11:22 AM, Jan Hubicka wrote: > > > On 8/25/20 8:46 PM, Jan Hubicka wrote: > > > > What will happen here with protected visibility? > > > > > > I forgot about it. Should it be mapped also to "local"? > > > > > > + const char *visibility = NULL; > > > + if (!TREE_PUBLIC (origin_decl)) > > > + visibility = "remove"; > > > + else if (DECL_VISIBILITY (origin_decl) == VISIBILITY_INTERNAL > > > + || DECL_VISIBILITY (origin_decl) == VISIBILITY_PROTECTED) > > > + visibility = "local"; > > > + else if (DECL_VISIBILITY (origin_decl) == VISIBILITY_HIDDEN) > > > + visibility = "hidden"; > > > > I have no idea (depends what gas will do), you need to check if the > > resulting symbol will indeed have right visibility in all of the cases. > > If some of them are not possible, I suppose we could just reject the > > comination. > > Ok, so I experimented a bit with the .symver attribute I don't see how > is the new syntax handy (I mean .symver foo, foo@VERS_2, hidden and > .symver foo, foo@VERS_1, local)? > > For instance: > > $ cat vi2.c > int > __attribute__((visibility ("hidden"))) > hidden_object; > > extern int > __attribute__ ((__symver__ ("foo@@VERS_2"))) > __attribute__ ((alias ("hidden_object"))) > symver_foo_v1; > > $ gcc vi2.c -S > $ cat vi2.s | grep '\.symver' > .symver symver_foo_v1, foo@@VERS_2 > > $ readelf -s vi2.o -W > ... > 8: 0000000000000000 4 OBJECT GLOBAL HIDDEN 3 hidden_object > 9: 0000000000000000 4 OBJECT GLOBAL DEFAULT 3 symver_foo_v1 > 10: 0000000000000000 4 OBJECT GLOBAL DEFAULT 3 foo@@VERS_2 > > Which seems fine to me. Similarly one can directly modify visibility of > symver_foo_v1 with: > .hidden symver_foo_v1 > > Or do I miss something? At low-level (and how GCC symtab should understand it), symver is just a symbol with funny name. Alias is just another symbol pointing to same place and in general we want to handle versions as aliases with funny names. But it is not how gas interpret its. Writting .symver foo, foo@VERS_2 in my understnading does two things 1) it makes gas to turn all apperances of references to "foo" to "foo@VERS_2" this is necessary since gas syntax does not allow names with @ in it so otherwise we have no way to reffer to it 2) it either exports the foo symbol (and you can add visibility). or makes foo@VERS_2 disappear depending how you declare visibilities of foo. With this we lose way to refernece to actul symbol foo (and not foo@VERS_2) which may be needed in LTO if one symbol declares foo and other declares foo with symtab attribute. So I think we want symver attributes of symbol "foo" to produce a local alias "foo.localalias" which will be renamed for GAS to "foo@VERS_2". Symtab can understand this via syntactic aliases. Then we have way to refer to symbol "foo" if we want "foo" and "foo.localalias" if we want "foo@VERS_2". I had patch for that but I stopped on the situation that there was no way to prevent gas from doing 2). So I see reason for .symbol X,Y, local I do not see much morivation for others, that is why I stopped on updating the patch for new gas syntax - wanted to take some time to understand it (and the time did not materialized). So it seems to me that taking that old patch (or patch of yours) and add the local alias machinery will do the trick, but I may be missing something. Honza