From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 118856 invoked by alias); 23 Apr 2016 02:05:59 -0000 Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org Received: (qmail 118812 invoked by uid 89); 23 Apr 2016 02:05:55 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mail-qg0-f51.google.com Received: from mail-qg0-f51.google.com (HELO mail-qg0-f51.google.com) (209.85.192.51) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Sat, 23 Apr 2016 02:05:37 +0000 Received: by mail-qg0-f51.google.com with SMTP id f74so59957379qge.2 for ; Fri, 22 Apr 2016 19:05:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=oVs9G0ADoAEpeGBE4ktzozA3oK40ZL9W9MlQXzGh1hM=; b=hcbUdU66S6QgMlatW5TZG/ep+QwKN+Pjh0GrQ6nZUhey1/HaiYB6zgAzU0TIHWqyEB cE7gC97q8+zcygBy0goFVJvhsc0HS/bPn5ujIAOtRcfUPBVk0HkmCPRq3YkzxU8tyf4X l51OSHLIYKHlAODFa8dU9pNFbYJilR7iIY0VvOFuoRLiQzh5LD98Yv+8vxoxTDCXCzYs dVdELDheBn5iB+Mh4Fz6CrcIot7tbke/OiLOrsiHPCyGNn3KKPYhZmpQxtSBf/sbL45m VOWD4QYoK1ibL08BPJI407HqpBVBzrbCwkBJtnGuRH0t7uAQXo1ionqWzZr/WIkAMWcc x7AA== X-Gm-Message-State: AOPr4FXZXzbumEb2rYpXziwmm2pKhPAHb2/vg9bIr8cKiBcyNytjg+sJSyZ5Lpert1XdJlcmtnn2xXILZUslIA== MIME-Version: 1.0 X-Received: by 10.140.228.68 with SMTP id y65mr24880456qhb.47.1461377135748; Fri, 22 Apr 2016 19:05:35 -0700 (PDT) Received: by 10.55.217.134 with HTTP; Fri, 22 Apr 2016 19:05:35 -0700 (PDT) In-Reply-To: <571AD1EE.1040005@imgtec.com> References: <20160223003208.GA30022@intel.com> <571A59A8.4000700@imgtec.com> <571A73BE.4000709@imgtec.com> <571AD1EE.1040005@imgtec.com> Date: Sat, 23 Apr 2016 02:05:00 -0000 Message-ID: Subject: Re: [committed, PATCH] Always create dynsym section with dynamic sections From: "H.J. Lu" To: Faraz Shahbazker Cc: Binutils Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2016-04/txt/msg00388.txt.bz2 On Fri, Apr 22, 2016 at 6:37 PM, Faraz Shahbazker wrote: > On 04/22/16 16:24, H.J. Lu wrote: >> On Fri, Apr 22, 2016 at 2:49 PM, Faraz Shahbazker >> wrote: >>> On 04/22/2016 12:28 PM, H.J. Lu wrote: >>>> On Fri, Apr 22, 2016 at 11:55 AM, Faraz Shahbazker >>>>> + if (dynsymcount != 0 || elf_hash_table (info)->dynamic_sections_created) >>>>> + ++dynsymcount; >>>> >>>> Are you saying dynamic_sections_created is 0 for MIPS here >>>> and will become 1 later? >>> >>> No, it will remain 0. The link is static, but the hash_table is still used to >>> record global symbols that have GOT relocations against them. Ofc, this >>> hash_table does not result in creation of a dynsym section, because well, >>> dynamic_sections_created is 0. >>> >>> Check the list of callers to bfd_elf_link_record_dynamic_symbol(), a number of >>> architectures use the link_hash_table in situations where it is not clear whether it is >>> being used to track dynamic symbols for a dynamic executable, as it is for x86. >>> >> >> So MIPS doesn't have dynamic symbols in this case. It just borrows >> dynsymcount for different purpose. Is this correct? > > Not quite! MIPS is expecting dynsymcount to count the number of symbols > that would have gone in to the .dynsym, even for a static executable. That way > parts of the arch-specific code can remain agnostic to the static/dynamic nature > of the link. It may not be used exactly as documented, but its not being used > for what one would call a different purpose. > > All we need is for handling of dynsymcount when renumbering to be consistent with > its initialization. If the initial increment for a NULL symbol was not gated by > dynamic_sections_created, then the increment when renumbering should also not. > If the increment when renumbering has to be gated by dynamic_sections_created, > then the initial increment must also be so. > >From what you are saying, shouldn't dynsymcount be incremented unconditionally? -- H.J.