[RFC] Symbol meta-information ELF extension

Message ID 20200218102515.54ab5fff@jozef-kubuntu
State New
Headers show
Series
  • [RFC] Symbol meta-information ELF extension
Related show

Commit Message

Jozef Lawrynowicz Feb. 18, 2020, 10:25 a.m.
Hi,

I've been working with Texas Instruments to develop an ELF extension which
allows additional information about symbols ("symbol meta-information") to
be stored in ELF files, in a section called .symtab_meta.

The aim of symbol meta-information is to provide a extensible format for
propagating additional information about symbols from the source code through to
the link stage.

I hope I can get some feedback on this proposal, and its current implementation,
from the upstream community so I can make any adjustments required for the
eventual upstreaming of this feature.

TI spec'd out this functionality and are implementing it into their soon-to-be
released ARM Clang/LLVM toolchain fork. They will also be looking to upstream
it to Clang/LLVM, so it is not GNU-specific.

So far, the behaviour of two new C/C++ attributes, "retain" and "location", and
their mapping to symbol meta-information have been spec'd out:
* "retain" - a symbol meta-information entry for the symbol informs the linker
  not to garbage collect the section containing the symbol, even if it appears
  unused.
* "location" - a symbol meta-information entry describes the VMA the
  linker should try to place the corresponding symbol at (similar to the "at"
  attribute in the ARM compiler).

So far these attributes making use of symbol meta-information are mainly
targeted at embedded software developers, where the ability to save objects from
garbage collection or place objects at specific addresses can sometimes be
necessary. Being able to describe this behaviour in the source code without
having to modify linker scripts arguably improves the developer experience.

In the patches attached to this RFC, the general mechanism for the symbol
meta-information functionality has been implemented in the BFD library and
plumbed into much of Binutils:
* GAS supports the ".sym_meta_info" directive which describes a symbol
  meta-information entry. It consolidates symbol meta-information entries into a
  table which is placed in the .symtab_meta section of the output object file.
* LD supports the consolidation of symbol meta-information from input object
  files into a single table, and will save symbols with an accompanying
  SMK_RETAIN meta-information entry from garbage collection.
* objdump supports dumping the symbol meta-information table with the
  --symtab-meta option.
* objcopy maintains the integrity of symbol meta-information as the input BFD is
  modified.

The high-level list of functionality that is not currently implemented in this
RFC, but I intend to add before submitting the patches for inclusion into
Binutils is:
* Support the placement of symbols at a VMA specified with an SMK_LOCATION
  meta-information entry in LD.
* Dump the symbol meta-information table in readelf.
* Support output formats other than ELF when linking ELF input object files with
  symbol meta-information.
* Clarify expected behaviour of objcopy/strip with "retained" symbols. Might
  need a new option to enable/disable the removal of these symbols.

I've added documentation to the individual tools as appropriate, a generic
description of the format of .symtab_meta and the entries within it is in
the ELF backends section of the BFD manual.

I've benchmarked the performance of LD when linking the Linux kernel
with/without symbol meta-information. There are ~120k symbols in the linked
Linux kernel, and after adding 120k new, randomly named symbols with
meta-information, there is no observable change in the time it takes to link
between these new symbols having meta-information or not.
I tested this in 3 combinations:
- 60k local symbols, 60k global symbols
- 120k local symbols
- 120k global symbols

I have some specific questions which I hope someone can provide some suggestions
for:
* Does this functionality need to be gated with a configure flag?
  I guess that partly depends on if a maintainer decides it should be on or off
  by default.
* I've positioned the .symtab_meta section to be emitted immediately after
  .symtab. I couldn't find anything in the ELF spec that enforces the positions
  of .symtab relative to .shstrtab and .strtab, but I recognize that these
  sections' relative positions have been the same for a long time. Are there any
  possible issues relating to this?

Also, any general feedback on the proposal and/or implementation is welcome.

I've additionally attached a rough GCC patch which emits .sym_meta_info
directives when __attribute__((retain)) is used on declarations of functions or
data.

I've built the attached patches with --enable-targets=all and confirmed there
are no issues there.
I've regtested and confirmed the new tests work for msp430-elf, arm-eabi,
x86-64-pc-linux-gnu, and also built and regtested the native configuration on a
i686-pc-linux-gnu host.
I additionally regtested for i386-pe, to check a non-ELF target.

Thanks,
Jozef

Comments

H.J. Lu Feb. 18, 2020, 12:58 p.m. | #1
On Tue, Feb 18, 2020 at 2:26 AM Jozef Lawrynowicz
<jozef.l@mittosystems.com> wrote:
>

> Hi,

>

> I've been working with Texas Instruments to develop an ELF extension which

> allows additional information about symbols ("symbol meta-information") to

> be stored in ELF files, in a section called .symtab_meta.

>

> The aim of symbol meta-information is to provide a extensible format for

> propagating additional information about symbols from the source code through to

> the link stage.

>

> I hope I can get some feedback on this proposal, and its current implementation,

> from the upstream community so I can make any adjustments required for the

> eventual upstreaming of this feature.


Have you looked at Solaris syminfo section

https://docs.oracle.com/cd/E26502_01/html/E26507/chapter7-17.html

Can you extend it to do what you want?

-- 
H.J.
Jozef Lawrynowicz Feb. 18, 2020, 1:47 p.m. | #2
On Tue, 18 Feb 2020 04:58:02 -0800
"H.J. Lu" <hjl.tools@gmail.com> wrote:

> On Tue, Feb 18, 2020 at 2:26 AM Jozef Lawrynowicz

> <jozef.l@mittosystems.com> wrote:

> >

> > Hi,

> >

> > I've been working with Texas Instruments to develop an ELF extension which

> > allows additional information about symbols ("symbol meta-information") to

> > be stored in ELF files, in a section called .symtab_meta.

> >

> > The aim of symbol meta-information is to provide a extensible format for

> > propagating additional information about symbols from the source code through to

> > the link stage.

> >

> > I hope I can get some feedback on this proposal, and its current implementation,

> > from the upstream community so I can make any adjustments required for the

> > eventual upstreaming of this feature.  

> 

> Have you looked at Solaris syminfo section

> 

> https://docs.oracle.com/cd/E26502_01/html/E26507/chapter7-17.html

> 

> Can you extend it to do what you want?

> 


It looks like there is only some minimal support for the Syminfo section in
Binutils. The support is only there so that readelf can dump information about
the Syminfo section from an object file.

There's no implementation to enable the creation of a Syminfo section with
user-specified flags for certain symbols, nor are there any hooks into any
other Binutils programs, so I can't see any advantage to try and leverage that
existing functionality. 

Thanks,
Jozef
H.J. Lu Feb. 18, 2020, 1:58 p.m. | #3
On Tue, Feb 18, 2020 at 5:47 AM Jozef Lawrynowicz
<jozef.l@mittosystems.com> wrote:
>

> On Tue, 18 Feb 2020 04:58:02 -0800

> "H.J. Lu" <hjl.tools@gmail.com> wrote:

>

> > On Tue, Feb 18, 2020 at 2:26 AM Jozef Lawrynowicz

> > <jozef.l@mittosystems.com> wrote:

> > >

> > > Hi,

> > >

> > > I've been working with Texas Instruments to develop an ELF extension which

> > > allows additional information about symbols ("symbol meta-information") to

> > > be stored in ELF files, in a section called .symtab_meta.

> > >

> > > The aim of symbol meta-information is to provide a extensible format for

> > > propagating additional information about symbols from the source code through to

> > > the link stage.

> > >

> > > I hope I can get some feedback on this proposal, and its current implementation,

> > > from the upstream community so I can make any adjustments required for the

> > > eventual upstreaming of this feature.

> >

> > Have you looked at Solaris syminfo section

> >

> > https://docs.oracle.com/cd/E26502_01/html/E26507/chapter7-17.html

> >

> > Can you extend it to do what you want?

> >

>

> It looks like there is only some minimal support for the Syminfo section in

> Binutils. The support is only there so that readelf can dump information about

> the Syminfo section from an object file.

>

> There's no implementation to enable the creation of a Syminfo section with

> user-specified flags for certain symbols, nor are there any hooks into any

> other Binutils programs, so I can't see any advantage to try and leverage that

> existing functionality.


syminfo is a very useful ELF extension.  My question is if binutils supports
syminfo, can it be extended to meet your need?


-- 
H.J.
Jozef Lawrynowicz Feb. 18, 2020, 2:38 p.m. | #4
On Tue, 18 Feb 2020 05:58:34 -0800
"H.J. Lu" <hjl.tools@gmail.com> wrote:

> On Tue, Feb 18, 2020 at 5:47 AM Jozef Lawrynowicz

> <jozef.l@mittosystems.com> wrote:

> >

> > On Tue, 18 Feb 2020 04:58:02 -0800

> > "H.J. Lu" <hjl.tools@gmail.com> wrote:

> >  

> > > On Tue, Feb 18, 2020 at 2:26 AM Jozef Lawrynowicz

> > > <jozef.l@mittosystems.com> wrote:  

> > > >

> > > > Hi,

> > > >

> > > > I've been working with Texas Instruments to develop an ELF extension which

> > > > allows additional information about symbols ("symbol meta-information") to

> > > > be stored in ELF files, in a section called .symtab_meta.

> > > >

> > > > The aim of symbol meta-information is to provide a extensible format for

> > > > propagating additional information about symbols from the source code through to

> > > > the link stage.

> > > >

> > > > I hope I can get some feedback on this proposal, and its current implementation,

> > > > from the upstream community so I can make any adjustments required for the

> > > > eventual upstreaming of this feature.  

> > >

> > > Have you looked at Solaris syminfo section

> > >

> > > https://docs.oracle.com/cd/E26502_01/html/E26507/chapter7-17.html

> > >

> > > Can you extend it to do what you want?

> > >  

> >

> > It looks like there is only some minimal support for the Syminfo section in

> > Binutils. The support is only there so that readelf can dump information about

> > the Syminfo section from an object file.

> >

> > There's no implementation to enable the creation of a Syminfo section with

> > user-specified flags for certain symbols, nor are there any hooks into any

> > other Binutils programs, so I can't see any advantage to try and leverage that

> > existing functionality.  

> 

> syminfo is a very useful ELF extension.  My question is if binutils supports

> syminfo, can it be extended to meet your need?

> 

> 


Well, a syminfo entry has a field to store flags which describes the extra
information about the symbol, similar to the "kind" field of a symbol
meta-information entry.

typedef struct {
        Elf64_Half      si_boundto;
        Elf64_Half      si_flags;
} Elf64_Syminfo;

Meanwhile, syminfo augments the si_flags value by using si_boundto to point
to an index in the .dynamic section. This is similar to how the "value" field of
a symbol meta-information entry augments its "kind" field, but this
functionality must work in static executables which do not have a .dynamic
section.

So one way to extend syminfo to meet the general need of this proposed symbol
meta-information functionality then we would need a new field to store the
value associated with the "si_flags".

typedef struct {
        Elf64_Half      si_boundto;
        Elf64_Half      si_flags;
	Elf64_Addr	si_value;
} Elf64_Syminfo_new;

But there are more caveats given that I've worked from a spec which has been
followed for an implementation in Clang/LLVM, so if in Binutils we base the
symbol meta-information functionality off Solaris syminfo we lose compatibility
with this other tool.

Even though adding the above si_value field would meet the *general* need of
the new implementation, the implementation details between the syminfo and
symbol meta-information are very different.

I do understand the desire not to fragment Binutils with multiple
implementations of similar functionality.

If this will be a sticking point for upstreaming then I will need to consider
some other options. A key aim of the upstreaming effort of this functioniality
is that the GNU and Clang/LLVM implementations are compatible.

Thanks,
Jozef
H.J. Lu Feb. 18, 2020, 2:50 p.m. | #5
On Tue, Feb 18, 2020 at 6:38 AM Jozef Lawrynowicz
<jozef.l@mittosystems.com> wrote:
>

> On Tue, 18 Feb 2020 05:58:34 -0800

> "H.J. Lu" <hjl.tools@gmail.com> wrote:

>

> > On Tue, Feb 18, 2020 at 5:47 AM Jozef Lawrynowicz

> > <jozef.l@mittosystems.com> wrote:

> > >

> > > On Tue, 18 Feb 2020 04:58:02 -0800

> > > "H.J. Lu" <hjl.tools@gmail.com> wrote:

> > >

> > > > On Tue, Feb 18, 2020 at 2:26 AM Jozef Lawrynowicz

> > > > <jozef.l@mittosystems.com> wrote:

> > > > >

> > > > > Hi,

> > > > >

> > > > > I've been working with Texas Instruments to develop an ELF extension which

> > > > > allows additional information about symbols ("symbol meta-information") to

> > > > > be stored in ELF files, in a section called .symtab_meta.

> > > > >

> > > > > The aim of symbol meta-information is to provide a extensible format for

> > > > > propagating additional information about symbols from the source code through to

> > > > > the link stage.

> > > > >

> > > > > I hope I can get some feedback on this proposal, and its current implementation,

> > > > > from the upstream community so I can make any adjustments required for the

> > > > > eventual upstreaming of this feature.

> > > >

> > > > Have you looked at Solaris syminfo section

> > > >

> > > > https://docs.oracle.com/cd/E26502_01/html/E26507/chapter7-17.html

> > > >

> > > > Can you extend it to do what you want?

> > > >

> > >

> > > It looks like there is only some minimal support for the Syminfo section in

> > > Binutils. The support is only there so that readelf can dump information about

> > > the Syminfo section from an object file.

> > >

> > > There's no implementation to enable the creation of a Syminfo section with

> > > user-specified flags for certain symbols, nor are there any hooks into any

> > > other Binutils programs, so I can't see any advantage to try and leverage that

> > > existing functionality.

> >

> > syminfo is a very useful ELF extension.  My question is if binutils supports

> > syminfo, can it be extended to meet your need?

> >

> >

>

> Well, a syminfo entry has a field to store flags which describes the extra

> information about the symbol, similar to the "kind" field of a symbol

> meta-information entry.

>

> typedef struct {

>         Elf64_Half      si_boundto;

>         Elf64_Half      si_flags;

> } Elf64_Syminfo;

>

> Meanwhile, syminfo augments the si_flags value by using si_boundto to point

> to an index in the .dynamic section. This is similar to how the "value" field of

> a symbol meta-information entry augments its "kind" field, but this

> functionality must work in static executables which do not have a .dynamic

> section.

>

> So one way to extend syminfo to meet the general need of this proposed symbol

> meta-information functionality then we would need a new field to store the

> value associated with the "si_flags".

>

> typedef struct {

>         Elf64_Half      si_boundto;

>         Elf64_Half      si_flags;

>         Elf64_Addr      si_value;

> } Elf64_Syminfo_new;


You should start a discussion to extend ELF symbol info at

https://groups.google.com/forum/#!forum/generic-abi

> But there are more caveats given that I've worked from a spec which has been

> followed for an implementation in Clang/LLVM, so if in Binutils we base the

> symbol meta-information functionality off Solaris syminfo we lose compatibility

> with this other tool.

>

> Even though adding the above si_value field would meet the *general* need of

> the new implementation, the implementation details between the syminfo and

> symbol meta-information are very different.

>

> I do understand the desire not to fragment Binutils with multiple

> implementations of similar functionality.

>

> If this will be a sticking point for upstreaming then I will need to consider

> some other options. A key aim of the upstreaming effort of this functioniality

> is that the GNU and Clang/LLVM implementations are compatible.

>

> Thanks,

> Jozef




-- 
H.J.
Jozef Lawrynowicz Feb. 18, 2020, 6:54 p.m. | #6
On Tue, 18 Feb 2020 06:50:58 -0800
"H.J. Lu" <hjl.tools@gmail.com> wrote:

> On Tue, Feb 18, 2020 at 6:38 AM Jozef Lawrynowicz

> <jozef.l@mittosystems.com> wrote:

> >

> > On Tue, 18 Feb 2020 05:58:34 -0800

> > "H.J. Lu" <hjl.tools@gmail.com> wrote:

> >  

> > > On Tue, Feb 18, 2020 at 5:47 AM Jozef Lawrynowicz

> > > <jozef.l@mittosystems.com> wrote:  

> > > >

> > > > On Tue, 18 Feb 2020 04:58:02 -0800

> > > > "H.J. Lu" <hjl.tools@gmail.com> wrote:

> > > >  

> > > > > On Tue, Feb 18, 2020 at 2:26 AM Jozef Lawrynowicz

> > > > > <jozef.l@mittosystems.com> wrote:  

> > > > > >

> > > > > > Hi,

> > > > > >

> > > > > > I've been working with Texas Instruments to develop an ELF extension which

> > > > > > allows additional information about symbols ("symbol meta-information") to

> > > > > > be stored in ELF files, in a section called .symtab_meta.

> > > > > >

> > > > > > The aim of symbol meta-information is to provide a extensible format for

> > > > > > propagating additional information about symbols from the source code through to

> > > > > > the link stage.

> > > > > >

> > > > > > I hope I can get some feedback on this proposal, and its current implementation,

> > > > > > from the upstream community so I can make any adjustments required for the

> > > > > > eventual upstreaming of this feature.  

> > > > >

> > > > > Have you looked at Solaris syminfo section

> > > > >

> > > > > https://docs.oracle.com/cd/E26502_01/html/E26507/chapter7-17.html

> > > > >

> > > > > Can you extend it to do what you want?

> > > > >  

> > > >

> > > > It looks like there is only some minimal support for the Syminfo section in

> > > > Binutils. The support is only there so that readelf can dump information about

> > > > the Syminfo section from an object file.

> > > >

> > > > There's no implementation to enable the creation of a Syminfo section with

> > > > user-specified flags for certain symbols, nor are there any hooks into any

> > > > other Binutils programs, so I can't see any advantage to try and leverage that

> > > > existing functionality.  

> > >

> > > syminfo is a very useful ELF extension.  My question is if binutils supports

> > > syminfo, can it be extended to meet your need?

> > >

> > >  

> >

> > Well, a syminfo entry has a field to store flags which describes the extra

> > information about the symbol, similar to the "kind" field of a symbol

> > meta-information entry.

> >

> > typedef struct {

> >         Elf64_Half      si_boundto;

> >         Elf64_Half      si_flags;

> > } Elf64_Syminfo;

> >

> > Meanwhile, syminfo augments the si_flags value by using si_boundto to point

> > to an index in the .dynamic section. This is similar to how the "value" field of

> > a symbol meta-information entry augments its "kind" field, but this

> > functionality must work in static executables which do not have a .dynamic

> > section.

> >

> > So one way to extend syminfo to meet the general need of this proposed symbol

> > meta-information functionality then we would need a new field to store the

> > value associated with the "si_flags".

> >

> > typedef struct {

> >         Elf64_Half      si_boundto;

> >         Elf64_Half      si_flags;

> >         Elf64_Addr      si_value;

> > } Elf64_Syminfo_new;  

> 

> You should start a discussion to extend ELF symbol info at

> 

> https://groups.google.com/forum/#!forum/generic-abi


Thanks for the suggestion. I'll work with TI to get something posted there soon.

Can you clarify whether you still think this would work best as an extension to
Solaris Syminfo?

To be honest I have a problem with that given that Syminfo is a target specific
extension to ELF (which just happens to be implemented in a generic way in
Readelf), and we want to add symbol meta-information as a generic extension
to ELF.

There's no advantage to building upon Syminfo in Binutils given the
implementation is limited to readelf dumping the Syminfo table.

If Syminfo was already part of the gABI I would be on board with working from
that to add the new functionality.

I guess the other option is to take Syminfo, extend it with the new
functionality we want, then propose it as generic ELF extension. I wonder if
there would be legal issues doing all that without any input from Oracle.

Do they "own" the spec? Would I be able to propose their spec with some
extensions to ELF gABI? (These are somewhat rhetorical questions...)

Regards,
Jozef
> 

> > But there are more caveats given that I've worked from a spec which has been

> > followed for an implementation in Clang/LLVM, so if in Binutils we base the

> > symbol meta-information functionality off Solaris syminfo we lose compatibility

> > with this other tool.

> >

> > Even though adding the above si_value field would meet the *general* need of

> > the new implementation, the implementation details between the syminfo and

> > symbol meta-information are very different.

> >

> > I do understand the desire not to fragment Binutils with multiple

> > implementations of similar functionality.

> >

> > If this will be a sticking point for upstreaming then I will need to consider

> > some other options. A key aim of the upstreaming effort of this functioniality

> > is that the GNU and Clang/LLVM implementations are compatible.

> >

> > Thanks,

> > Jozef  

> 

> 

>
H.J. Lu Feb. 18, 2020, 9:43 p.m. | #7
On Tue, Feb 18, 2020 at 10:54 AM Jozef Lawrynowicz
<jozef.l@mittosystems.com> wrote:
>

> On Tue, 18 Feb 2020 06:50:58 -0800

> "H.J. Lu" <hjl.tools@gmail.com> wrote:

>

> > On Tue, Feb 18, 2020 at 6:38 AM Jozef Lawrynowicz

> > <jozef.l@mittosystems.com> wrote:

> > >

> > > On Tue, 18 Feb 2020 05:58:34 -0800

> > > "H.J. Lu" <hjl.tools@gmail.com> wrote:

> > >

> > > > On Tue, Feb 18, 2020 at 5:47 AM Jozef Lawrynowicz

> > > > <jozef.l@mittosystems.com> wrote:

> > > > >

> > > > > On Tue, 18 Feb 2020 04:58:02 -0800

> > > > > "H.J. Lu" <hjl.tools@gmail.com> wrote:

> > > > >

> > > > > > On Tue, Feb 18, 2020 at 2:26 AM Jozef Lawrynowicz

> > > > > > <jozef.l@mittosystems.com> wrote:

> > > > > > >

> > > > > > > Hi,

> > > > > > >

> > > > > > > I've been working with Texas Instruments to develop an ELF extension which

> > > > > > > allows additional information about symbols ("symbol meta-information") to

> > > > > > > be stored in ELF files, in a section called .symtab_meta.

> > > > > > >

> > > > > > > The aim of symbol meta-information is to provide a extensible format for

> > > > > > > propagating additional information about symbols from the source code through to

> > > > > > > the link stage.

> > > > > > >

> > > > > > > I hope I can get some feedback on this proposal, and its current implementation,

> > > > > > > from the upstream community so I can make any adjustments required for the

> > > > > > > eventual upstreaming of this feature.

> > > > > >

> > > > > > Have you looked at Solaris syminfo section

> > > > > >

> > > > > > https://docs.oracle.com/cd/E26502_01/html/E26507/chapter7-17.html

> > > > > >

> > > > > > Can you extend it to do what you want?

> > > > > >

> > > > >

> > > > > It looks like there is only some minimal support for the Syminfo section in

> > > > > Binutils. The support is only there so that readelf can dump information about

> > > > > the Syminfo section from an object file.

> > > > >

> > > > > There's no implementation to enable the creation of a Syminfo section with

> > > > > user-specified flags for certain symbols, nor are there any hooks into any

> > > > > other Binutils programs, so I can't see any advantage to try and leverage that

> > > > > existing functionality.

> > > >

> > > > syminfo is a very useful ELF extension.  My question is if binutils supports

> > > > syminfo, can it be extended to meet your need?

> > > >

> > > >

> > >

> > > Well, a syminfo entry has a field to store flags which describes the extra

> > > information about the symbol, similar to the "kind" field of a symbol

> > > meta-information entry.

> > >

> > > typedef struct {

> > >         Elf64_Half      si_boundto;

> > >         Elf64_Half      si_flags;

> > > } Elf64_Syminfo;

> > >

> > > Meanwhile, syminfo augments the si_flags value by using si_boundto to point

> > > to an index in the .dynamic section. This is similar to how the "value" field of

> > > a symbol meta-information entry augments its "kind" field, but this

> > > functionality must work in static executables which do not have a .dynamic

> > > section.

> > >

> > > So one way to extend syminfo to meet the general need of this proposed symbol

> > > meta-information functionality then we would need a new field to store the

> > > value associated with the "si_flags".

> > >

> > > typedef struct {

> > >         Elf64_Half      si_boundto;

> > >         Elf64_Half      si_flags;

> > >         Elf64_Addr      si_value;

> > > } Elf64_Syminfo_new;

> >

> > You should start a discussion to extend ELF symbol info at

> >

> > https://groups.google.com/forum/#!forum/generic-abi

>

> Thanks for the suggestion. I'll work with TI to get something posted there soon.

>

> Can you clarify whether you still think this would work best as an extension to

> Solaris Syminfo?

>

> To be honest I have a problem with that given that Syminfo is a target specific

> extension to ELF (which just happens to be implemented in a generic way in

> Readelf), and we want to add symbol meta-information as a generic extension

> to ELF.

>

> There's no advantage to building upon Syminfo in Binutils given the

> implementation is limited to readelf dumping the Syminfo table.

>

> If Syminfo was already part of the gABI I would be on board with working from

> that to add the new functionality.

>

> I guess the other option is to take Syminfo, extend it with the new

> functionality we want, then propose it as generic ELF extension. I wonder if

> there would be legal issues doing all that without any input from Oracle.

>

> Do they "own" the spec? Would I be able to propose their spec with some

> extensions to ELF gABI? (These are somewhat rhetorical questions...)


https://groups.google.com/forum/#!forum/generic-abi

is the place to discuss ELF gABI.


-- 
H.J.

Patch

From d2c9df194c7e7bcb37bd54cd39cef7b7b8a74ec5 Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz <jozef.l@mittosystems.com>
Date: Tue, 18 Feb 2020 10:21:04 +0000
Subject: [PATCH] META: Add retain attribute and emit .sym_meta_info

---
 gcc/c-family/c-attribs.c   | 14 ++++++++++++++
 gcc/config/elfos.h         |  9 +++++++++
 gcc/config/msp430/msp430.c |  3 +++
 3 files changed, 26 insertions(+)

diff --git a/gcc/c-family/c-attribs.c b/gcc/c-family/c-attribs.c
index 2ea5fd5ff46..a758e8ee2a0 100644
--- a/gcc/c-family/c-attribs.c
+++ b/gcc/c-family/c-attribs.c
@@ -94,6 +94,7 @@  static tree handle_aligned_attribute (tree *, tree, tree, int, bool *);
 static tree handle_warn_if_not_aligned_attribute (tree *, tree, tree,
 						  int, bool *);
 static tree handle_noinit_attribute (tree *, tree, tree, int, bool *);
+static tree handle_retain_attribute (tree *, tree, tree, int, bool *);
 static tree handle_weak_attribute (tree *, tree, tree, int, bool *) ;
 static tree handle_noplt_attribute (tree *, tree, tree, int, bool *) ;
 static tree handle_alias_ifunc_attribute (bool, tree *, tree, tree, bool *);
@@ -484,6 +485,8 @@  const struct attribute_spec c_common_attribute_table[] =
 			      handle_noinit_attribute, attr_noinit_exclusions },
   { "access",		      1, 3, false, true, true, false,
 			      handle_access_attribute, NULL },
+  { "retain",		      0, 0, true, false, false, false,
+			      handle_retain_attribute, NULL },
   { NULL,                     0, 0, false, false, false, false, NULL, NULL }
 };
 
@@ -2258,6 +2261,17 @@  handle_noinit_attribute (tree * node,
   return res;
 }
 
+static tree
+handle_retain_attribute (tree * node,
+			 tree   name,
+			 tree   args,
+			 int    flags,
+			 bool *no_add_attrs)
+{
+  /* The "retain" attribute implies "used".  */
+  return handle_used_attribute (node, name, args, flags, no_add_attrs);
+}
+
 
 /* Handle a "noplt" attribute; arguments as in
    struct attribute_spec.handler.  */
diff --git a/gcc/config/elfos.h b/gcc/config/elfos.h
index 74a3eafda6b..59f89203de2 100644
--- a/gcc/config/elfos.h
+++ b/gcc/config/elfos.h
@@ -289,6 +289,9 @@  see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
   do								\
     {								\
       ASM_OUTPUT_TYPE_DIRECTIVE (FILE, NAME, "function");	\
+      /* Change to ASM_OUTPUT_SYM_META_INFO */ \
+      if (lookup_attribute ("retain", DECL_ATTRIBUTES (DECL)) != NULL_TREE) \
+	  fprintf (FILE, "\t.sym_meta_info\t%s, SMK_RETAIN, 1\n", NAME); \
       ASM_DECLARE_RESULT (FILE, DECL_RESULT (DECL));		\
       ASM_OUTPUT_FUNCTION_LABEL (FILE, NAME, DECL);		\
     }								\
@@ -305,6 +308,9 @@  see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
   do								\
     {								\
       ASM_OUTPUT_TYPE_DIRECTIVE (FILE, NAME, "function");	\
+      /* Change to ASM_OUTPUT_SYM_META_INFO */ \
+      if (lookup_attribute ("retain", DECL_ATTRIBUTES (DECL)) != NULL_TREE) \
+	  fprintf (FILE, "\t.sym_meta_info\t%s, SMK_RETAIN, 1\n", NAME); \
       ASM_DECLARE_RESULT (FILE, DECL_RESULT (DECL));		\
       ASM_OUTPUT_FUNCTION_LABEL (FILE, NAME, DECL);		\
     }								\
@@ -334,6 +340,9 @@  see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
 	ASM_OUTPUT_TYPE_DIRECTIVE (FILE, NAME, "gnu_unique_object");	\
       else								\
 	ASM_OUTPUT_TYPE_DIRECTIVE (FILE, NAME, "object");		\
+      /* Change to ASM_OUTPUT_SYM_META_INFO */ \
+      if (lookup_attribute ("retain", DECL_ATTRIBUTES (DECL)) != NULL_TREE) \
+	  fprintf (FILE, "\t.sym_meta_info\t%s, SMK_RETAIN, 1\n", NAME); \
 									\
       size_directive_output = 0;					\
       if (!flag_inhibit_size_directive					\
diff --git a/gcc/config/msp430/msp430.c b/gcc/config/msp430/msp430.c
index 25d191694ef..93875a27e35 100644
--- a/gcc/config/msp430/msp430.c
+++ b/gcc/config/msp430/msp430.c
@@ -1767,6 +1767,9 @@  msp430_start_function (FILE *file, const char *name, tree decl)
 
   switch_to_section (function_section (decl));
   ASM_OUTPUT_TYPE_DIRECTIVE (file, name, "function");
+  /* Change to ASM_OUTPUT_SYM_META_INFO */
+  if (lookup_attribute ("retain", DECL_ATTRIBUTES (decl)) != NULL_TREE)
+    fprintf (file, "\t.sym_meta_info\t%s, SMK_RETAIN, 1\n", name);
   ASM_OUTPUT_FUNCTION_LABEL (file, name, decl);
 }
 
-- 
2.17.1