Add MacOs support

[GoogleCodeExporter]

Add support for taget:  'x86_64-apple-darwin14.1.0'

Original issue reported on code.google.com by gonzalob...@gmail.com on 9 Feb 2015 at 4:52

[GoogleCodeExporter]

We are not planing any work here.
MSan is usable only if *all* the code is instrumented.
On Mac this is impossible except for really tiny programs. 

I am closing this bug because it is not actionable, not because we don't want 
this to happen. If you know how to proceed and are ready to help -- please 
reopen. 

Original comment by konstant...@gmail.com on 24 Feb 2015 at 1:53

• Changed state: WontFix

[GoogleCodeExporter]

How is this not the case under Linux?
Don't you have to recompile all the code above libc with msan?
That is as easy to do under linux as it is under MacOS.

Original comment by gonzalob...@gmail.com on 24 Feb 2015 at 2:30

[GoogleCodeExporter]

I've heard that MacOS has a number of proprietary "frameworks" that must be 
used by any GUI application.

Original comment by euge...@google.com on 24 Feb 2015 at 2:34

[GoogleCodeExporter]

be used by any GUI application.

Might be, but nor did I ask support for MacOS GUI frameworks, nor this
would be the right place to ask for that.

I asked for support for the 'x86_64-apple-darwin14.1.0' target.

The documentation says that the memory sanitizer provides libc wrappers.
However, using clang tip-of-trunk under MacOS with -fsanitize=memroy fails
to compile the following C++ program:

int main() { return 0; }

The error is just: target 'x86_64-apple-darwin14.1.0'  is not supported.

I would like to be able to compile:

#include <stdio.h>
int main() { puts("Hello World!"); }

Since that would mean the libc wrapper works, and that I can compile
non-trivial non-tiny applications like llvm/clang from source using the
memory sanitizer.

Original comment by gonzalob...@gmail.com on 24 Feb 2015 at 3:47

[GoogleCodeExporter]

Right, of course. LLVM/Clang is doable on Mac.
Still, that's a non-trivial amount of work that we don't have free cycles for.
It would require, at a minimum:
(1) figuring out shadow/origin mapping compatible with MacOS process memory 
layout
(2) tweaking the runtime library for libc differencies

Patches are welcome.

Original comment by euge...@google.com on 25 Feb 2015 at 9:39

[GoogleCodeExporter]

Thanks, for the TODO list.

I cannot contribute patches but it would be helpful if the issue would stay
open in case someone wants to contribute to the memory sanitizer. I think a
lot of people could benefit from this.

Maybe one could get apple interested (e.g. Chris Lattner?) in the next
meetups.

Original comment by gonzalob...@gmail.com on 25 Feb 2015 at 9:53

[GoogleCodeExporter]

Original comment by euge...@google.com on 25 Feb 2015 at 9:56

• Changed state: Accepted
• Added labels: Priority-Low
• Removed labels: Priority-Medium

[GoogleCodeExporter]

As Eugeniy said, enabling msan for Mac only for 'hello world' apps will not 
solve any problem for us, but will require non-trivial effort.

I don't mind keeping this bug open, but we really need support from Apple here. 
Would you like to file a bug against Apple to request msan support?

Original comment by konstant...@gmail.com on 25 Feb 2015 at 10:04

[GoogleCodeExporter]

not
solve any problem for us, but will require non-trivial effort.

Sorry to hear that. I think that for any graphical application, even if you
use XQuartz as an X replacement directly, you will have to, at some point,
interface with Apple's libraries. So without wrappers provided by Apple
that won't work. There is still, however, a lot of useful complex software
(without GUI) that could use `msan` on MacOS.

Yes I can do that.

Original comment by gonzalob...@gmail.com on 25 Feb 2015 at 11:07

[GoogleCodeExporter]

Adding Project:MemorySanitizer as part of GitHub migration.

Original comment by gli...@google.com on 30 Jul 2015 at 9:22

• Added labels: ProjectMemorySanitizer