From: Roland McGrath <mcgrathr@google.com>
To: "gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>
Cc: rguenth@gcc.gnu.org
Subject: Re: [PATCH PR other/77609] Let the assembler choose ELF section types for miscellaneous named sections
Date: Thu, 22 Sep 2016 20:25:00 -0000 [thread overview]
Message-ID: <CAB=4xhqjPwteqOf7TD-22AG6--wLPGZiSF9XZUb8C_nDvW2S5A@mail.gmail.com> (raw)
In-Reply-To: <CAB=4xhrks=KVuKKBOxwS9iV9==sdhKmu_9RqopiSeKC-+Hb08g@mail.gmail.com>
ping?
On Thu, Sep 15, 2016 at 4:09 PM, Roland McGrath <mcgrathr@google.com> wrote:
> This fixes https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77609 (which I've
> just filed).
>
> OK for trunk?
>
> I'm not sure if this kind of fix is appropriate for gcc-6-branch or not,
> but I'd like to backport it there too if it is acceptable.
>
>
> Thanks,
> Roland
>
>
> gcc/
> 2016-09-15 Roland McGrath <<mcgrathr@google.com>
>
> PR other/77609
> * varasm.c (default_section_type_flags): Set SECTION_NOTYPE for
> any section for which we don't know a specific type it should have,
> regardless of name. Previously this was done only for the exact
> names ".init_array", ".fini_array", and ".preinit_array".
>
> diff --git a/gcc/varasm.c b/gcc/varasm.c
> index 00a9b30..0d7ea38 100644
> --- a/gcc/varasm.c
> +++ b/gcc/varasm.c
> @@ -6210,15 +6210,20 @@ default_section_type_flags (tree decl, const
> char *name, int reloc)
> || strncmp (name, ".gnu.linkonce.tb.", 17) == 0)
> flags |= SECTION_TLS | SECTION_BSS;
>
> - /* These three sections have special ELF types. They are neither
> - SHT_PROGBITS nor SHT_NOBITS, so when changing sections we don't
> - want to print a section type (@progbits or @nobits). If someone
> - is silly enough to emit code or TLS variables to one of these
> - sections, then don't handle them specially. */
> - if (!(flags & (SECTION_CODE | SECTION_BSS | SECTION_TLS))
> - && (strcmp (name, ".init_array") == 0
> - || strcmp (name, ".fini_array") == 0
> - || strcmp (name, ".preinit_array") == 0))
> + /* Various sections have special ELF types that the assembler will
> + assign by default based on the name. They are neither SHT_PROGBITS
> + nor SHT_NOBITS, so when changing sections we don't want to print a
> + section type (@progbits or @nobits). Rather than duplicating the
> + assembler's knowledge of what those special name patterns are, just
> + let the assembler choose the type if we don't know a specific
> + reason to set it to something other than the default. SHT_PROGBITS
> + is the default for sections whose name is not specially known to
> + the assembler, so it does no harm to leave the choice to the
> + assembler when @progbits is the best thing we know to use. If
> + someone is silly enough to emit code or TLS variables to one of
> + these sections, then don't handle them specially. */
> + if (!(flags & (SECTION_CODE | SECTION_BSS | SECTION_TLS | SECTION_ENTSIZE))
> + && !(HAVE_COMDAT_GROUP && (flags & SECTION_LINKONCE)))
> flags |= SECTION_NOTYPE;
>
> return flags;
next prev parent reply other threads:[~2016-09-22 20:15 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-15 23:41 Roland McGrath
2016-09-22 20:25 ` Roland McGrath [this message]
2018-02-24 9:54 ` Roland McGrath via gcc-patches
2018-02-27 4:11 ` Ian Lance Taylor via gcc-patches
2018-02-28 2:01 ` Roland McGrath via gcc-patches
2018-02-28 4:14 ` Ian Lance Taylor via gcc-patches
2018-02-28 23:56 ` Roland McGrath via gcc-patches
2018-03-01 0:07 ` Ian Lance Taylor via gcc-patches
2018-03-01 0:19 ` Roland McGrath via gcc-patches
2018-04-28 11:58 ` Roland McGrath via gcc-patches
2018-05-04 18:25 ` Roland McGrath via gcc-patches
2018-05-04 18:44 ` Ian Lance Taylor via gcc-patches
2018-05-05 23:38 ` Roland McGrath via gcc-patches
2018-06-14 0:52 ` Roland McGrath via gcc-patches
2018-06-14 1:05 ` Ian Lance Taylor via gcc-patches
2018-06-14 1:23 ` Roland McGrath via gcc-patches
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='CAB=4xhqjPwteqOf7TD-22AG6--wLPGZiSF9XZUb8C_nDvW2S5A@mail.gmail.com' \
--to=mcgrathr@google.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=rguenth@gcc.gnu.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).