search for: stv_protect

...I propose >>>> that we: >>>> - remove/deprecate protected visibility, making visibility purely a hidden >>>> vs. non-hidden flag >>> >>> This would prevent us from propagating >>> __attribute__((visibility("protected")) to a STV_PROTECTED in the .o, >>> so I don't think we should do it. >> >> The whole point of this proposal is to get us to a state where we can use >> STV_PROTECTED for ordinary external or weak_for_linker symbols. > > And you can't also just produce STV_PROTECTED for ever...

...sentation, though. Absent the will to do that, I propose >> that we: >> - remove/deprecate protected visibility, making visibility purely a hidden >> vs. non-hidden flag > > This would prevent us from propagating > __attribute__((visibility("protected")) to a STV_PROTECTED in the .o, > so I don't think we should do it. The whole point of this proposal is to get us to a state where we can use STV_PROTECTED for ordinary external or weak_for_linker symbols. __attribute__((visibility(“protected”))) on a strong definition would just map to ordinary non-hidden e...

> On Mar 11, 2016, at 1:40 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: >>> And you can't also just produce STV_PROTECTED for every symbol. I >>> would love for that to be the case, but while most ELF systems support >>> copy relocations and related PLT hacks for functions it is not >>> practical to do it. >> >> I’m sorry, I'm not familiar with the technical problems here....

...y_anno = . ); *(set_orphan_dummy_anno) PROVIDE (__stop_set_orphan_dummy_anno = . );} >} >============ howto ============= : >LDFLAGS="-Bshareable -T ./linker_script" >clang -fPIC -c test.c >ld.lld $LDFLAGS test.o -o test.so >objdump -tT test.so Making __start_* __stop_* STV_PROTECTED is a deliberate choice. See https://reviews.llvm.org/D44566 Such symbols can still be exported to .dynsym (can be looked up from another shared object with dlopen) but prevent accidental symbol preemption.. > >On 6/2/20, 12:00 AM, "llvm-dev on behalf of Moshtaghi, Alireza via llvm-dev...

> On Mar 11, 2016, at 9:56 AM, Reid Kleckner <rnk at google.com> wrote: > > On Fri, Mar 11, 2016 at 9:41 AM, John McCall <rjmccall at apple.com <mailto:rjmccall at apple.com>> wrote: > Okay, so, it sounds to me like LLVM basically treats strong definitions as protected, then. Should we just formalize that? > > I guess the proposal here would be: > 1.

You are right it creates them but sets the protected flag (STV_PROTECTED) which seems to be the cause of my problem. How can I tell it to set the flag as STV_DEFAULT? Thanks A On 5/28/20, 11:30 PM, "Fangrui Song" <maskray at google.com> wrote: NetApp Security WARNING: This is an external email. Do not click links or open attachments unless you...

lld does not seem to create the __start and __end symbols for orphan sections. I would like to keep my linker script as generic as possible so how can I tell lld to create these symbols without having to add them in the linker script? Thanks A -------------- next part -------------- An HTML attachment was scrubbed... URL:

...#39;s responsibility. See George's reply about computeIsPreemptible. There are many ways to make a defined symbol in -shared mode non-preemptible: >>> >>> * visibility (usually via STV_HIDDEN; for a function, if you don't take the address in any -fno-pic translation unit, STV_PROTECTED can be used as well if you do want to export the function) >>> * -Bsymbolic, -Bsymbolic-functions >>> * --dynamic-list >>> * local: in --version-script >>> >>>> It seems the linker/lld should supply an equivalent of -mcmodel=kernel, e.g. indicating...

Hi, I'm in the process of migrating from clang5 to clang10. Unfortunately clang10 introduced a negative performance impact. The cause is an increase of PLT entries from this patch (first released in clang7): https://bugs.llvm.org/show_bug.cgi?id=36370 https://reviews.llvm.org/D43383 If I revert that clang patch locally, the additional PLT entries and the performance impact disappear. This