From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-f196.google.com (mail-pf1-f196.google.com [209.85.210.196]) by sourceware.org (Postfix) with ESMTPS id 63B64385B835 for ; Thu, 9 Apr 2020 17:16:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 63B64385B835 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=maskray.me Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=emacsray@gmail.com Received: by mail-pf1-f196.google.com with SMTP id k15so4402050pfh.6 for ; Thu, 09 Apr 2020 10:16:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=wKRiNS7ylC3wZxpeSDk6qz/oUVYXr4AvS8i4Q8CqdL4=; b=cKqjOlhP1Zz7AArPG0RXyZ3alXDvLevxiH90fouYq0jiqKBppew5I3UOe83/q1FX6j aL3808LtdN63Wcp1FkACjI3tTwQ1jZKcxFcFsSkVw64tukto6hoNhfUvz24WSBfGhv9p bzStOavOh88GjGjGOUW3a4CDUHc5jX3/I4BKolsA0lswfMe6k8FN0X0Uwhnjzm5UnkI4 xXqTYNVUEjp2vjFdOHy4uooqEDRn9zW13eTF+5u+tZYmUoV7H8DbY8SohkPWyTISiQqx SKey8xQl5ij8JOx6yhaPhBMbUNfjfKVK1W6NHxoFQRciFCI7u7xfD4zsUrf8raL6IkjC ex/w== X-Gm-Message-State: AGi0PuYC0WYABdydfEf78LRU/GhP1bNQ3evWN0xvbmXopzKzCtp0I0SG erx8ToluID+irVyMKTgjWYo= X-Google-Smtp-Source: APiQypJxPScbzin1gAqEtp7YfXzoTk3r5sECGCt8fLGvIJPsDZGobix/6on++OIWOfPKA7uEr+C9RQ== X-Received: by 2002:a63:d3:: with SMTP id 202mr474865pga.378.1586452618437; Thu, 09 Apr 2020 10:16:58 -0700 (PDT) Received: from localhost ([2601:647:4b01:ae80::51fb]) by smtp.gmail.com with ESMTPSA id a13sm6389758pfc.26.2020.04.09.10.16.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 09 Apr 2020 10:16:57 -0700 (PDT) Date: Thu, 9 Apr 2020 10:16:56 -0700 From: Fangrui Song To: "H.J. Lu" Cc: Binutils , Andreas Schwab Subject: Re: V3 [PATCH] gas: Extend .symver directive Message-ID: <20200409171656.5wxp43yuaqzweovx@gmail.com> References: <20200407121048.265065-1-hjl.tools@gmail.com> <87zhbnxybk.fsf@igel.home> <87v9mbxxoy.fsf@igel.home> <20200407212221.d5y4qghn3tnczmsf@gmail.com> <20200407235842.bpsbiifriyff42td@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-5.1 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, GIT_PATCH_2, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, KAM_INFOUSMEBIZ, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, 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: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2020 17:17:01 -0000 On 2020-04-08, H.J. Lu wrote: >On Wed, Apr 8, 2020 at 5:53 AM H.J. Lu wrote: >> >> On Tue, Apr 7, 2020 at 4:58 PM Fangrui Song wrote: >> > >> > On 2020-04-07, H.J. Lu wrote: >> > >On Tue, Apr 7, 2020 at 2:23 PM Fangrui Song wrote: >> > >> >> > >> On 2020-04-07, H.J. Lu via Binutils wrote: >> > >> >On Tue, Apr 7, 2020 at 5:55 AM Andreas Schwab wrote: >> > >> >> >> > >> >> On Apr 07 2020, H.J. Lu wrote: >> > >> >> >> > >> >> > The optional argument VISIBILITY updates the visibility of >> > >> >> > the original symbol. The valid visibilities are 'local', 'hidden', and >> > >> >> > 'remove'. The 'local' visibility makes the original symbol a local >> > >> >> > symbol (*note Local::). The 'hidden' visibility sets the visibility of >> > >> >> > the original symbol to 'hidden' (*note Hidden::). The 'remove' >> > >> >> > visibility removes the original symbol from the symbol table. If >> > >> >> > visibility isn't specified, the original symbol is unchanged. >> > >> >> >> > >> >> Looks good. >> > >> > >> > >> >Here is the updated patch. >> > >> > >> > >> >-- >> > >> >H.J. >> > >> >> > >> Let me summarize the current status: >> > >> >> > >> @@@ has the renaming semantics. (invented in 2000) >> > >> @ and @@ has the copying semantics. The original symbol remains which is usually cumbersome. >> > >> >> > >> We have received some requests: >> > >> >> > >> * Have a way to not retain the original symbol >> > >> * Have a way to define multiple versions `.symver something,foo@v1; .symver something,foo@v2. symver something,foo@@v3` >> > >> >> > >> >> > >> We have many choices. >> > >> >> > >> A. make @ @@ similar to @@@ >> > >> For @@, because of the linking rule (a @@ definition can satisfy a >> > >> referenced without a version), there should be no difference. >> > >> >> > >> For @, this will be a semantic break. Personally I don't think this >> > >> matters. I believe 99% projects don't need the original symbol and >> > >> will not notice anything. I also checked with FreeBSD developers. >> > > >> > >The original symbol name is used in glibc to bypass PLT within >> > >libc.so. >> > >> > This does not seem correct. By convention, the hidden aliases are those prefixed with __ >> > They are called to bypass PLT (STV_HIDDEN implies the non-preemptible property). >> > The original symbol does not have the prefix. >> > >> > When a linker sees memcpy@@GLIBC_2.14 , basically it inserts both "memcpy" and >> > "memcpy@GLIBC_2.14" into the symbol table. Both a reference without a version >> > "memcpy" and a reference with a version "memcpy@GLIBC_2.14" can be satisfied. >> >> As I said before, the original purpose of .symver is for glibc to >> implement symbol >> versioning. Given: >> >> --- >> const int _sys_nerr_internal = 200; >> __asm__ (".symver _sys_nerr_internal, sys_nerr@@GLIBC_2.12"); >> --- >> >> _sys_nerr_internal is used internally in glibc: >> >> File: libc_pic.a(_strerror.os) >> >> Relocation section '.rela.text' at offset 0x14e0 contains 17 entries: >> Offset Info Type Symbol's >> Value Symbol's Name + Addend >> 000000000000001c 0000001500000002 R_X86_64_PC32 >> 0000000000000000 _sys_nerr_internal - 4 >> 000000000000002c 0000001600000002 R_X86_64_PC32 >> 0000000000000000 _sys_errlist_internal - 4 >> >> --- >> char * >> __strerror_r (int errnum, char *buf, size_t buflen) >> { >> ... >> return (char *) _(_sys_errlist_internal[errnum]); >> } >> --- >> >> Also with -g, _sys_nerr_internal is also referenced in debug info. We >> just can't change .symver to rename. OK. >> > If the definition of "memcpy" also exists, I think it is somewhat special cased >> > in GNU ld and/or gold. In GNU ld, the actual implementation may be more complex >> > with indirect symbol involved. I believe the whole thing can be simplified a >> > lot by using renaming semantic. I debugged this area last year and may >> > misremember something. >> >> It is OK to extend .symver directive. Change it to rename semantic isn't an >> option. >> > >Updated patch to call symbol_remove to remove the symbol >if it isn't used in relocation. > >-- >H.J. Is the second .symver required to be after the definition? Case A .symver foo,foo@@v2 .symver foo,foo@v1 .globl foo foo: ret % as-new a.s a.s: Assembler messages: a.s: Error: local label `"0" (instance number 0 of a dollar label)' is not defined Case B .globl foo foo: ret .symver foo,foo@@v2 .symver foo,foo@v1 .hidden foo 5: 0000000000000000 0 NOTYPE GLOBAL HIDDEN 1 foo 6: 0000000000000000 0 NOTYPE GLOBAL HIDDEN 1 foo@@v2 7: 0000000000000000 0 NOTYPE GLOBAL DEFAULT 1 foo@v1