From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) by sourceware.org (Postfix) with ESMTPS id 34C2B385DC30 for ; Wed, 26 Jan 2022 03:07:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 34C2B385DC30 Received: by mail-pg1-x530.google.com with SMTP id j10so7814880pgc.6 for ; Tue, 25 Jan 2022 19:07:55 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=RQjkqvsekmKRdv3xFYTcs5KoGdY/ed721K0gJcnF354=; b=zkjETToUhsoMSUKLB7kwogPCKmBhM56qUmwmoWgsCewAJxkSjyAn0eqS6YAtXdwu/R UUWzPWv7HZ5JoP0dbegaGYmVygKkeOW8ABEoURSD/Br8u6sVH31HSU6U8o1WRsj4M47C 4MvVgDHOSTRPTciq3KiYK0/mcBMyvelr/IFiZ8cU9Ac5Aex35iC2U4xh8hw7QCBg559D NEXiQOe0XxWgUtKW9YZNwVfbiTtPV7k+qpdsVoVby2Y9O/ZJK1zDWFNFGr2ibrBMol1f p/0PwQ+enq1sioPXUD0GysHCx4QH0R9wmVNmI6cckBa3gtf3wGercE+yJ5yg4D+6kpI5 7xFA== X-Gm-Message-State: AOAM531/w5zbhsohJVgJoNEoxE3snKJRBYLroQ3DuiHw9SExxj65vfN4 QgE6BX8Lz+qW8RWz7toAY2VUlBC7NuE= X-Google-Smtp-Source: ABdhPJwNiFAUt5o4KpZcjcuv/6FBK2tFiR3dR+2WjXt6ddnCAtnZLavoTPomA5gwDZ4sSdRtuERThA== X-Received: by 2002:a05:6a00:2312:b0:4ca:dec8:d11d with SMTP id h18-20020a056a00231200b004cadec8d11dmr4417580pfh.74.1643166474390; Tue, 25 Jan 2022 19:07:54 -0800 (PST) Received: from squeak.grove.modra.org ([2406:3400:51d:8cc0:d3f1:8f46:c664:200e]) by smtp.gmail.com with ESMTPSA id s9sm10133035pgm.76.2022.01.25.19.07.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 25 Jan 2022 19:07:53 -0800 (PST) Received: by squeak.grove.modra.org (Postfix, from userid 1000) id 9FF3F1140450; Wed, 26 Jan 2022 13:37:50 +1030 (ACDT) Date: Wed, 26 Jan 2022 13:37:50 +1030 From: Alan Modra To: "H.J. Lu" Cc: binutils@sourceware.org Subject: Re: [PATCH] elf: Don't set VER_FLG_WEAK Message-ID: References: <20220126001953.652545-1-hjl.tools@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220126001953.652545-1-hjl.tools@gmail.com> X-Spam-Status: No, score=-3037.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, 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: 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: Wed, 26 Jan 2022 03:07:56 -0000 On Tue, Jan 25, 2022 at 04:19:53PM -0800, H.J. Lu via Binutils wrote: > On Solaris, VER_FLG_WEAK indicates a weak version definition with no > symbols associated with it. It is used to verify the existence of a > particular implementation without any symbol references to the weak > version. Don't set VER_FLG_WEAK since it is unused in binutils. Can you tell me why the presence of this flag is bad? I don't see it affecting anything in binutils or glibc. VER_FLG_WEAK in version refs does affect resolution of symbol, but I can't see how a VER_FLG_WEAK in a version def can transfer over to a ref if the def is unused. > PR ld/28814 > * elflink.c (bfd_elf_size_dynamic_sections): Don't set > VER_FLG_WEAK. > --- > bfd/elflink.c | 4 ---- > 1 file changed, 4 deletions(-) > > diff --git a/bfd/elflink.c b/bfd/elflink.c > index 2677561478d..ffb4506958f 100644 > --- a/bfd/elflink.c > +++ b/bfd/elflink.c > @@ -6921,10 +6921,6 @@ bfd_elf_size_dynamic_sections (bfd *output_bfd, > > def.vd_version = VER_DEF_CURRENT; > def.vd_flags = 0; > - if (t->globals.list == NULL > - && t->locals.list == NULL > - && ! t->used) > - def.vd_flags |= VER_FLG_WEAK; > def.vd_ndx = t->vernum + (info->create_default_symver ? 2 : 1); > def.vd_cnt = cdeps + 1; > def.vd_hash = bfd_elf_hash (t->name); > -- > 2.34.1 -- Alan Modra Australia Development Lab, IBM