search for: __cxx_global_var_init

...ctors are not placed in the same order by lld and we end up with some null pointers and I believe it has to do with the order of initializations of. I used nm -n to compare the symbols in the output of ld vs lld and found that many symbols are placed differently… When I grep the symbols to only see __cxx_global_var_init… I see that some are placed by lld differently than ld Question: The __cxx_global_var_initN symbols usually have a unique number (N) at the end but for my case there are few that do not have the unique number and some don’t even have any number (Just __cxx_global_var_init) because they are originat...

...align 4 @__dso_handle = external global i8* @.str = private unnamed_addr constant [6 x i8] c"~Foo\0A\00" @.str1 = private unnamed_addr constant [5 x i8] c"Foo\0A\00" @llvm.global_ctors = appending global [1 x %0] [%0 { i32 65535, void ()* @_GLOBAL__I_a }] define internal void @__cxx_global_var_init() nounwind section "__TEXT,__StaticInit,regular,pure_instructions" { call void @_ZN3FooC1Ev(%class.Foo* @foo) %1 = call i32 @__cxa_atexit(void (i8*)* bitcast (void (%class.Foo*)* @_ZN3FooD1Ev to void (i8*)*), i8* bitcast (%class.Foo* @foo to i8*), i8* bitcast (i8** @__dso_handle to i8*)...

...am:    #include <iostream>    int main(){      std::cout << "hello\n";      return 0;    } After generating llvm bitcode using the following command:       $ clang++ -c -emit-llvm -O -Xclang -disable-llvm-passes a.cpp the bitcode has the following function with define. __cxx_global_var_init    main    _ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc _ZNSt9basic_iosIcSt11char_traitsIcEE8setstateESt12_Ios_Iostate    _ZNSt11char_traitsIcE6lengthEPKc    _ZStorSt12_Ios_IostateS_    _ZNKSt9basic_iosIcSt11char_traitsIcEE7rdstateEv    _GLOBAL__sub_I_a.cpp In a pass, I want to kn...

...external global i8* > @.str = private unnamed_addr constant [6 x i8] c"~Foo\0A\00" > @.str1 = private unnamed_addr constant [5 x i8] c"Foo\0A\00" > @llvm.global_ctors = appending global [1 x %0] [%0 { i32 65535, void ()* @_GLOBAL__I_a }] > > define internal void @__cxx_global_var_init() nounwind section "__TEXT,__StaticInit,regular,pure_instructions" { >  call void @_ZN3FooC1Ev(%class.Foo* @foo) >  %1 = call i32 @__cxa_atexit(void (i8*)* bitcast (void (%class.Foo*)* @_ZN3FooD1Ev to void (i8*)*), i8* bitcast (%class.Foo* @foo to i8*), i8* bitcast (i8** @__dso_hand...

...ourier, monospace">clang++ -c -emit-llvm -O -Xclang -disable-llvm-passes a.cpp</font><br> </div> <div>the bitcode has the following function with define.</div> <div>      <font face="Courier New, Courier, monospace">__cxx_global_var_init<br>    main<br>    _ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc<br>    _ZNSt9basic_iosIcSt11char_traitsIcEE8setstateESt12_Ios_Iostate<br>    _ZNSt11char_traitsIcE6lengthEPKc<br>    _ZStorSt12_Ios_IostateS...

...n the other hand sometimes uses eh_frame and sometimes uses debug_frame. Here's an example: int f1(); int i = f1(); void func() { } Compiled with -fno-exceptions -g. The first two lines produce a global ctor. Clang is generous enough to flag the LLVM IR function for this global ctor ("__cxx_global_var_init") as nounwind (tools/clang/lib/CodeGen/CGDeclCXX.cpp:246), though "func" gets flagged as nounwind but also as uwtable (why? I don't really understand these semantics & haven't tracked down where that attribute gets applied) Without 'func' in this translation unit...

...1 _GLOBAL__sub_I_MarkLive.cpp __cxa_atexit 1 _ZN3lld3elf12LinkerScript24fabricateDefaultCommandsEv __cxa_atexit 1 _ZN3lld3elf12LinkerScript15processCommandsERNS0_20OutputSectionFactoryE __cxa_atexit 1 _ZN3lld3elf4makeINS0_13OutputSectionEJRN4llvm9StringRefENS3_3ELF3$_0EiEEEPT_DpOT0_ __cxa_atexit 1 __cxx_global_var_init.44 __cxa_atexit 1 __cxx_global_var_init.43 __cxa_atexit 1 __cxx_global_var_init.42 __cxa_atexit 1 __cxx_global_var_init.38 __cxa_atexit 1 _ZN3lld3elf4makeINS0_14DefinedRegularEJRNS0_10StringRefZEbRhS5_RmS6_RPNS0_16InputSectionBaseEPNS0_7ObjFileIN4llvm6object7ELFTypeILNSB_7support10endiannessE1ELb1E...

A rebased version of the lld patch is attached. Cheers, Rafael On 31 July 2017 at 15:11, Rafael Avila de Espindola <rafael.espindola at gmail.com> wrote: > Tobias Edler von Koch <tobias at codeaurora.org> writes: > >> Hi Rafael, >> >> On 07/31/2017 04:20 PM, Rafael Avila de Espindola via llvm-dev wrote: >>> However, do we need to start with

We know that in C++, the constructor of a static member will get called when the program starts up. I checked the generated IR code and found this is implemented by defining a __cxx_global_var_init() function and marked it as section ".text.startup" and assign it to @llvm.global_ctors. We also know that in C++, the constructor of a static thread_local member will *not* get called when the program starts, but the first time this member is used, I also checked the IR code, this is im...

I see that some of the system header-file definitions have the internal keyword. For example, define internal void @__cxx_global_var_init() section "__TEXT,__StaticInit,regular,pure_instructions" { entry: call void @_ZNSt8ios_base4InitC1Ev(%"class.std::ios_base::Init"* @_ZStL8__ioinit) %0 = call i32 @__cxa_atexit(void (i8*)* bitcast (void (%"class.std::ios_base::Init"*)* @_ZNSt8ios_base4InitD1Ev to v...

...79:15 #4 0x421020 in createMCAsmInfo /mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/include/llvm/Support/TargetRegistry.h:298:12 #5 0x421020 in Context /mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/unittests/MC/DwarfLineTables.cpp:41 #6 0x421020 in __cxx_global_var_init /mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/unittests/MC/DwarfLineTables.cpp:49 #7 0x421020 in _GLOBAL__sub_I_DwarfLineTables.cpp /mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/unittests/MC/DwarfLineTables.cpp #8 0x102efcc in __libc_csu_init (/mnt/b/...

Hi Dimitry, Thanks for your kind response! Thanks for the commit message of Jung's patch, I found that the bug had been fixed in OpenJDK 12 by Zhengyu https://bugs.openjdk.java.net/browse/JDK-8205965 But only backported to 11. So Jung could backport it for OpenJDK 8, thanks a lot! But I argue that the root cause might be in the compiler side, why clang-3.9.1, gcc-6.4.1 couldn't

Hi, I'd like to fix PR19590, which is about llvm.global_ctors containing functions that end up being empty after optimization (which causes the linker to add useless init_array entries to the output binary). globalopt removes empty functions from llvm.global_ctors, but by the time the function becomes empty globalopt has already run and it doesn't run again. I'm wondering what the

On 5/23/11 1:05 PM, George Baah wrote: > Hi, > I am writing a pass which is supposed to ignore library functions. Is > there a way to > distinguish functions declared and defined by a developer from > non-local functions (library functions)? > Thanks. There is no reliable way to do this, but there are several heuristics that will probably work well in practice. When

...: >> >> int f1(); >> int i = f1(); >> void func() { } >> >> Compiled with -fno-exceptions -g. >> >> The first two lines produce a global ctor. >> >> Clang is generous enough to flag the LLVM IR function for this global >> ctor ("__cxx_global_var_init") as nounwind >> (tools/clang/lib/CodeGen/CGDeclCXX.cpp:246), though "func" gets >> flagged as nounwind but also as uwtable (why? I don't really >> understand these semantics & haven't tracked down where that attribute >> gets applied) > > Is...

Hi, I am writing a pass which is supposed to ignore library functions. Is there a way to distinguish functions declared and defined by a developer from non-local functions (library functions)? Thanks. George -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110523/650c7fa4/attachment.html>

...e all copies will be the same. We can make f() available_externally (to enable inlining), and simply convert references to aliases of f() into direct references to f() and drop the aliases - does that sound right? Another tricky thing is if the weak symbol was a variable that is initialized via a __cxx_global_var_init function in the global_ctors list. If we have an alias to that symbol, presumably we'll want the new internalized/renamed version to get initialized instead? Now in the case where we have an alias that is itself a weak non-prevailing symbol, how we handle will I think depend on what it is ali...

> 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 > -------------------------------- > > TU2: >

> On Sep 1, 2016, at 9:20 PM, Greg Parker <gparker at apple.com> wrote: > >> On Sep 1, 2016, at 9:06 PM, llvm.buildmaster at lab.llvm.org wrote: >> >> The Buildbot has detected a new failure on builder sanitizer-x86_64-linux-fast while building llvm. >> Full details are available at: >>

Hi Mehdi, Peter and David (and anyone else who sees this), I've been playing with some examples to handle the weak symbol cases we discussed in IRC earlier this week in the context of D28523. I was going to implement the support for turning aliases into copies in order to enable performing thinLTOResolveWeakForLinkerGUID on both aliases and aliasees, as a first step to being able to drop