search for: markliv

...0467a890 __restore_rt > (/lib/x86_64-linux-gnu/libpthread.so.0+0x12890) > > #4 0x000056348d614025 lld::coff::DefinedRegular::getChunk() const > /home/jshi19/llvm/llvm-project/lld/COFF/Symbols.h:176:0 > > #5 0x000056348d614025 operator() > /home/jshi19/llvm/llvm-project/lld/COFF/MarkLive.cpp:46:0 > > #6 0x000056348d614025 > lld::coff::markLive(llvm::ArrayRef<lld::coff::Chunk*>) > /home/jshi19/llvm/llvm-project/lld/COFF/MarkLive.cpp:55:0 > > #7 0x000056348d5f363e std::vector<lld::coff::Chunk*, > std::allocator<lld::coff::Chunk*> >::~vector() &...

...nix/Signals.inc:357:0 #3 0x00007f172a5f2890 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x12890) #4 0x000055f11edd8025 lld::coff::DefinedRegular::getChunk() const /home/jshi19/llvm/llvm-project/lld/COFF/Symbols.h:176:0 #5 0x000055f11edd8025 operator() /home/jshi19/llvm/llvm-project/lld/COFF/MarkLive.cpp:46:0 #6 0x000055f11edd8025 lld::coff::markLive(llvm::ArrayRef<lld::coff::Chunk*>) /home/jshi19/llvm/llvm-project/lld/COFF/MarkLive.cpp:55:0 #7 0x000055f11edb763e std::vector<lld::coff::Chunk*, std::allocator<lld::coff::Chunk*> >::~vector() /usr/include/c++/7/bits/stl_vector.h...

...2a5f2890 __restore_rt > (/lib/x86_64-linux-gnu/libpthread.so.0+0x12890) > > #4 0x000055f11edd8025 lld::coff::DefinedRegular::getChunk() const > /home/jshi19/llvm/llvm-project/lld/COFF/Symbols.h:176:0 > > #5 0x000055f11edd8025 operator() > /home/jshi19/llvm/llvm-project/lld/COFF/MarkLive.cpp:46:0 > > #6 0x000055f11edd8025 > lld::coff::markLive(llvm::ArrayRef<lld::coff::Chunk*>) > /home/jshi19/llvm/llvm-project/lld/COFF/MarkLive.cpp:55:0 > > #7 0x000055f11edb763e std::vector<lld::coff::Chunk*, > std::allocator<lld::coff::Chunk*> >::~vector() &...

...u/libpthread.so.0+0x12890) >>> >>> #4 0x000056348d614025 lld::coff::DefinedRegular::getChunk() const >>> /home/jshi19/llvm/llvm-project/lld/COFF/Symbols.h:176:0 >>> >>> #5 0x000056348d614025 operator() >>> /home/jshi19/llvm/llvm-project/lld/COFF/MarkLive.cpp:46:0 >>> >>> #6 0x000056348d614025 >>> lld::coff::markLive(llvm::ArrayRef<lld::coff::Chunk*>) >>> /home/jshi19/llvm/llvm-project/lld/COFF/MarkLive.cpp:55:0 >>> >>> #7 0x000056348d5f363e std::vector<lld::coff::Chunk*, >>> s...

...2a5f2890 __restore_rt > (/lib/x86_64-linux-gnu/libpthread.so.0+0x12890) > > #4 0x000055f11edd8025 lld::coff::DefinedRegular::getChunk() const > /home/jshi19/llvm/llvm-project/lld/COFF/Symbols.h:176:0 > > #5 0x000055f11edd8025 operator() > /home/jshi19/llvm/llvm-project/lld/COFF/MarkLive.cpp:46:0 > > #6 0x000055f11edd8025 > lld::coff::markLive(llvm::ArrayRef<lld::coff::Chunk*>) > /home/jshi19/llvm/llvm-project/lld/COFF/MarkLive.cpp:55:0 > > #7 0x000055f11edb763e std::vector<lld::coff::Chunk*, > std::allocator<lld::coff::Chunk*> >::~vector() &...

...g: "When performing unused section elimination, the link editor should ensure that both the section and the referenced section are retained or discarded together." This sentence makes sense to me, and I assumed lld works like this. When looking through the code of lld, I found that in MarkLive::markLive(), the liveness of parent sections is not propagated to the child sections. Instead, it is marked as live resulting that the section is kept even though the parent section is removed. To fix this issue, I propose changing the code marking sections live to the following loop: for (Inp...

...nused section elimination, the link editor should >ensure that both the section and the referenced section are retained >or discarded together." > >This sentence makes sense to me, and I assumed lld works like this. > >When looking through the code of lld, I found that in >MarkLive::markLive(), the >liveness of parent sections is not propagated to the child sections. >Instead, >it is marked as live resulting that the section is kept even though the >parent >section is removed. > >To fix this issue, I propose changing the code marking sections live to &gt...

...evaluates symbol assignments in many passes, the representation of a symbol (section+offset) can vary among passes. In the GC pass, its rule only works for simple expressions like --defsym d=foo, but not any slightly complex expressions. In lld, it would be difficult to drop the following rule in MarkLive.cpp: for (StringRef s : script->referencedSymbols) markSymbol(symtab->find(s)); The issue can be demonstrated by the following call tree: LinkerDriver::link markLive ... resolveReloc // Defined::section is nullptr for `d` because the assignment d=foo hasn't been...

On Tue, Nov 10, 2020 at 7:01 PM Fāng-ruì Sòng <maskray at google.com> wrote: > > How to find what is pulling libmvec? > > If you build a -DCMAKE_BUILD_TYPE=Debug lld, you can set a breakpoint > on lld/ELF/MarkLive.cpp:114 (ss->getFile().isNeeded) and check which > symbol makes > libmvec.so needed. I'm afraid this is going to far for me :) > > On the other hand, I don't understand why I have to specify that I > > want exp from glibc 2.2 or 2.29, I just want the exp symbol, and...

...vm::sys::RunSignalHandlers() (/home/jshi19/llvm/releaseinstall/bin/lld-link+0x270d14) #2 0x0000559a34ba3e52 SignalHandler(int) (/home/jshi19/llvm/releaseinstall/bin/lld-link+0x270e52) #3 0x00007f896c8ea890 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x12890) #4 0x0000559a34c11325 lld::coff::markLive(llvm::ArrayRef<lld::coff::Chunk*>) (/home/jshi19/llvm/releaseinstall/bin/lld-link+0x2de325) #5 0x0000559a34bf0220 lld::coff::LinkerDriver::link(llvm::ArrayRef<char const*>) (/home/jshi19/llvm/releaseinstall/bin/lld-link+0x2bd220) #6 0x0000559a34bf0478 lld::coff::link(llvm::ArrayRef<...

...d14) >> >> #2 0x0000559a34ba3e52 SignalHandler(int) >> (/home/jshi19/llvm/releaseinstall/bin/lld-link+0x270e52) >> >> #3 0x00007f896c8ea890 __restore_rt >> (/lib/x86_64-linux-gnu/libpthread.so.0+0x12890) >> >> #4 0x0000559a34c11325 >> lld::coff::markLive(llvm::ArrayRef<lld::coff::Chunk*>) >> (/home/jshi19/llvm/releaseinstall/bin/lld-link+0x2de325) >> >> #5 0x0000559a34bf0220 lld::coff::LinkerDriver::link(llvm::ArrayRef<char >> const*>) (/home/jshi19/llvm/releaseinstall/bin/lld-link+0x2bd220) >> >> #6...

Thank you very much for your help Fāng-ruì Sòng. I've tried various things like linking directly to libm-2.32 but it didn't work, it seems that libm-2.32 still pulls libmvec. I have the following linker flags: CLANG_LDFLAGS="-fuse-ld=lld -static-libstdc++ -static-libgcc -fvisibility=hidden -fdata-sections -ffunction-sections" CLANG_LDFLAGS="$CLANG_LDFLAGS

...om> wrote: > > > > On Tue, Nov 10, 2020 at 7:01 PM Fāng-ruì Sòng <maskray at google.com> wrote: > > > > How to find what is pulling libmvec? > > > > > > If you build a -DCMAKE_BUILD_TYPE=Debug lld, you can set a breakpoint > > > on lld/ELF/MarkLive.cpp:114 (ss->getFile().isNeeded) and check which > > > symbol makes > > > libmvec.so needed. > > > > I'm afraid this is going to far for me :) > > > > > > On the other hand, I don't understand why I have to specify that I > > > &g...

...<bique.alexandre at gmail.com> wrote: > > On Tue, Nov 10, 2020 at 7:01 PM Fāng-ruì Sòng <maskray at google.com> wrote: > > > How to find what is pulling libmvec? > > > > If you build a -DCMAKE_BUILD_TYPE=Debug lld, you can set a breakpoint > > on lld/ELF/MarkLive.cpp:114 (ss->getFile().isNeeded) and check which > > symbol makes > > libmvec.so needed. > > I'm afraid this is going to far for me :) > > > > On the other hand, I don't understand why I have to specify that I > > > want exp from glibc 2.2 or 2.29,...

...tly in terms of code quality or performance, at least in comparison to parsing the DWARF itself. sizeof(InputSection) is 208 (sizeof(Elf64_Shdr)=64) so there is indeed a significant overhead on fragmented segments. A MergeInputSection can be split into SectionPiece, which is indeed lightweight and MarkLive can mark liveness on these pieces. However, in InputFiles.cpp we change MergeInputSection to regular if it has a relocation (toRegularSection). Using more lightweight data structures for .debug_* fragments is still challenging. >> Thank you, Alexey. >> >> >> Thanks, >&g...

...S -Wl,--gc-sections -Wl,-O1 > -Wl,--as-needed -Wl,--strip-all" > CLANG_LDFLAGS="$CLANG_LDFLAGS -Wl,-y,exp,-y,exp at GLIBC_2.29,-y,exp at GLIBC_2.2.5" > > How to find what is pulling libmvec? If you build a -DCMAKE_BUILD_TYPE=Debug lld, you can set a breakpoint on lld/ELF/MarkLive.cpp:114 (ss->getFile().isNeeded) and check which symbol makes libmvec.so needed. > On the other hand, I don't understand why I have to specify that I > want exp from glibc 2.2 or 2.29, I just want the exp symbol, and if > possible the latest version available on the system. > B...

On Wed, 4 Dec 2019 at 07:05, Fāng-ruì Sòng <maskray at google.com> wrote: > > On Tue, Dec 3, 2019 at 7:02 PM Shoaib Meenai via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > > > LLD treats any symbol referenced from a linker script as a GC root, which makes sense. Unfortunately, it also processes --defsym as a linker script fragment internally, so all target

...gt; >> > On Tue, Nov 10, 2020 at 7:01 PM Fāng-ruì Sòng <maskray at google.com> wrote: >> > > > How to find what is pulling libmvec? >> > > >> > > If you build a -DCMAKE_BUILD_TYPE=Debug lld, you can set a breakpoint >> > > on lld/ELF/MarkLive.cpp:114 (ss->getFile().isNeeded) and check which >> > > symbol makes >> > > libmvec.so needed. >> > >> > I'm afraid this is going to far for me :) >> > >> > > > On the other hand, I don't understand why I have to specify...

You might have realized this already but it's probably not a good idea to use InputSection::Relocations for this because that ends up missing anything that becomes a dynamic relocation. I reckon that the code should be doing exactly what MarkLive.cpp is doing. Peter On Thu, Feb 28, 2019 at 5:15 PM Rui Ueyama via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I hacked up a patch to make lld output a dependency graph in the graphviz > "dot" format. > > https://gist.github.com/rui314/4eab9f328a5568b682d11c84d32...

...aed123216ad4a38a9c2b16f1783895fd5cb1a04) (git at github.com:llvm-mirror/llvm.git d209b37aec1e392dabbf9b5324ea4a60c36fbc55)"} $ /opt/llvm-svn/bin/lli hello2.dce.ll 'main' function not found in module. *No* more Alive Functions, so LLVM v6.0 Internalize and GlobalDCE PASS failed to MarkLive Function together? But LLVM 3.1 is able to work together: $ ./build/Release+Asserts/bin/opt --version LLVM (http://llvm.org/):   LLVM version 3.1   Optimized build with assertions.   Built Oct 23 2017 (16:22:51).   Default target: x86_64-unknown-linux-gnu   Host CPU: corei7-avx $ ./build/...