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]

Re: Preventing preemption of 'protected' symbols in GNU ld 2.26 [aka should we revert the fix for 65248]

H.J. Lu wrote:
On Tue, Apr 19, 2016 at 7:06 AM, Michael Matz <> wrote:

On Tue, 19 Apr 2016, Richard Biener wrote:

So with all this it sounds that current protected visibility is just
broken and we should forgo with it, making it equal to default
Like how?  You mean in GCC regarding protected as default visibility?  No,
that's just throwing out the baby with the water.  We should make
protected do what it was intended to do and accept that not all invariants
that are true for default visible symbols are also true for protected
symbols, possibly by ...

At least I couldn't decipher a solution that solves all of the issues
with protected visibility apart from trying to error at link-time (or
runtime?) for the cases that are tricky (impossible?) to solve.

Protected visibility is a useful feature.  But as it stands today,
it is pretty much useless on x86 as seen in ld and  We
have known this defect for a long time, almost from day 1.  To
make it truly useful, we need to clearly spell out how and when
it can be used.  We should enforce its limitation in compiler,
ld and so that there is no surprise, either for correctness or
performance,  at run-time.

my prefference would be if you (re)add it: do so such that there is no portability issue with next or previous gcc version (or other cc if possible), and that it be left as optional with a quick note that it is, and insure both on and off both build w/o fail in doing so. picky?

thank you, have a nice day!

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