From: Jozef Lawrynowicz <jozef.l@mittosystems.com>
To: Pedro Alves <pedro@palves.net>
Cc: binutils@sourceware.org
Subject: Re: [PATCH] Support SHF_GNU_RETAIN ELF section flag
Date: Mon, 28 Sep 2020 13:28:22 +0100 [thread overview]
Message-ID: <20200928122822.nql5aatbpo7kr5si@jozef-acer-manjaro> (raw)
In-Reply-To: <a6cd1d9b-fa36-be55-8fae-76d6eafc7b2c@palves.net>
On Mon, Sep 28, 2020 at 12:35:28PM +0100, Pedro Alves wrote:
> On 9/22/20 9:29 PM, Jozef Lawrynowicz wrote:
> >
> > The overall intention for this new flag is to enable a new "retain"
> > attribute to be applied to declarations of functions and data in the
> > source code. This attribute can be used to ensure the definition
> > associated with the declaration is present in the linked output file,
> > even if linker garbage collection would normally remove the containing
> > section because it is unused.
>
> On a high level, this sounds pretty much like __attribute__((used)).
> Couldn't the new section flag be wired to that attribute?
>
> I mean, isn't it a bug if linker garbage collection eliminates a
> function marked with __attribute__((used)) ?
>
> "used
>
> This attribute, attached to a function, means that code must be emitted
> for the function even if it appears that the function is not referenced."
>
> I was surprised to not see any mention of the "used" attribute in the
> proposal, neither here, nor in gABI mailing list discussion linked.
> But maybe I missed it.
In an early version of the implementation, I tried tying the
behavior to the "used" attribute, but it caused some problems.
I believe the issues mainly came from the usage of "used" in
libgcc/crtstuff.c. The functions there are static and unused, so have
"used" applied to prevent removal by the compiler. However, that does
not mean that all of those functions should be included in every program
linking against libgcc.
I don't remember the exact failure mode, I think it may have been that
lots of tests were failing due to "multiple definition of ..." errors,
or perhaps "undefined reference to ...".
The "retain" attribute implies the "used" attribute, so if the user
wants to prevent compiler optimization AND linker optimization, "retain"
can be used. To prevent only compiler optimization, "used" should be
applied.
Jozef
>
> Pedro Alves
next prev parent reply other threads:[~2020-09-28 12:28 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-22 20:29 Jozef Lawrynowicz
2020-09-22 23:24 ` Hans-Peter Nilsson
2020-09-22 23:58 ` H.J. Lu
2020-09-23 1:09 ` Fangrui Song
2020-09-23 9:58 ` Jozef Lawrynowicz
2020-09-23 13:39 ` H.J. Lu
2020-09-23 13:51 ` Michael Matz
2020-09-23 16:52 ` Jozef Lawrynowicz
2020-09-23 17:13 ` H.J. Lu
2020-09-23 18:47 ` Jozef Lawrynowicz
2020-09-23 19:03 ` H.J. Lu
2020-09-23 20:04 ` Jozef Lawrynowicz
2020-09-23 20:17 ` H.J. Lu
2020-09-23 23:29 ` Fangrui Song
2020-09-24 11:39 ` Jozef Lawrynowicz
2020-09-24 19:06 ` Fangrui Song
2020-09-24 13:27 ` Michael Matz
2020-09-24 13:18 ` H.J. Lu
2020-09-24 13:49 ` Jozef Lawrynowicz
2020-09-24 13:59 ` H.J. Lu
2020-09-24 16:56 ` Jozef Lawrynowicz
2020-09-24 17:04 ` H.J. Lu
2020-09-24 17:18 ` Jozef Lawrynowicz
2020-09-24 17:37 ` H.J. Lu
2020-09-23 12:13 ` Jozef Lawrynowicz
2020-09-23 13:59 ` Alan Modra
2020-09-23 16:54 ` Jozef Lawrynowicz
2020-09-28 11:35 ` Pedro Alves
2020-09-28 12:28 ` Jozef Lawrynowicz [this message]
2020-09-28 14:46 ` Pedro Alves
2020-09-29 13:18 ` Michael Matz
2020-09-29 13:22 ` Jozef Lawrynowicz
2020-09-29 13:48 ` Pedro Alves
2020-09-29 13:55 ` Michael Matz
2020-09-29 14:04 ` Pedro Alves
2020-09-29 14:10 ` Michael Matz
2020-09-29 14:11 ` Pedro Alves
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=20200928122822.nql5aatbpo7kr5si@jozef-acer-manjaro \
--to=jozef.l@mittosystems.com \
--cc=binutils@sourceware.org \
--cc=pedro@palves.net \
/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).