Hi Rainer, All contributions to libsanitizer should go via LLVM repository. See https://code.google.com/p/address-sanitizer/wiki/HowToContribute The smaller the patches the faster they will come through. If you can set up a public build bot it will *immensely* simplify many things. (see more below)
On Fri, Jul 4, 2014 at 3:47 PM, Rainer Orth <r...@cebitec.uni-bielefeld.de> wrote: > Hi Alex, > >> The quick answer is no, although the expansion into GCC world may >> require such a guideline. >> We've initially implemented ASan on Linux and then ported it to >> Android (which is very similar to Linux) and Mac (which is very >> different), so we have little experience with porting yet. >> I've summarized the differences between Linux and Mac here: >> https://code.google.com/p/address-sanitizer/wiki/AddressSanitizerForMacImplementationDetails >> >> The core things to pay attention at are function wrapping (e.g. dlsym >> on Linux, mach_override on Mac), hooking the allocations/deallocations >> in the program, stack unwinding (already done for x86 and ARM), thread >> creation, early initialization, debug info and symbolization. Maybe >> something else. In fact if any of these points work on your platform >> differently than they do on Linux/Mac, you'll have to re-implement >> those. >> >> Regarding mach_override, it's a Mac OS-specific thing that we use >> because dlsym doesn't reliably override functions (keywords: two-level >> namespace) >> This only works on x86/x86_64 and is just a bunch of ad-hoc hacks to >> hot-patch the library code. >> Extending the instruction table in mach_override.c is irrelevant to >> porting, it's just a mean of making it work with some newer libraries >> provided by Apple. >> It won't work on any other OS (well, without some refactoring; in fact >> it's possible to use it on Linux) or any other arch (one could rewrite >> mach_override.c for ARM, but iOS doesn't allow code patching). >> >> I'm working on a replacement for mach_override, which will compile >> libasan as a dynamic library on Mac OS and preload it before running >> the program. >> It's not ready yet, so the easiest thing for GCC will be to add some >> more instructions to mach_override and stick to it for now. > > Thanks for those hints. After a first start at a Solaris port of > libsanitizer when it was first integrated into the GCC tree, I've now > made very good progress. > > I'm now down to just a few testsuite failures on Solaris 11.2 Beta: > > * g++, 32-bit: > > c-c++-common/asan/misalign-1.c > c-c++-common/asan/misalign-2.c > c-c++-common/asan/null-deref-1.c > c-c++-common/asan/swapcontext-test-1.c > g++.dg/asan/deep-tail-call-1.C > > * g++, 64-bit: > > c-c++-common/asan/global-overflow-1.c > c-c++-common/asan/heap-overflow-1.c > c-c++-common/asan/memcmp-1.c > c-c++-common/asan/misalign-1.c > c-c++-common/asan/misalign-2.c > c-c++-common/asan/null-deref-1.c > c-c++-common/asan/pr61530.c > c-c++-common/asan/rlimit-mmap-test-1.c > c-c++-common/asan/sanity-check-pure-c-1.c > c-c++-common/asan/sleep-before-dying-1.c > c-c++-common/asan/stack-overflow-1.c > c-c++-common/asan/strip-path-prefix-1.c > c-c++-common/asan/strlen-overflow-1.c > c-c++-common/asan/strncpy-overflow-1.c > c-c++-common/asan/swapcontext-test-1.c > c-c++-common/asan/use-after-free-1.c > c-c++-common/asan/use-after-return-1.c > g++.dg/asan/deep-stack-uaf-1.C > g++.dg/asan/deep-tail-call-1.C > g++.dg/asan/deep-thread-stack-1.C > g++.dg/asan/default-options-1.C > g++.dg/asan/interception-failure-test-1.C > g++.dg/asan/interception-test-1.C > g++.dg/asan/large-func-test-1.C > g++.dg/asan/pr55617.C > c-c++-common/ubsan/float-cast-overflow-2.c > c-c++-common/ubsan/float-cast-overflow-4.c > > * gcc, 32-bit: > > c-c++-common/asan/misalign-1.c > c-c++-common/asan/misalign-2.c > c-c++-common/asan/null-deref-1.c > c-c++-common/asan/swapcontext-test-1.c > > * gcc, 64-bit: > > c-c++-common/asan/global-overflow-1.c > c-c++-common/asan/heap-overflow-1.c > c-c++-common/asan/memcmp-1.c > c-c++-common/asan/misalign-1.c > c-c++-common/asan/misalign-2.c > c-c++-common/asan/null-deref-1.c > c-c++-common/asan/pr61530.c > c-c++-common/asan/rlimit-mmap-test-1.c > c-c++-common/asan/sanity-check-pure-c-1.c > c-c++-common/asan/sleep-before-dying-1.c > c-c++-common/asan/stack-overflow-1.c > c-c++-common/asan/strip-path-prefix-1.c > c-c++-common/asan/strlen-overflow-1.c > c-c++-common/asan/strncpy-overflow-1.c > c-c++-common/asan/swapcontext-test-1.c > c-c++-common/asan/use-after-free-1.c > c-c++-common/asan/use-after-return-1.c > gcc.dg/asan/nosanitize-and-inline.c > c-c++-common/ubsan/float-cast-overflow-2.c > c-c++-common/ubsan/float-cast-overflow-4.c > > That's not too bad, I believe, and the 64-bit failures seem to be mostly > due to a single error. > > The question is how best to proceed from here. I'm attaching the > current patch for reference, though it's far from ready for submission > (no ChangeLog, no explanations for the issues found, several hacks that > need cleaning up), but it certainly is a start. > > A few random observations about the port: > > * From a porting point, I find it nightmarish that libsanitizer is > completely platform-based (SANITIZER_<PLATFORM> all over the place) > rather than feature-based (HAVE_<XYX>, irrespective of how the > features are detected). I don't enjoy the current situation. Any help here is welcome, but testing any such change might be complicated, especially for platforms which don't have public buildbots :( > > * Even this is not consistent: many places use SANITIZER_<PLATFORM>, > others still __linux__/__FreeBSD__/... Again, patches are more than welcome to get rid of __linux__/__FreeBSD__/... --kcc > > * I couldn't find any explanation on the semantics and requirements of > some of the runtime functions, like GetEnv and especially > BlockingMutex. Porting is mostly guesswork here, looking at other > ports and hoping that what you infer from them is right. > > Please note that I'll be moving to a new flat next week, so I will be > busy with other stuff for some time. I just wanted to get this out of > the door for comments and suggestions. > > Rainer > > > > > -- > ----------------------------------------------------------------------------- > Rainer Orth, Center for Biotechnology, Bielefeld University >
