search for: dso

I get some failing tests from compiler-rt. FAIL: cfi :: cross-dso/stats.cpp (30831 of 30893) ******************** TEST 'cfi :: cross-dso/stats.cpp' FAILED ******************** Script: -- /usr/local/google/home/prazek/llvm-build-release/./bin/clang -fuse-ld=gold -flto -fsanitize=cfi -fwhole-program-vtables --driver-mode=g++ -fsanitize-cfi-cross-dso -fvisib...

There seem to be some recent regressions in clang/llvm. I see some test failing, and there is also this issue: https://llvm.org/bugs/show_bug.cgi?id=30466 Is anyone working on it? Piotr -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160920/ade5e8cd/attachment.html>

On Wed, Apr 20, 2016 at 1:42 PM, Renato Golin via llvm-dev <llvm-dev at lists.llvm.org> wrote: > On 20 April 2016 at 13:18, Yury Gribov <y.gribov at samsung.com> wrote: >> Not when dead store happens in an external DSO where compiler can't detect >> it (same applies for single references). > > Do you mean the ones between the DSO and the instrumented code? > Because if it's just in the DSO itself, then the compiler could have > spotted it, too, when compiling the DSO. > > I mean, o...

Hi, I'm seeming new regressions form 4.0.0 for mips big endian: DataFlowSanitizer-mips64 :: custom.cc DataFlowSanitizer-mips64 :: propagate.c SanitizerCommon-asan-mips-Linux :: sanitizer_coverage_trace_pc_guard-dso.cc SanitizerCommon-asan-mips-Linux :: sanitizer_coverage_trace_pc_guard.cc SanitizerCommon-asan-mips64-Linux :: Linux/getpwnam_r_invalid_user.cc SanitizerCommon-asan-mips64-Linux :: sanitizer_coverage_trace_pc_guard-dso.cc SanitizerCommon-asan-mips64-Linux :: sanitizer_coverage_trac...

Right. Usually you wouldn't want to write a .tbe from scratch, but for the sake of linking against a DSO you might only have access to a .tbe stub that was produced from the DSO. This specific functionality becomes critical when DSOs only used for linking are replaced entirely by .tbe stubs because at a SDK level the complete DSO isn't needed. This is what Apple has done to significantly reduce th...

Ashok Nalkund wrote: > > Resending :(. Any pointers? Fundamentally the issue is that the system linker is supposed to define __dso_handle when linking, but since there is no system linker between your build of the .bc files and running lli, nobody has defined it. It seems reasonable to me that lli should define __dso_handle if it's declared in the module. You could module tools/lli/lli.cpp to add a global: char *du...

..., i32, i32} {0, @A::rtti, @A::f - (@A_vtable + 16), @A::g - (@A_vtable + 16)} > > There's a subtlety about this aspect of the ABI that I should call attention to. The virtual function references can only be resolved directly by the static linker if they are defined in the same executable/DSO as the virtual table. I expect this to be the overwhelmingly common case, as classes are normally wholly defined within a single executable or DSO, so our implementation should be optimized around that case. > > If we expected cross-DSO references to be relatively common, we could make vtabl...

Absolutely. The goal of the tool is to produce both textual and binary DSO stubs. This means you could take a DSO, produce a textual stub, modify it however you wish, and then produce a linkable binary stub from that modified .tbe. That, or you could bypass the textual portion altogether and just produce binary stubs from DSOs. While the textual format is useful, the goal...

?Hi, I found a new issue in lld (https://llvm.org/bugs/show_bug.cgi?id=26222), but after review of outputs internals still have no idea why that can happen. Do you have any thoughts about possible reasons of that ? I am going to continue investigating that tomorrow. Best regards, George. -------------- next part -------------- An HTML attachment was scrubbed... URL:

...'::_1::' part). That >> won't work. >> >> Nick > > Thanks for the clue. I had earlier tried to use libc++ and there were > some remnants of that try. I've now cleaned up and now it gets past the > use_facet error. > > It now complains about '__dso_handle'. I saw a bug already reported but > its status is still NEW: > http://llvm.org/bugs/show_bug.cgi?id=7847 > > As mentioned in the bug, the problem seems to be when the interpreter is > used. > > There is another post on cfe-dev list: > http://clang-developers.4246...

> What about creating an msan interface DSO for the purposes of satisfying -z > defs? The executable will always be searched first, so the interface DSO > could be empty or full of ud2a. I like the idea. The ideal solution would probably be for the linkers to have a --not-needed command line option that prevents the .so from going in...

...olve the problem. However I noticed this message turning up in the logs: [Fri Aug 28 01:27:30.057020 2015] [proxy:warn] [pid 23782:tid 139661984888576] [client 173.213.212.234:14579] AH01144: No protocol handler was valid for the URL /mycompanyStore/images/Jimmy_792x802_R2.jpg. If you are using a DSO version of mod_proxy, make sure the proxy submodules are included in the configuration using LoadModule., referer: http://stage.theshopatmycompanystudios.com/ [Fri Aug 28 01:27:30.057216 2015] [proxy:warn] [pid 23780:tid 139661995378432] [client 173.213.212.234:14577] AH01144: No protocol handler...

Hmm, I'm confused. The DSO is compiled with gcc. Do I need to compile it with clang instead? I don't believe the JITted code uses the thread support library directly, although I suppose it may be hidden with templates and/or inline functions... On Mon, Sep 28, 2020 at 10:43 PM Lang Hames <lhames at gmail.com> wrot...

...er I noticed this message turning up in the logs: > > [Fri Aug 28 01:27:30.057020 2015] [proxy:warn] [pid 23782:tid > 139661984888576] [client 173.213.212.234:14579] AH01144: No protocol > handler was valid for the URL /mycompanyStore/images/Jimmy_792x802_R2.jpg. > If you are using a DSO version of mod_proxy, make sure the proxy > submodules are included in the configuration using LoadModule., referer: > http://stage.theshopatmycompanystudios.com/ > > [Fri Aug 28 01:27:30.057216 2015] [proxy:warn] [pid 23780:tid > 139661995378432] [client 173.213.212.234:14577] AH011...

...t; the same value already in memory). Xref the Deadspy paper from CGO 2012. > > This should probably be spotted by the compiler, so I guess it's a > tool for compiler developers to spot missed optimisation opportunities > in the back-end. Not when dead store happens in an external DSO where compiler can't detect it (same applies for single references). >> *Single-reference*: this tool identifies data cache lines brought in but >> only read once. These could be candidates for non-temporal loads. > > That's nice and should be simple enough to get a rep...

...files instead of statically linked binaries - reducing both disk space and runtime memory consumption. [...] ?https://wiki.syslinux.org/wiki/index.php?title=Syslinux_5_Changelog The pros are obviously explained. But this causes some side effects. Those modules may be erroneously treated as system DSOs. ? libcom32.c32 ELF Header: Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 Class: ELF64 Data: 2's complement, little endian Version: 1 (current) OS/ABI: UNIX - Sy...

Hi JITters, I have some JIT-compiled C++ code that uses symbols from a DSO which uses C++14's thread support library. When I compile it I get the following error message: Symbols not found: [ __emutls_v._ZSt15__once_callable, __emutls_v._ZSt11__once_call ] Those seem to correspond to std::__once_callable and std::__once_call, which are indeed present in the C++ stan...

Hey LLVM folks, I've run into an interesting assertion. In one of HardenedBSD's feature branches, we're working on integration llvm's Cross-DSO CFI implementation. Using Cross-DSO CFI requires building libs with LTO, which causes clang to emit LLVM IR intermediate object files rather than ELF intermediate object files. I've found that with lld, attempting to link LLVM IR intermediate object files hits an assert in lld. I've create...

...seeing. But I do know that at the start of the project they did evaluate using regular dynamic linking for the feature partitions, and that was quickly rejected in favour of other approaches due to the code size and maintenance overhead. And with control flow integrity the binary size of the cross-DSO metadata dwarfed the binary size savings that they were hoping to gain by splitting their program in two. Furthermore, there are things that you simply cannot do with a more conventional approach, such as optimizations relying on whole-program information (like whole-program devirtualization, whic...

https://bugzilla.mindrot.org/show_bug.cgi?id=1714 Summary: Avoid implicit DSO linking Product: Portable OpenSSH Version: 5.3p1 Platform: Other OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Build system AssignedTo: unassigned-bugs at mindrot.org ReportedBy...