public inbox for gnu-gabi@sourceware.org
 help / color / mirror / Atom feed
* Re: RFC Adding a section group flag of 0
  2019-01-01  0:00   ` RFC Adding a section group flag of 0 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       ` 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

* 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
       [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
       [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

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] <24c0c8d8-44e6-ab81-bdfb-43af8b53323b@redhat.com>
     [not found] ` <mvm5zuxg8wt.fsf@suse.de>
2019-01-01  0:00   ` RFC Adding a section group flag of 0 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
     [not found] <000000000000e0ce64057f1c76ed@google.com>
2019-01-01  0:00 ` Nick Clifton

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).