chandlerc added inline comments.
================ Comment at: clang/lib/CodeGen/BackendUtil.cpp:1231-1232 + MPM.addPass(ModuleSanitizerCoveragePass(SancovOpts)); + MPM.addPass( + createModuleToFunctionPassAdaptor(SanitizerCoveragePass(SancovOpts))); + } ---------------- leonardchan wrote: > chandlerc wrote: > > Is there an existing function pass pipeline we can put this in, maybe by > > using an extension point? That would make it much faster to run I suspect. > I tried this earlier, but when I use `registerOptimizerLastEPCallback()` > before the default module pipeline is made, I end up getting this linker > error for `-O2` runs: > > ``` > fuzzer.c:(.text.sancov.module_ctor_8bit_counters[sancov.module_ctor_8bit_counters]+0x11): > undefined reference to `__start___sancov_pcs' > fuzzer.c:(.text.sancov.module_ctor_8bit_counters[sancov.module_ctor_8bit_counters]+0x16): > undefined reference to `__stop___sancov_pcs' > ``` > > I don't understand how I get this because the symbols are declared in the IR > dump as: > > ``` > @__start___sancov_pcs = external hidden global i64* > @__stop___sancov_pcs = external hidden global i64* > ``` > > for both the optimized cases if I use the adaptor or EP. I'm still linking > with the same compiler-rt in each case. > > The only difference I think of using the adaptor after > `buildPerModuleDefaultPipeline()` vs using the extension point callback > before is that the order in which the pass will be called changes, although I > still don't see how it could lead to this undefined reference if I still link > against compiler-rt. > > Additionally, the only difference between the IR between using the adaptor vs > the EP is a few extra globals/declarations seem to be missing when using the > EP, which makes me think another pass that ran after this one removed them, > although these don't seem to be related to the error. > Hmm... Maybe those missing globals / declarations are relevant. Maybe they are necessary to get the linking against the sancov runtime to work correctly? You could try adding these globals / declarations to the 'used' set so they don't get removed by later passes: https://llvm.org/docs/LangRef.html#the-llvm-compiler-used-global-variable Otherwise, I have no idea, maybe makes sense to loop in the sanitizer folks explicitly for help debugging this... ================ Comment at: llvm/lib/Passes/PassRegistry.def:248 FUNCTION_PASS("tsan", ThreadSanitizerPass()) +FUNCTION_PASS("sancov-func", SanitizerCoveragePass()) #undef FUNCTION_PASS ---------------- leonardchan wrote: > chandlerc wrote: > > Consistency would suggest just `sancov` here? I don't feel strongly though. > Ah, so the reason why I don't use `sancov` here is because in the tests when > using `-passes='function(sancov)', I get the following error: > > ``` > /usr/local/google/home/leonardchan/llvm-monorepo/llvm-build-3-b133876586/bin/opt: > unknown function pass > '/usr/local/google/home/leonardchan/llvm-monorepo/llvm-build-3-b133876586/bin/sancov' > ``` > > I think this is because lit tries to substitute `sancov` with the one under > `bin/sancov` in my build dir. I'd be up for changing it if there's a way > around this. That's... really entertaining. I suspect the tool should really be `llvm-sancov` to avoid this kind of thing. But anyways, i'm OK with this or calling it something else. There is probably a way to hide a thing from `lit`'s substitution as well, I just don't know what it is.... Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D62888/new/ https://reviews.llvm.org/D62888 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
