This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Software Convention Proposal

Proposal for Linux Software Convention Options. 
Knud J Kirkegaard, Intel Corporation
David C Sehr, Intel Corporation


This is a proposal to take advantage of the performance opportunities
available to several applications that don't require position independent
code and the default symbol preemption model described in the ELF ABI.

The intent is to maintain binary compatibility by using existing ELF gABI
symbol visibility attributes as well as options to the compiler that can
change the default software convention used. The linker will report errors
if an attempt is made to link objects that have incompatible visibility
attributes on symbols.

ELF Symbol Visibility Attribute 

Currently gcc supports a function and variable attribute corresponding to
the ELF symbol visibility attributes protected, hidden, and internal. These
turn correspond to the ELB ABI symbol visibility attributes STV_PROTECTED,
STV_HIDDEN, and STV_INTERNAL (see Appendix).

We propose to add the visibility attribute "default" corresponding to
STV_DEFAULT.  The idea is that through compiler command line options it
will be possible to change the default symbol visibility and then set the
"default" attribute on functions and variables that require the
"default" setting. 


   int i __attribute__ ((visibility ("default")));
   void __attribute__ ((visibility ("default"))) foo () {  }

In addition to providing a source syntax to set the complete range of ELF
visibility attributes it is proposed to add compiler options to provide
command line control of the visibility attributes. The will enable immediate
access to the feature and not depend on header file modifications.

-fdefault   [<filename>]
-fprotected [<filename>]
-fhidden    [<filename>]
-finternal  [<filename>]

 The options will cause all global symbols to get the visibility specified
 by the option. If no file is specified as argument to the option all
 will get the specified attribute. If a file argument is specified, then
 space separated symbols listed in the file will get the visibility

 Explicitly setting the visibility to "default", either using the attribute
 syntax or the command line option, to "default" will override any setting
 to "protected", "hidden", or "internal"

 Explicitly setting the visibility to "protected" will override any setting
 to "hidden", or "internal"

 Explicitly setting the visibility to "hidden" will override any setting
 to "internal"

 Since "internal" is a processor-specific attribute is may not be desirable
 to have a general option for it. This proposal does not depend on support
 for -finternal. It is included for completeness.


 -fprotected -fdefault <file> 

 All symbols will be protected except symbols listed in the file argument
 to the fdefault option or symbols having the "default" visibility attribute
 set in the source.

Compiling for "main program" option


 This option indicates to the compiler that the module is being compiled
 for the main program. This allows for absolute addressing of symbols that
 are protected or hidden. The option implies -fprotected. Use of this option
 will allow the compiler to generate non-position independent code and 
 therefore use absolute addressing.

libc Header File Changes

To increase the acceptance of the options to change software conventions
it is proposed that the glibc headers are modified to include the "default"
attribute on every extern symbol declaration. Applications that rely only
on using glibc as a shared library will not need to specify any symbol lists
to -fdefault to get the performance benefits.

It is recommended that other shared libraries also add the "default"
to the header files. Third party library providers would be encouraged to
add the "default" attribute as well.

It is proposed that the setting of the "default" attribute for exported 
data and functions can be overridden through the definition of a macro or
similar control.  Since the default behavior is dynamic linking an extra
macro definition or similar control is only needed to override the
"default" attribute, if an application wants to take full advantage of the
performance opportunities of statically linking in glibc.


The printf prototype will be:

  extern int __VISIBILITY printf (__const char *__restrict __format, ...)

By default the prototype for printf when including stdio.h will be expanded

  extern int __attribute__ ((visibility ("default"))) printf (__const char
*__restrict __format, ...) __THROW;

When static behavior is desired the prototype will be expanded to:

  extern int printf (__const char *__restrict __format, ...) __THROW;


>From the GCC documentation on current development:

Not all target machines support this attribute.

visibility ("visibility_type") 
The visibility attribute on ELF targets causes the declaration to be emitted
with hidden, protected or internal visibility. 

void __attribute__ ((visibility ("protected")))
f () { /* Do something. */; }
int i __attribute__ ((visibility ("hidden")));

See the ELF gABI for complete details, but the short story is 

Hidden visibility indicates that the symbol will not be placed into the
dynamic symbol table, so no other module (executable or shared library) can
reference it directly. 

Protected visibility indicates that the symbol will be placed in the dynamic
symbol table, but that references within the defining module will bind to
the local symbol. That is, the symbol cannot be overridden by another

Internal visibility is like hidden visibility, but with additional processor
specific semantics. Unless otherwise specified by the psABI, gcc defines
internal visibility to mean that the function is never called from another
module. Note that hidden symbols, while then cannot be referenced directly
by other modules, can be referenced indirectly via function pointers. By
indicating that a symbol cannot be called from outside the module, gcc may
for instance omit the load of a PIC register since it is known that the
calling function loaded the correct value. 
Not all ELF targets support this attribute. 

Knud Joergen Bjerre Kirkegaard	phone	(408) 765 5069
Intel Corporation			fax:	(408) 765 5165
3600 Juliette Lane		email:
Santa Clara, CA 95052-8119	mailstop: SC12-301

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]