This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
RE: Software Convention Proposal
- From: "Kirkegaard, Knud J" <knud dot j dot kirkegaard at intel dot com>
- To: "'Richard Henderson'" <rth at redhat dot com>, "'gcc at gcc dot gnu dot org'" <gcc at gcc dot gnu dot org>
- Cc: "Kirkegaard, Knud J" <knud dot j dot kirkegaard at intel dot com>, "Sehr, David C" <david dot c dot sehr at intel dot com>, "Saxena, Sunil" <sunil dot saxena at intel dot com>, "'cary at cup dot hp dot com'" <cary at cup dot hp dot com>, "Winalski, Paul" <paul dot winalski at intel dot com>
- Date: Fri, 23 Aug 2002 14:47:04 -0700
- Subject: RE: Software Convention Proposal
I would like to change the command line options after seeing Richard's
response.
The original proposed command-line option with an optional argument does not
have a clean semantic and is difficult to parse.
Therefore using Richard's suggestion:
-fvisibility=<visibility>
where visibility is one of: default, protected, hidden, or internal.
This option will, by default, cause all global symbols to get the ELF
visibility
specified by the option.
-fvisibility-default=<file>
-fvisibility-protected=<file>
-fvisibility-hidden=<file>
-fvisibility-internal=<file>
The options listed will all take a file as an argument. Space separated
symbols listed in
the file will get the visibility specified by the options. The precedence
order of
the visibility attributes remains as described in the original proposal.
With respect to -fminshared I still feel it makes sense to have it imply
-fvisibility=protected since it allows the compiler to generate absolute
addressing for
any symbols not explicitly marked default (either through using the
attribute syntax or
the -fvisibility-default=<file>). That in turn means symbol preemption is
not possible
and therefore it should imply that the default visibility is protected. It
is not
exactly the same as -fno-pic since the default is still PIC, just that most
of the
symbols can be addressed absolute since we guarantee it will be linked into
the main
executable image. If due diligence is not applied the worst case should be a
link time
error when a symbol marked protected turns out to be resolved from a shared
library.
Regarding architectures that will benefit from this besides IPF and the ones
listed in other responses, we can add that PA-RISC already benefits from
this. Otherwise any architecture using ELF and having PIC and symbol
preemption as the default behavior should benefit.
- Knud