* Re: RFC Adding a section group flag of 0 [not found] <000000000000e0ce64057f1c76ed@google.com> @ 2019-01-01 0:00 ` Nick Clifton 0 siblings, 0 replies; 5+ messages in thread From: Nick Clifton @ 2019-01-01 0:00 UTC (permalink / raw) To: gnu-gabi Hi Ali, [I tried posting this to generic-abi@googlegroups.com but it was rejected. I hope that it will reach you via the gnu-gabi email address]. > Nick, I am curious why gcc produces these GROUP sections. Not > challenging their right to do so, but wondering what benefit > they derive from it. It is not gcc itself. It is the annobin plugin to gcc. The plugin creates new note sections to describe the contents of any code section created by gcc. It puts the note section and the code section together into a group so that if the linker discards the code section it will also discard the note section. The notes are used by a security checking tool in order to make sure that the code has been compiled according to a specified set of guidelines. In order for this to work, accurate notes are needed and having extraneous notes referring to discarded code sections would be a bad thing. Cheers Nick PS. If you are interested in the actual code, it is under the GPL. Check out the annobin package in Fedora. The specification for the notes is also available here: https://fedoraproject.org/wiki/Toolchain/Watermark ^ permalink raw reply [flat|nested] 5+ messages in thread
[parent not found: <24c0c8d8-44e6-ab81-bdfb-43af8b53323b@redhat.com>]
[parent not found: <mvm5zuxg8wt.fsf@suse.de>]
* Re: RFC Adding a section group flag of 0 [not found] ` <mvm5zuxg8wt.fsf@suse.de> @ 2019-01-01 0:00 ` Nick Clifton 2019-01-01 0:00 ` Andreas Schwab 0 siblings, 1 reply; 5+ messages in thread From: Nick Clifton @ 2019-01-01 0:00 UTC (permalink / raw) To: Andreas Schwab; +Cc: binutils, ruiu, peter.smith, sguelton, gnu-gabi Hi Andreas, >> I would like to propose adding a new value to this list. A value of 0. > > The value of 0 just means the absence of flags, doesn't it? Right. I just want to make it clear that a value of 0 is allowed and that it means that there are no special processing semantics required. The standard, as currently written is not 100% clear on this: The section data of a SHT_GROUP section is an array of Elf32_Word entries. The first entry is a flag word. The remaining entries are a sequence of section header indices. The following flags are currently defined: Figure 4-13: Section Group Flags Name Value GRP_COMDAT 0x1 GRP_MASKOS 0x0ff00000 GRP_MASKPROC 0xf0000000 GRP_COMDAT This is a COMDAT group. It may duplicate another COMDAT [...] The problem is that this does not make it clear whether a value of zero is allowed or an error. So all I am really asking for is some clarification in the wording of this part of the standard. Cheers Nick ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: RFC Adding a section group flag of 0 2019-01-01 0:00 ` Nick Clifton @ 2019-01-01 0:00 ` Andreas Schwab 2019-01-01 0:00 ` Cary Coutant 0 siblings, 1 reply; 5+ messages in thread From: Andreas Schwab @ 2019-01-01 0:00 UTC (permalink / raw) To: Nick Clifton; +Cc: binutils, ruiu, peter.smith, sguelton, gnu-gabi On Jan 09 2019, Nick Clifton <nickc@redhat.com> wrote: > The problem is that this does not make it clear whether a value > of zero is allowed or an error. Why would the absence of flag 0 be different from the absence of any other flag? Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: RFC Adding a section group flag of 0 2019-01-01 0:00 ` Andreas Schwab @ 2019-01-01 0:00 ` Cary Coutant 2019-01-01 0:00 ` Rui Ueyama via gnu-gabi 0 siblings, 1 reply; 5+ messages in thread From: Cary Coutant @ 2019-01-01 0:00 UTC (permalink / raw) To: Andreas Schwab Cc: Nick Clifton, binutils, Rui Ueyama, Peter Smith, sguelton, gnu-gabi > > The problem is that this does not make it clear whether a value > > of zero is allowed or an error. > > Why would the absence of flag 0 be different from the absence of any > other flag? I'm OK with adding a clarifying statement to the spec. -cary ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: RFC Adding a section group flag of 0 2019-01-01 0:00 ` Cary Coutant @ 2019-01-01 0:00 ` Rui Ueyama via gnu-gabi 0 siblings, 0 replies; 5+ messages in thread From: Rui Ueyama via gnu-gabi @ 2019-01-01 0:00 UTC (permalink / raw) To: Cary Coutant Cc: Andreas Schwab, Nick Clifton, binutils, Peter Smith, sguelton, gnu-gabi After carefully reading the page (*), I also found that the value 0 can be interpreted as an absence of any flag and has no semantics other than defining a group, which would probably means that they should be discarded or retained as a group when GC runs. But I don't think it is very clear; we probably should add a clarifying statement to the spec. * https://docs.oracle.com/cd/E19120-01/open.solaris/819-0690/chapter7-26/index.html On Wed, Jan 9, 2019 at 10:11 AM Cary Coutant <ccoutant@gmail.com> wrote: > > > > The problem is that this does not make it clear whether a value > > > of zero is allowed or an error. > > > > Why would the absence of flag 0 be different from the absence of any > > other flag? > > I'm OK with adding a clarifying statement to the spec. > > -cary ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2019-01-10 15:48 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <000000000000e0ce64057f1c76ed@google.com> 2019-01-01 0:00 ` RFC Adding a section group flag of 0 Nick Clifton [not found] <24c0c8d8-44e6-ab81-bdfb-43af8b53323b@redhat.com> [not found] ` <mvm5zuxg8wt.fsf@suse.de> 2019-01-01 0:00 ` Nick Clifton 2019-01-01 0:00 ` Andreas Schwab 2019-01-01 0:00 ` Cary Coutant 2019-01-01 0:00 ` Rui Ueyama via gnu-gabi
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).