public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Alan Modra <amodra@gmail.com>
To: KONRAD Frederic <frederic.konrad@adacore.com>
Cc: binutils@sourceware.org
Subject: Re: PR24511, nm should not mark symbols in .init_array as "t"
Date: Thu, 27 Feb 2020 06:56:00 -0000	[thread overview]
Message-ID: <20200227065610.GG32593@bubble.grove.modra.org> (raw)
In-Reply-To: <1b774bd1-68a9-bcf7-795b-e3c545c4faa6@adacore.com>

On Wed, Feb 26, 2020 at 06:08:46PM +0100, KONRAD Frederic wrote:
> It seems that this patch has the side effect of marking the symbols in .idata as
> "D" instead of "I" previously.  Is that expected?

I guess so, but also wrong.  The patch should not have changed the
order of decode_section_type and coff_section_type calls.  I'm going
to commit this to trunk and a patch that just reverses the calls to
the branch, after testing.

	* syms.c (stt): Trim off all but 'e', 'i' and 'p' entries.
	(coff_section_type): Adjust comment.
	(decode_section_type): Likewise.  Call coff_section_type before
	decode_section_type.
	(bfd_decode_symclass): Use 'c' for common sections other than
	the standard one.

diff --git a/bfd/syms.c b/bfd/syms.c
index 8a5c89767a..c1de8ebab1 100644
--- a/bfd/syms.c
+++ b/bfd/syms.c
@@ -565,30 +565,15 @@ struct section_to_type
   char type;
 };
 
-/* Map section names to POSIX/BSD single-character symbol types.
+/* Map special section names to POSIX/BSD single-character symbol types.
    This table is probably incomplete.  It is sorted for convenience of
    adding entries.  Since it is so short, a linear search is used.  */
 static const struct section_to_type stt[] =
 {
-  {".bss", 'b'},
-  {"code", 't'},		/* MRI .text */
-  {".data", 'd'},
-  {"*DEBUG*", 'N'},
-  {".debug", 'N'},		/* MSVC's .debug (non-standard debug syms) */
   {".drectve", 'i'},		/* MSVC's .drective section */
   {".edata", 'e'},		/* MSVC's .edata (export) section */
-  {".fini", 't'},		/* ELF fini section */
   {".idata", 'i'},		/* MSVC's .idata (import) section */
-  {".init", 't'},		/* ELF init section */
   {".pdata", 'p'},		/* MSVC's .pdata (stack unwind) section */
-  {".rdata", 'r'},		/* Read only data.  */
-  {".rodata", 'r'},		/* Read only data.  */
-  {".sbss", 's'},		/* Small BSS (uninitialized data).  */
-  {".scommon", 'c'},		/* Small common.  */
-  {".sdata", 'g'},		/* Small initialized data.  */
-  {".text", 't'},
-  {"vars", 'd'},		/* MRI .data */
-  {"zerovars", 'b'},		/* MRI .bss */
   {0, 0}
 };
 
@@ -596,8 +581,7 @@ static const struct section_to_type stt[] =
    section S, or '?' for an unknown COFF section.
 
    Check for leading strings which match, followed by a number, '.',
-   or '$' so .text5 matches the .text entry, but .init_array doesn't
-   match the .init entry.  */
+   or '$' so .idata5 matches the .idata entry.  */
 
 static char
 coff_section_type (const char *s)
@@ -619,7 +603,7 @@ coff_section_type (const char *s)
    SECTION, or '?' for an unknown section.  This uses section flags to
    identify sections.
 
-   FIXME These types are unhandled: c, i, e, p.  If we handled these also,
+   FIXME These types are unhandled: e, i, p.  If we handled these also,
    we could perhaps obsolete coff_section_type.  */
 
 static char
@@ -668,7 +652,12 @@ bfd_decode_symclass (asymbol *symbol)
   char c;
 
   if (symbol->section && bfd_is_com_section (symbol->section))
-    return 'C';
+    {
+      if (symbol->section == bfd_com_section_ptr)
+	return 'C';
+      else
+	return 'c';
+    }
   if (bfd_is_und_section (symbol->section))
     {
       if (symbol->flags & BSF_WEAK)
@@ -705,9 +694,9 @@ bfd_decode_symclass (asymbol *symbol)
     c = 'a';
   else if (symbol->section)
     {
-      c = decode_section_type (symbol->section);
+      c = coff_section_type (symbol->section->name);
       if (c == '?')
-	c = coff_section_type (symbol->section->name);
+	c = decode_section_type (symbol->section);
     }
   else
     return '?';

-- 
Alan Modra
Australia Development Lab, IBM

  reply	other threads:[~2020-02-27  6:56 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-04  7:57 Alan Modra
2020-02-26 17:09 ` KONRAD Frederic
2020-02-27  6:56   ` Alan Modra [this message]
2020-02-27  7:07     ` Alan Modra
2020-02-27 17:28       ` Hans-Peter Nilsson
2020-02-27 15:03     ` KONRAD Frederic

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=20200227065610.GG32593@bubble.grove.modra.org \
    --to=amodra@gmail.com \
    --cc=binutils@sourceware.org \
    --cc=frederic.konrad@adacore.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).