Re: [PATCH][Revised] Enable libsanitizer on darwin

[Alexander Potapenko <glider at google dot com>]

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 <howarth@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
>> <ro@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