public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "i at maskray dot me" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/95095] New: Feature request: support -fno-unique-section-names
Date: Tue, 12 May 2020 21:57:51 +0000	[thread overview]
Message-ID: <bug-95095-4@http.gcc.gnu.org/bugzilla/> (raw)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95095

            Bug ID: 95095
           Summary: Feature request: support -fno-unique-section-names
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: i at maskray dot me
  Target Milestone: ---

-ffunction-sections produces sections .text.foo , .text.bar , etc, which can
take significant amount of string table space.

In clang, -fno-unique-section-names emits multiple ".text" sections which can
share the section name. Multiple sections with the same name require the new
GNU as feature https://sourceware.org/bugzilla/show_bug.cgi?id=25380 (binutils
2.35).

For .text.exit.* .text.unlikely.* .text.hot.* .text.startup.* , the preferred
sections are .text.exit. .text.unlikely. .text.hot. .text.startup. The trailing
dots can avoid a linker problem described in https://reviews.llvm.org/D79600

--------- pasted below for your convenience

GNU ld's internal linker script uses
(https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=add44f8d5c5c05e08b11e033127a744d61c26aee)

.text           :
{
  *(.text.unlikely .text.*_unlikely .text.unlikely.*)
  *(.text.exit .text.exit.*)
  *(.text.startup .text.startup.*)
  *(.text.hot .text.hot.*)
  *(SORT(.text.sorted.*))
  *(.text .stub .text.* .gnu.linkonce.t.*)
  /* .gnu.warning sections are handled specially by elf.em.  */
  *(.gnu.warning)
}
Because *(.text.exit .text.exit.*) is ordered before *(.text .text.*), in a
-ffunction-sections build, the C library function exit will be placed before
other functions.
gold's -z keep-text-section-prefix has the same problem.

In lld, -z keep-text-section-prefix recognizes
.text.{exit,hot,startup,unlikely,unknown}.*, but not
.text.{exit,hot,startup,unlikely,unknown}, to avoid the strange placement
problem.

             reply	other threads:[~2020-05-12 21:57 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-12 21:57 i at maskray dot me [this message]
2020-05-24 22:08 ` [Bug target/95095] " i at maskray dot me
2021-01-16 20:49 ` segher at gcc dot gnu.org
2021-01-16 21:00 ` i at maskray dot me
2021-01-22  0:57 ` segher at kernel dot crashing.org
2021-01-22  1:38 ` i at maskray dot me
2021-01-25 16:30 ` segher at gcc dot gnu.org
2021-01-25 17:58 ` i at maskray dot me
2021-01-25 19:04 ` segher at gcc dot gnu.org
2021-01-25 20:11 ` i at maskray dot me

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=bug-95095-4@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@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).