search for: dead_strip

...store i32 0, i32* %1, align 4 %2 = load i32, i32* @x, align 4 %3 = call i32 (i8*, ...) @printf(i8* getelementptr inbounds ([8 x i8], [8 x i8]* @.str, i32 0, i32 0), i32 %2) ret i32 0 } gives the following result (expected) $ clang test.ll $ ./a.out p = 123 x = 10 however, with -dead_strip on macOS, we see the following: $ clang test.ll -dead_strip $ ./a.out p = 0 x = 10 Thus I believe we are incorrectly stripping prefix data when linking with -dead_strip on macOS. As I do not have a bugzilla account, and hence cannot post this as a proper bug report. Cheers, Moritz

...tead? The alt_entry is supposed to be bound to the atom appearing *before* it. > _main.dsp = _main-4 > > .subsections_via_symbols > > (e.g. we inject the .alt_entry after the fact, pointing to the start of > the prefix data) > > this will yield: > > $ clang test.s -dead_strip > ld: warning: N_ALT_ENTRY bit set on first atom in section __TEXT/__text > And the prefix data will be stripped again. > > E.g. what you end up getting is: > > $ otool -vVtdj a.out > a.out: > _main: > 0000000100000fb5 ff c0 incl %eax > 0000000100000fb7...

...telementptr inbounds ([8 x i8], >> [8 x i8]* @.str, i32 0, i32 0), i32 %2) >> ret i32 0 >> } >> >> gives the following result (expected) >> >> $ clang test.ll >> $ ./a.out >> p = 123 >> x = 10 >> >> however, with -dead_strip on macOS, we see the following: >> >> $ clang test.ll -dead_strip >> $ ./a.out >> p = 0 >> x = 10 >> >> Thus I believe we are incorrectly stripping prefix data when linking with >> -dead_strip on macOS. >> >> As I do not have a...

...t; .section __TEXT,__text > > .globl _main > > > > .long 1 > > _main: > > inc %eax > > ret > > > > .alt_entry _main > > _main.dsp = _main-4 > > > > .subsections_via_symbols > > > > > > $ clang test.s -dead_strip > > $ otool -vVtdj a.out > > a.out: > > _main.dsp: > > 0000000100000fb1 01 00 addl %eax, (%rax) > > 0000000100000fb3 00 00 addb %al, (%rax) > > _main: > > 0000000100000fb5 ff c0 incl %eax > > 0000000100000fb7...

...Peter! > > That seems to do the trick! > > $ cat test.s > .section __TEXT,__text > .globl _main > > .long 1 > _main: > inc %eax > ret > > .alt_entry _main > _main.dsp = _main-4 > > .subsections_via_symbols > > > $ clang test.s -dead_strip > $ otool -vVtdj a.out > a.out: > _main.dsp: > 0000000100000fb1 01 00 addl %eax, (%rax) > 0000000100000fb3 00 00 addb %al, (%rax) > _main: > 0000000100000fb5 ff c0 incl %eax > 0000000100000fb7 c3 retq > > > > Howeve...

...n 4 > %3 = call i32 (i8*, ...) @printf(i8* getelementptr inbounds ([8 x i8], [8 x i8]* @.str, i32 0, i32 0), i32 %2) > ret i32 0 > } > > gives the following result (expected) > > $ clang test.ll > $ ./a.out > p = 123 > x = 10 > > however, with -dead_strip on macOS, we see the following: > > $ clang test.ll -dead_strip > $ ./a.out > p = 0 > x = 10 > > Thus I believe we are incorrectly stripping prefix data when linking with -dead_strip on macOS. > > As I do not have a bugzilla account, and hence cannot post t...

...uldn’t be sufficient), and for testing fuzzers I was always building them in debug > Yea, we need to make sure the pc-tables are not stripped (this is a separate section with globals). > (I still haven't documented pc-tables, will do soon) > Do you know what's the analog of Wl,-dead_strip on Linux? Apparently -Wl,—gc-sections. For some reason LLVM does not do it for gold, even though it seems to support this flag as well. (that could be another reason why you don’t see the failure on Linux) 1 if(NOT LLVM_NO_DEAD_STRIP) 2 if(${CMAKE_SYSTEM_NAME} MATCHES "Darwin") 3...

...rs I was always building them in debug >> >> Yea, we need to make sure the pc-tables are not stripped (this is a >> separate section with globals). >> (I still haven't documented pc-tables, will do soon) >> >> >> Do you know what's the analog of Wl,-dead_strip on Linux? >> >> >> Apparently -Wl,—gc-sections. >> For some reason LLVM does not do it for gold, even though it seems to >> support this flag as well. >> (that could be another reason why you don’t see the failure on Linux) >> >> 1 *if*(NOT LLVM_NO_D...

...t; >> Yea, we need to make sure the pc-tables are not stripped (this is a >> >> separate section with globals). >> >> (I still haven't documented pc-tables, will do soon) >> >> >> >> >> >> Do you know what's the analog of Wl,-dead_strip on Linux? >> >> >> >> >> >> Apparently -Wl,—gc-sections. >> >> For some reason LLVM does not do it for gold, even though it seems to >> >> support this flag as well. >> >> (that could be another reason why you don’t see the fai...

...e pc-tables are not stripped (this is a >>>> >> separate section with globals). >>>> >> (I still haven't documented pc-tables, will do soon) >>>> >> >>>> >> >>>> >> Do you know what's the analog of Wl,-dead_strip on Linux? >>>> >> >>>> >> >>>> >> Apparently -Wl,—gc-sections. >>>> >> For some reason LLVM does not do it for gold, even though it seems to >>>> >> support this flag as well. >>>> >> (that c...

...>>>>> >> separate section with globals). > >>>>> >> (I still haven't documented pc-tables, will do soon) > >>>>> >> > >>>>> >> > >>>>> >> Do you know what's the analog of Wl,-dead_strip on Linux? > >>>>> >> > >>>>> >> > >>>>> >> Apparently -Wl,—gc-sections. > >>>>> >> For some reason LLVM does not do it for gold, even though it > seems to > >>>>> >> support th...

...> >>> -Chris >> >> Chris, >> I am using cmake 3.5.2. My read of this problem is as follows. >> While libLLVM.dylib is being linked against -lxar when >> -DLLVM_LINK_LLVM_DYLIB:BOOL=ON is passed to cmake, the libLLVM.dylib >> is created with -Wl,-dead_strip such that any symbols from libxar not >> explicitly used with in the object files of libLLVM.dylib are stripped >> out. This means that those additional symbols used by llvm-objdump >> aren't accessible from libLLVM.dylib's linkage on libxar and an >> additional expl...

...LLVMOptions.cmake > @@ -665,6 +665,9 @@ if(LLVM_USE_SANITIZER) > endif() > if (LLVM_USE_SANITIZE_COVERAGE) > append("-fsanitize=fuzzer-no-link" CMAKE_C_FLAGS CMAKE_CXX_FLAGS) > + > + # Dead stripping messes up coverage instrumentation. > + set(LLVM_NO_DEAD_STRIP ON) > endif() > endif() > > Any arguments against that? We shouldn't do this. We really only want to prevent dead stripping of the counters themselves - disabling it completely isn't very nice. > Apparently, a better way is to follow ASAN instrumentation pass, > whic...

...e: > Jack, > > What version of CMake are you using? > > -Chris Chris, I am using cmake 3.5.2. My read of this problem is as follows. While libLLVM.dylib is being linked against -lxar when -DLLVM_LINK_LLVM_DYLIB:BOOL=ON is passed to cmake, the libLLVM.dylib is created with -Wl,-dead_strip such that any symbols from libxar not explicitly used with in the object files of libLLVM.dylib are stripped out. This means that those additional symbols used by llvm-objdump aren't accessible from libLLVM.dylib's linkage on libxar and an additional explicit linkage on libxar is required i...

...of CMake are you using? >> >> -Chris > > Chris, > I am using cmake 3.5.2. My read of this problem is as follows. > While libLLVM.dylib is being linked against -lxar when > -DLLVM_LINK_LLVM_DYLIB:BOOL=ON is passed to cmake, the libLLVM.dylib > is created with -Wl,-dead_strip such that any symbols from libxar not > explicitly used with in the object files of libLLVM.dylib are stripped > out. This means that those additional symbols used by llvm-objdump > aren't accessible from libLLVM.dylib's linkage on libxar and an > additional explicit linkage on...

...parate section with globals). >>> >>>>> >> (I still haven't documented pc-tables, will do soon) >>> >>>>> >> >>> >>>>> >> >>> >>>>> >> Do you know what's the analog of Wl,-dead_strip on Linux? >>> >>>>> >> >>> >>>>> >> >>> >>>>> >> Apparently -Wl,—gc-sections. >>> >>>>> >> For some reason LLVM does not do it for gold, even though it >>> seems to >&...

...ce. Is it because the globals added to compiler used is ignored by the optimizer so they cannot be internalized and they cannot be optimized away? This works well for the case I am looking at because c++ VTable can't really be optimized and for darwin platforms because we can rely on ld64 to do dead_stripping if needed. 2. Add visibility hidden when promote linkonce_odr + unnamed_addr. Well,this doesn't really preserve the link semantics, but neither does promoting linkonce_odr to weak_odr. The global will still end up in the symbol table but at least it isn't external so it doesn't co...

...e globals added to compiler used is > ignored by the optimizer so they cannot be internalized and they cannot be > optimized away? This works well for the case I am looking at because c++ > VTable can't really be optimized and for darwin platforms because we can > rely on ld64 to do dead_stripping if needed. > > 2. Add visibility hidden when promote linkonce_odr + unnamed_addr. > Well,this doesn't really preserve the link semantics, but neither does > promoting linkonce_odr to weak_odr. The global will still end up in the > symbol table but at least it isn't extern...

...to compiler used is >> ignored by the optimizer so they cannot be internalized and they cannot be >> optimized away? This works well for the case I am looking at because c++ >> VTable can't really be optimized and for darwin platforms because we can >> rely on ld64 to do dead_stripping if needed. >> >> 2. Add visibility hidden when promote linkonce_odr + unnamed_addr. >> Well,this doesn't really preserve the link semantics, but neither does >> promoting linkonce_odr to weak_odr. The global will still end up in the >> symbol table but at least...

...e globals added to compiler used is > ignored by the optimizer so they cannot be internalized and they cannot be > optimized away? This works well for the case I am looking at because c++ > VTable can't really be optimized and for darwin platforms because we can > rely on ld64 to do dead_stripping if needed. > > 2. Add visibility hidden when promote linkonce_odr + unnamed_addr. > Well,this doesn't really preserve the link semantics, but neither does > promoting linkonce_odr to weak_odr. The global will still end up in the > symbol table but at least it isn't extern...