Add MacOs support

[ramosian-glider]

Originally reported on Google Code with ID 85

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

Reported by gonzalobg88 on 2015-02-09 16:52:55

[ramosian-glider]

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. 

Reported by konstantin.s.serebryany on 2015-02-24 01:53:06

• Status changed: WontFix

[ramosian-glider]

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.

Reported by gonzalobg88 on 2015-02-24 14:30:51

[ramosian-glider]

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

Reported by eugenis@google.com on 2015-02-24 14:34:03

[ramosian-glider]

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.

Reported by gonzalobg88 on 2015-02-24 15:47:00

[ramosian-glider]

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.

Reported by eugenis@google.com on 2015-02-25 09:39:25

[ramosian-glider]

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.

Reported by gonzalobg88 on 2015-02-25 09:53:22

[ramosian-glider]

Reported by eugenis@google.com on 2015-02-25 09:56:05

• Status changed: Accepted
• Labels added: Priority-Low
• Labels removed: Priority-Medium

[ramosian-glider]

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?

Reported by konstantin.s.serebryany on 2015-02-25 22:04:38

[ramosian-glider]

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.

Reported by gonzalobg88 on 2015-02-25 23:07:18

[ramosian-glider]

Adding Project:MemorySanitizer as part of GitHub migration.

Reported by glider@google.com on 2015-07-30 09:22:27

• Labels added: ProjectMemorySanitizer