[llvm-dev] [cfe-dev] __attribute__((retain)) && llvm.used/llvm.compiler.used

[via llvm-dev]

> (c) Change llvm.used to use SHF_GNU_RETAIN if integrated assembler or
> binutils>=2.36

I am curious how you intend to check if binutils>=2.36.  This is not
something you can decide when the compiler is built.
--paulr


> -----Original Message-----
> From: cfe-dev <cfe-dev-bounces at lists.llvm.org> On Behalf Of Fang-ruì Sòng
> via cfe-dev
> Sent: Wednesday, February 24, 2021 2:03 PM
> To: David Blaikie <dblaikie at gmail.com>
> Cc: LLVM Developers Mailing List <llvm-dev at lists.llvm.org>; cfe-dev <cfe-
> dev at lists.llvm.org>
> Subject: Re: [cfe-dev] __attribute__((retain)) &&
> llvm.used/llvm.compiler.used
> 
> On Wed, Feb 24, 2021 at 10:40 AM David Blaikie <dblaikie at gmail.com> wrote:
> >
> > (best to include folks from previous conversations in threads -
> sometimes we can't all keep up to date with all the threads happening - so
> I've added John McCall here, and echristo since he might have some
> thoughts on this too)
> >
> > I'd lean towards (1) too myself - give the LLVM constructs consistent
> semantics, and deal with the platform differences in the frontend during
> the mapping down to LLVM.
> 
> I chatted with Saleem Abdulrasool, who is in favor of (1), too.
> 
> I am going to send these patches:
> 
> (a) Add CodeGenModule::addUsedOrCompilerUsedGlobal (which uses
> llvm.compiler.used for ELF and llvm.used for the others). Migrate some
> addUsedGlobal call sites to use addUsedOrCompilerUsedGlobal.
> (b) Add __attribute__((retain))
> (c) Change llvm.used to use SHF_GNU_RETAIN if integrated assembler or
> binutils>=2.36
> 
> Currently llvm.used/llvm.compiler.used should have no difference on
> ELF, so (a) & (b) do not affect users who don't use 'retain'.
> 
> (c) will change the binary format representation of llvm.used, so
> there is some risk if the consumer is not prepared for multiple
> sections of the same name (which means they already break with
> -fno-unique-section-names, but the option is rare).
> On very large C/C++ projects, llvm.used has usually 0 or 1 element.
> ObjC can have multiple llvm.used but that should work. So if there is
> risk, the risk for other frontends.
> I don't see a way to avoid that, but they can switch to
> llvm.compiler.used.
> 
> Non-ELF users should not observe anything different.
> 
> > On Wed, Feb 24, 2021 at 1:09 AM Fāng-ruì Sòng via cfe-dev <cfe-
> dev at lists.llvm.org> wrote:
> >>
> >> On 2021-02-24, Fāng-ruì Sòng wrote:
> >> >Currently __attribute__((used)) lowers to llvm.used.
> >> >
> >> >* On Mach-O, a GlobalObject in llvm.used gets the S_ATTR_NO_DEAD_STRIP
> >> >attribute, which prevents linker GC (dead stripping).
> >> >* On COFF, a non-local-linkage GlobalObject[1] in llvm.used gets the
> >> >/INCLUDE: linker option (similar to ELF `ld -u`), which prevents
> >> >linker GC.
> >> >  It should be possible to work with local linkage GlobalObject's as
> >> >well but that will require a complex COMDAT dance.
> >> >* On ELF, a global object llvm.used can be discarded by
> >> >ld.bfd/gold/ld.lld --gc-sections.
> >> >  (If the section is a C identifier name, __start_/__stop_ relocations
> >> >from a live input section can retain the section, even if its defined
> >> >symbols are not referenced. [2] .
> >> >  I understand that some folks use `__attribute__((used,
> >> >section("C_ident")))` and expect the sections to be similar to GC
> >> >roots, however,
> >> >  non-C-identifier cases are very common, too. They don't get
> >> >__start_/__stop_ linker magic and the sections can always be GCed.
> >> >  )
> >> >
> >> >In LangRef, the description of llvm.used contains:
> >> >
> >> >> If a symbol appears in the @llvm.used list, then the compiler,
> assembler, and **linker** are required to treat the symbol as if there is
> a reference to the symbol that it cannot see (which is why they have to be
> named). For example, if a variable has internal linkage and no references
> other than that from the @llvm.used list, it cannot be deleted. This is
> commonly used to represent references from inline asms and other things
> the compiler cannot “see”, and corresponds to “attribute((used))” in GNU
> C.
> >> >
> >> >Note that the "linker" part does not match the reality on ELF targets.
> >> >It does match the reality on Mach-O and partially on COFF.
> >> >
> >> >llvm.compiler.used:
> >> >
> >> >> The @llvm.compiler.used directive is the same as the @llvm.used
> directive, except that it only prevents the compiler from touching the
> symbol. On targets that support it, this allows an **intelligent linker to
> optimize references to the symbol without being impeded** as it would be
> by @llvm.used.
> >> >
> >> >Note that this explicitly mentions linker GC, so this appears to be
> >> >the closest thing to __attribute__((used)) on ELF.
> >> >However, LangRef also says:
> >> >
> >> >> This is a rare construct that should only be used in rare
> circumstances, and should not be exposed to source languages.
> >> >
> >> >
> >> >
> >> >My goal is to implement __attribute__((retain)) (which will be in GCC
> >> >11) on ELF. GCC folks think that 'used' and 'retain are orthogonal.
> >> >(see
> https://urldefense.com/v3/__https://reviews.llvm.org/D96838*2578127__;Iw!!
> JmoZiZGBv3RvKRSx!rLrNj9PBZVjhd2ZivvkftKSeGpwQ57nAtK3ZvCcj3MeCRk9Gz-sSt4Y-
> y3hXRPvXMA$ )
> >> >
> >> >Shall we
> >> >
> >> >1. Lift the source language restriction on llvm.compiler.used and
> >> >change __attribute__((used)) to use llvm.compiler.used on ELF.
> >>
> >> It is too late here and I did not think of it clearly;-)
> >>
> >> Clarify:
> >>
> >> 1. Lift the source language restriction on llvm.compiler.used, let
> llvm.used use SHF_GNU_RETAIN on ELF, and change __attribute__((used)) to
> use llvm.compiler.used on ELF.
> >>
> >>
> >> __attribute__((retain)) has semantics which are not described by
> >> llvm.used/llvm.compiler.used.  To facilitate linker GC,
> __attribute__((retain))
> >> causes the section to be placed in a unique section. The separate
> section
> >> behavior can be undesired in some cases (e.g. poorly written Linux
> kernel linker
> >> scripts which expect one section per name).
> >>
> >> So in the -fno-function-sections -fno-data-sections case, a retained
> >> function/variable does not cause the whole .text/.data/.rodata to be
> retained.
> >>
> >> The test llvm/test/CodeGen/X86/elf-retain.ll in
> https://urldefense.com/v3/__https://reviews.llvm.org/D96837__;!!JmoZiZGBv3
> RvKRSx!rLrNj9PBZVjhd2ZivvkftKSeGpwQ57nAtK3ZvCcj3MeCRk9Gz-sSt4Y-y3igRCpu4Q$
> >> demonstrates the behavior.  So I am not particularly clear that we
> should use
> >> llvm.compiler.used/llvm.used to describe __attribute__((retain)) .
> >>
> >> >2. Or add a metadata (like
> https://urldefense.com/v3/__https://reviews.llvm.org/D96837)?__;!!JmoZiZGB
> v3RvKRSx!rLrNj9PBZVjhd2ZivvkftKSeGpwQ57nAtK3ZvCcj3MeCRk9Gz-sSt4Y-
> y3j8yTbbsA$
> >> >
> >> >
> >> >I lean to option 1 to leverage the existing mechanism.
> >> >The downside is that clang codegen will have some target inconsistency
> >> >(llvm.compiler.used on ELF while llvm.used on others).
> >> >
> >> >
> >> >
> >> >[1]: The implementation additionally allows GlobalAlias.
> >> >[2]: See https://urldefense.com/v3/__https://maskray.me/blog/2021-01-
> 31-metadata-sections-comdat-and-shf-link-
> order__;!!JmoZiZGBv3RvKRSx!rLrNj9PBZVjhd2ZivvkftKSeGpwQ57nAtK3ZvCcj3MeCRk9
> Gz-sSt4Y-y3jIbWqo9A$
> >> >"C identifier name sections" for details.
> >> _______________________________________________
> >> cfe-dev mailing list
> >> cfe-dev at lists.llvm.org
> >> https://urldefense.com/v3/__https://lists.llvm.org/cgi-
> bin/mailman/listinfo/cfe-
> dev__;!!JmoZiZGBv3RvKRSx!rLrNj9PBZVjhd2ZivvkftKSeGpwQ57nAtK3ZvCcj3MeCRk9Gz
> -sSt4Y-y3gvE5g2Qg$
> 
> 
> 
> --
> 宋方睿
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://urldefense.com/v3/__https://lists.llvm.org/cgi-
> bin/mailman/listinfo/cfe-
> dev__;!!JmoZiZGBv3RvKRSx!rLrNj9PBZVjhd2ZivvkftKSeGpwQ57nAtK3ZvCcj3MeCRk9Gz
> -sSt4Y-y3gvE5g2Qg$