From: Michael Matz <matz@suse.de>
To: Pedro Alves <pedro@palves.net>
Cc: binutils@sourceware.org
Subject: Re: [PATCH] Support SHF_GNU_RETAIN ELF section flag
Date: Tue, 29 Sep 2020 13:55:06 +0000 (UTC) [thread overview]
Message-ID: <alpine.LSU.2.20.2009291353370.20802@wotan.suse.de> (raw)
In-Reply-To: <810fbf87-ed6d-9d11-62ba-c92dd75b52b8@palves.net>
Hello,
On Tue, 29 Sep 2020, Pedro Alves wrote:
> > We should remember that this thread is about the addition of the section
> > flag, which affects but isn't directly related to how it's going to be
> > used in source code in a high level language. If it's the pre-existing
> > "used" or a new "retain" attribute, or an attribute at all or just left to
> > section markers or pragmas: a discussion about that doesn't need to hold
> > up the addition of the ELF feature.
>
> I never suggested that it should (hold up the ELF feature).
Okay.
> I was replying to this in the original message:
>
> > 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.
>
> Discussing the intention of a new proposed mechanism seems apropos.
> Sometimes the high level usage model influences the low level design too.
Definitely. But used vs retain attribute seemed like a too detailed
distinction to make at this point. For the GCC patches it's totally
appropriate, though, as planned.
Ciao,
Michael.
next prev parent reply other threads:[~2020-09-29 13:55 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
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 [this message]
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=alpine.LSU.2.20.2009291353370.20802@wotan.suse.de \
--to=matz@suse.de \
--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).