-
Notifications
You must be signed in to change notification settings - Fork 571
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
port to Mac OS X #58
Comments
From bruen...@google.com on July 09, 2012 04:57:23 Note that I now have access to a Mac and I started toying with this Status: Started |
From bruen...@google.com on April 14, 2013 19:54:28 I had a tree from a while back that is now committed, along with some recent work in r2056 , r2059 , r2060 , r2061 , r2062 , r2063 . Still quite early though: haven't even gotten to the bulk of the os-specific parts of the code, but I have a plan for how to solve many of the issues. Probably I will use libSystem's mach wrappers initially as they are pretty bare and we can replace w/ raw syscalls in the future. |
From bruen...@google.com on February 24, 2014 12:14:04 I have put a lot of work into this and can now run small single-threaded apps that do not use signals on both Lion and Mavericks. If I get a chance I will put a summary of the noteworthy issues here. A number of the more recent issues have been filed separately, but a lot of the core things are still under this issue. |
64-bit support has a major roadblock in #1568 as there is no simple TLS solution |
Not much progress on macOS 64bit. |
A subset of the 32-bit test suite (51 tests) works on MacOSX today. You can see it on our Travis runs: https://travis-ci.org/DynamoRIO/dynamorio/jobs/179528229. Basic signals and threads do work today but we will not be surprised if larger apps (e.g., big commercial packages) do not work. We also have Dr. Memory running, again on small programs. The biggest problem for tools and the limiting factor for Dr. Memory is the lack of a private loader (#1285) which means there is not proper resource isolation today: this is the reason we do not advertise the Mac port of DR very much and do not even provide a binary package, while we do provide a DrM package. For 64-bit the blocking issue is as mentioned above: #1568. Unfortunately there is no public write-up in either the DR or DrM wikis but I have substantial notes and if publishing them will facilitate contributors I can try to make them accessible. |
I think it would be awesome if notes on the DR codebase were shared in whatever imperfect form in the Wiki -- both notes relevant to macOS and the project in general. They could be titled "Getting started on the DynamoRIO codebase" (or similar). Some open source projects tend to have these resources as a way of on-boarding would be contributors and they are definitely useful. DynamoRIO has an abundance of research publications and a nicely written thesis about it -- this is already a great resource -- now just some code guidance would be great! |
@derekbruening It looks like a comprehensive and awesome presentation. Sadly I was not able to understand many slides as there was no audio/video. Might audio/video be available for this? If not, are there any presentations you're going to give in the near future on this slide set that could be recorded? |
There will be a CGO tutorial in early Feb 2017. |
Please request a video recording of the CGO tutorial! |
To get links to the commits: 2013-04-14 e61c6e2 i#58 MacOS: first steps toward building on MacOS |
From derek.br...@gmail.com on February 26, 2009 12:58:15
container issue for general task of porting to Mac OS X
we should expand our feature-based *NIX support: HAVE_PROC_MAPS, etc., to
make further ports (e.g., to BSD) and support of wider range of Linux
distros easier
for /proc/maps, should investigate vm_region()
Original issue: http://code.google.com/p/dynamorio/issues/detail?id=58
The text was updated successfully, but these errors were encountered: