public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: KONRAD Frederic <frederic.konrad@adacore.com>
To: Alan Modra <amodra@gmail.com>
Cc: binutils@sourceware.org
Subject: Re: PR24511, nm should not mark symbols in .init_array as "t"
Date: Thu, 27 Feb 2020 15:03:00 -0000	[thread overview]
Message-ID: <5986aaf4-f81d-ace4-3920-94e3f854b62d@adacore.com> (raw)
In-Reply-To: <20200227065610.GG32593@bubble.grove.modra.org>



Le 2/27/20 à 7:56 AM, Alan Modra a écrit :
> 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.

Thanks for the fast answer,

I confirm that the patch below fix the behavior I had.

> 
> 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 '?';
> 

      parent reply	other threads:[~2020-02-27 15:03 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
2020-02-27  7:07     ` Alan Modra
2020-02-27 17:28       ` Hans-Peter Nilsson
2020-02-27 15:03     ` KONRAD Frederic [this message]

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=5986aaf4-f81d-ace4-3920-94e3f854b62d@adacore.com \
    --to=frederic.konrad@adacore.com \
    --cc=amodra@gmail.com \
    --cc=binutils@sourceware.org \
    /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).