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
next prev parent 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).