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
thanks, that's certainly helpful. I'm primarily interested in porting
to Solaris, both SPARC and x86. Several things should be similar to
Linux (both being ELF systems), while other areas are certainly
different (syscalls implementation etc.).
> 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.
I'll certainly be looking around. One problem I see with the current
code organization is duplication between different platforms:
e.g. considerable parts of sanitizer_mac.cc and a new
sanitizer_solaris.cc are identical. Perhaps we need more granularity in
the future, but that can be decided once an initial port (with
duplication to avoid treading on other port's feet) is done. At the
same time, we should add infrastructure (like libffi) to only compile
target-specific code on the relevant platforms, instead of wrapping
every source file in #ifdef __linux__ or similar and extending the
conditionals once a new platform is added.
> 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.
This hopefully won't be an issue on Solaris where dlsym should work the
same as on Linux.
Thanks.
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University
