public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: "H.J. Lu" <hjl.tools@gmail.com>
To: Faraz Shahbazker <faraz.shahbazker@imgtec.com>
Cc: Binutils <binutils@sourceware.org>
Subject: Re: [committed, PATCH] Always create dynsym section with dynamic sections
Date: Sun, 24 Apr 2016 01:43:00 -0000	[thread overview]
Message-ID: <CAMe9rOpuLNQT-m5ym56FOeCDUJWcBB2fkB-okvu96MX7pn83nA@mail.gmail.com> (raw)
In-Reply-To: <571BCC3A.6090700@imgtec.com>

[-- Attachment #1: Type: text/plain, Size: 837 bytes --]

On Sat, Apr 23, 2016 at 12:25 PM, Faraz Shahbazker
<faraz.shahbazker@imgtec.com> wrote:
>>>> You said dynsym should be treated treated the same for static and
>>>> dynamic executables.   dynsymcount is number of dynsym + 1 in
>>>> dynamic executable.  Why isn't it true for static executable?
>>>
>>> It is, or at least used to be, before this patch. It still is for both,
>>> before renumbering. But now the +1 only happens for dynamic executables
>>> when renumbering.
>>
>> Then what is wrong to always +1 for both dynamic and static
>> executables?
>
> Aah, now I see! Ever since the table was created, the count was at least 1.
> You are saying it should always remain at least 1 no matter what. Had a quick
> look through other uses of the field and it looks safe enough to me.
>

Here is a patch.  Does it work for you?

-- 
H.J.

[-- Attachment #2: 0001-Always-count-the-NULL-entry-in-dynamic-symbol-table.patch --]
[-- Type: text/x-patch, Size: 1870 bytes --]

From f54270fc5a342ed8ead17e95731c3b0c2e7a1ecc Mon Sep 17 00:00:00 2001
From: "H.J. Lu" <hjl.tools@gmail.com>
Date: Sat, 23 Apr 2016 18:37:59 -0700
Subject: [PATCH] Always count the NULL entry in dynamic symbol table

There is an unused NULL entry at the head of dynamic symbol table which
we must account for in our count even if the table is empty or unused.

	* elf-bfd.h (elf_link_hash_table): Update comments for
	dynsymcount.
	* elflink.c (_bfd_elf_link_renumber_dynsyms): Always count for
	the unused NULL entry at the head of dynamic symbol table.
---
 bfd/elf-bfd.h | 2 +-
 bfd/elflink.c | 8 +++-----
 2 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/bfd/elf-bfd.h b/bfd/elf-bfd.h
index 5dce70e..de721f0 100644
--- a/bfd/elf-bfd.h
+++ b/bfd/elf-bfd.h
@@ -520,7 +520,7 @@ struct elf_link_hash_table
   union gotplt_union init_got_offset;
   union gotplt_union init_plt_offset;
 
-  /* The number of symbols found in the link which must be put into
+  /* The number of symbols found in the link which is intended for
      the .dynsym section.  */
   bfd_size_type dynsymcount;
 
diff --git a/bfd/elflink.c b/bfd/elflink.c
index 6f67266..17751cf 100644
--- a/bfd/elflink.c
+++ b/bfd/elflink.c
@@ -905,11 +905,9 @@ _bfd_elf_link_renumber_dynsyms (bfd *output_bfd,
 			  elf_link_renumber_hash_table_dynsyms,
 			  &dynsymcount);
 
-  /* There is an unused NULL entry at the head of the table which
-     we must account for in our count.  We always create the dynsym
-     section, even if it is empty, with dynamic sections.  */
-  if (elf_hash_table (info)->dynamic_sections_created)
-    ++dynsymcount;
+  /* There is an unused NULL entry at the head of the table which we
+     must account for in our count even if the table is empty.  */
+  dynsymcount++;
 
   elf_hash_table (info)->dynsymcount = dynsymcount;
   return dynsymcount;
-- 
2.5.5


  reply	other threads:[~2016-04-24  1:43 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-23  0:33 H.J. Lu
2016-04-22 17:04 ` Faraz Shahbazker
2016-04-22 18:11   ` H.J. Lu
2016-04-22 18:56     ` Faraz Shahbazker
2016-04-22 19:29       ` H.J. Lu
2016-04-22 21:49         ` Faraz Shahbazker
2016-04-22 22:57           ` H.J. Lu
2016-04-22 23:09             ` Faraz Shahbazker
2016-04-22 23:24           ` H.J. Lu
2016-04-22 23:25             ` H.J. Lu
2016-04-23  1:38             ` Faraz Shahbazker
2016-04-23  2:05               ` H.J. Lu
2016-04-23  2:32                 ` Faraz Shahbazker
2016-04-23 12:27                   ` H.J. Lu
2016-04-23 15:25                     ` Faraz Shahbazker
2016-04-23 15:36                       ` H.J. Lu
2016-04-23 19:26                         ` Faraz Shahbazker
2016-04-24  1:43                           ` H.J. Lu [this message]
2016-04-25  2:18                             ` Faraz Shahbazker
2016-04-25 12:47                               ` H.J. Lu
2016-04-25 13:41                                 ` Alan Modra
2016-04-25 16:03                                   ` H.J. Lu
2016-04-26  2:08                                     ` Alan Modra

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAMe9rOpuLNQT-m5ym56FOeCDUJWcBB2fkB-okvu96MX7pn83nA@mail.gmail.com \
    --to=hjl.tools@gmail.com \
    --cc=binutils@sourceware.org \
    --cc=faraz.shahbazker@imgtec.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).