search for: comdat

...hen that TU emits a constant weak >>> object (in .rodata if we want) containing the folded value and with the guard >>> variable set to 1 (per Eli's proposal). >> >> The ABI actually suggests doing exactly this, except using multiple >> symbols linked with a COMDAT group. Unfortunately, LLVM doesn't >> support that COMDAT feature yet, but it could certainly be taught to. >> This guarantees correctness as long as every translation unit emits the >> code the same way, which is exactly what we'd get from an ABI change, >> except...

I've been digging into COMDAT with regular LTO, specifically in the context of the LLVM gold plugin. The GCC WHOPR documentation specifies that the linker will resolve all COMDAT groups to the IR-provided definitions, if available. Additionally it specifies that "When the WPA phase produces the definition of the COMDAT sym...

> Unfortunately, making the comdat be for the entire function is not > conformant with the ABI, which says that you either put the variable > and its guard in different comdats or you put them in a single comdat > named for the variable.  It also doesn't actually help unless we disable > inlining. I see. Using two c...

On Nov 21, 2011, at 9:05 AM, Rafael Espíndola wrote: >> Unfortunately, making the comdat be for the entire function is not >> conformant with the ABI, which says that you either put the variable >> and its guard in different comdats or you put them in a single comdat >> named for the variable. It also doesn't actually help unless we disable >> inlining. &gt...

...7) { x += 3; } return x; } }; int Foo::public_foo() { return inline_foo() ? inline_bar1() : inline_bar2(); } ``` Compiling this with `clang++ -fsanitize-coverage=trace-pc-guard /tmp/test.cpp -c -O1` generates sancov guards (__sancov_gen_.X) that are used outside of their comdat group due to inlining: ``` @__sancov_gen_.1 = private global [3 x i32] zeroinitializer, section "__sancov_guards", comdat($_ZN3Foo10inline_fooEv) define dso_local i32 @_ZN3Foo10public_fooEv(%struct.Foo* %0) local_unnamed_addr #0 comdat align 2 { call void @__sanitizer_cov_trace_pc_g...

> I see. Using two comdats would still cause the same problem for us, > no? So the solution in the end is to emit: > > TU1: > -------------------------------- > @_ZN1UI1SE1kE = weak_odr constant i32 42, align 4, comdat _ZN1UI1SE1kE > @_ZGVN1UI1SE1kE = weak_odr global i64 1, comdat _ZN1UI1SE1kE > -------...

...y translation unit, then that TU emits a constant weak >> object (in .rodata if we want) containing the folded value and with the guard >> variable set to 1 (per Eli's proposal). > > The ABI actually suggests doing exactly this, except using multiple > symbols linked with a COMDAT group.  Unfortunately, LLVM doesn't > support that COMDAT feature yet, but it could certainly be taught to. > This guarantees correctness as long as every translation unit emits the > code the same way, which is exactly what we'd get from an ABI change, > except without actually...

...; initialization in any translation unit, then that TU emits a constant weak > object (in .rodata if we want) containing the folded value and with the guard > variable set to 1 (per Eli's proposal). The ABI actually suggests doing exactly this, except using multiple symbols linked with a COMDAT group. Unfortunately, LLVM doesn't support that COMDAT feature yet, but it could certainly be taught to. This guarantees correctness as long as every translation unit emits the code the same way, which is exactly what we'd get from an ABI change, except without actually breaking ABI confor...

Hi, As part of PR27551 I want to add a string table to the bitcode format to allow global value and comdat names to be shared with the proposed symbol table (and, as side effects, allow comdat names to be shared with value names, make bitcode files more compressible and make bitcode easier to parse). The format of the string table would be a top-level block containing a blob containing null-terminated s...

...be either included >> or excluded as a unit. > I thought groups were a collection of symbol - not sections. Is this a case > where there is one symbol per section? It's sections. There is no restriction on symbols in a group section. > >> They also are used to implement COMDAT. Each >> group has an "identifying symbol entry" or "group signature". This is >> only used in the case of COMDAT groups (which are marked with a flag). >> When two COMDAT groups have the same group signature the linker must >> select one (not specified h...

...excluded as a unit. >> I thought groups were a collection of symbol - not sections. Is this a case >> where there is one symbol per section? > > It's sections. There is no restriction on symbols in a group section. > >> >>> They also are used to implement COMDAT. Each >>> group has an "identifying symbol entry" or "group signature". This is >>> only used in the case of COMDAT groups (which are marked with a flag). >>> When two COMDAT groups have the same group signature the linker must >>> select one...

...hought groups were a collection of symbol - not sections. Is this a > case > >> where there is one symbol per section? > > > > It's sections. There is no restriction on symbols in a group section. > > > >> > >>> They also are used to implement COMDAT. Each > >>> group has an "identifying symbol entry" or "group signature". This is > >>> only used in the case of COMDAT groups (which are marked with a flag). > >>> When two COMDAT groups have the same group signature the linker must > >...

My recent change to use more aliases for destrucors in clang has opened a can of worms. The fundamental issue is that aliasing in object files have fairly complex semantics. For example, on ELF if a symbol is defined in a COMDAT in one object file, it must be defined in every object file that has that COMDAT. Given that weak symbols get implemented with COMDATs, the actual rule at the llvm level would have to be something like * If an alias is declared to a isWeakForLinker symbol in one object file, it must be defined in...

A clarification pointed out by David Majnemer: what I"m really talking about is "comdat or comdat-semantic-equivalents" which include linkonce_odr and available_externally. As a further strategy to recover optimizations: On platforms with comdat support, we could also teach function attrs that deduction is safe for functions which are only called from within their own comdat. A...

...we might also want to check that both > symbols have non-default visibility, but I think that our support for that > is still a little fuzzy at the moment. > Per your and David's analysis it sounds like this is a bug then - I can file a bug to track it with the example. Regarding the comdat case I mentioned - Peter and I discussed on IRC and he pointed out that my case was illegal since aliases are by definition in the same comdat group as the symbol they alias. So in effect I had an incomplete comdat group. Thanks, Teresa > Thanks, > Peter > > On Fri, Jan 13, 2017 at 2...

> There are also odd stuffs such as COMDAT groups or > merge-not-by-name-but-by-content sections, that may complicate the model. (I > don't think about that yet.) For comdats (on ELF) you should be able to avoid even reading the bits from subsequent files once a comdat of a given name has been found. Cheers, Rafael

...e concept of a group to the atom model directly, as modeling it with references fails to capture some semantics. http://www.sco.com/developers/gabi/latest/ch4.sheader.html Groups in ELF are collections of sections that must be either included or excluded as a unit. They also are used to implement COMDAT. Each group has an "identifying symbol entry" or "group signature". This is only used in the case of COMDAT groups (which are marked with a flag). When two COMDAT groups have the same group signature the linker must select one (not specified how to pick) and discard _all_ member...

Hi Nick, Bigcheese, I wanted to add support to support .gnu.linkonce sections in the resolver. _*About .gnu.linkonce sections*_ .gnu.linkonce sections were primarily present in ELF that was used in a way to model COMDAT in early ELF implementations. We have seen usecases of .gnu.linkonce sections used in various object files(mainly libc), and I think its much needed to support this style in lld as well. _*a solution to support .gnu.linkonce in lld*_ I was thinking of adding a typeGnuLinkOnce and special case...

...s would each become a copy of weak1.c's f()). If we however want them to resolve to the prevailing copy of f(), then we need to turn the aliases into declarations (external linkage in the case of strongalias and external weak in the case of weakalias?). I also tried the case where f() was in a comdat, because I also need to handle that case in ThinLTO (when f() is not prevailing, drop it from the comdat and remove the comdat from that module). Interestingly, in this case when weak2.c is prevailing, I get the following warning when linking and get a seg fault at runtime: weak1.o:weak1.o:functio...

...pers/gabi/latest/ch4.sheader.html > > Groups in ELF are collections of sections that must be either included > or excluded as a unit. I thought groups were a collection of symbol - not sections. Is this a case where there is one symbol per section? > They also are used to implement COMDAT. Each > group has an "identifying symbol entry" or "group signature". This is > only used in the case of COMDAT groups (which are marked with a flag). > When two COMDAT groups have the same group signature the linker must > select one (not specified how to pick) and...