I've responded to the bug. Sorry for offtopics unrelated to your original patch.
On Wed, Nov 14, 2012 at 8:11 PM, Jack Howarth <howa...@bromo.med.uc.edu> wrote: > On Wed, Nov 14, 2012 at 07:56:18PM +0400, Alexander Potapenko wrote: >> Hi Rainer, >> >> 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. > > Alex, > Please see... > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55289#c27 > > So far for all the test cases that I have looked at, the problem > seems to be when mach_overrride.c hits the opcodes... > > 48 8d 5 > > Can you suggest a patch for that one? It may be the only blocker to > asan support on darwin (for x86_64 anyway). > Jack > >> >> Alex >> >> On Wed, Nov 14, 2012 at 7:08 PM, Rainer Orth >> <r...@cebitec.uni-bielefeld.de> wrote: >> > Hi Alex, >> > >> >> most certainly the functionality of asan is not intact. >> >> The error messages denote that mach_override couldn't parse some of >> >> the function prologues, which means some of ASan interceptors just >> >> won't work. >> >> In order to fix this you need to change the DEBUG definition in >> >> mach_override.c, look at the bytes being parsed and fix the >> >> instruction table in mach_override.c >> > >> > is there some guideline how to port asan to a new OS or CPU? That would >> > certainly be easier than figuring things out on your own one by one. I >> > guess several target and os port maintainers would want to do so in GCC. >> > >> > Thanks. >> > Rainer >> > >> > -- >> > ----------------------------------------------------------------------------- >> > Rainer Orth, Center for Biotechnology, Bielefeld University >> >> >> >> -- >> Alexander Potapenko >> Software Engineer >> Google Moscow -- Alexander Potapenko Software Engineer Google Moscow