Giters

microsoft / CLRInstrumentationEngine

The CLR Instrumentation Engine is a cooperation profiler that allows running multiple profiling extensions in the same process.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Add support for macOS

jakubch1 opened this issue · comments

commented

To support dynamic code coverage on macOS we need nuget with CLR IE macOS binaries.

I was trying to build CLR IE on macOS but it looks like it's not so easy. I was trying to build it with clang 11. I saw some issues with stringstream but after commenting out some stringstream usages I was able to reach linking. Linking is failing with such issues:

ld: warning: ignoring file ../unix/src/liblinux_pal.a, building for macOS-x86_64 but attempting to link with file built for macOS-x86_64
ld: warning: ignoring file ../unix/src/atl/libatl.a, building for macOS-x86_64 but attempting to link with file built for macOS-x86_64
ld: warning: ignoring file ../InstrumentationEngine.Api/libInstrumentationEngine.Api.a, building for macOS-x86_64 but attempting to link with file built for unknown-unsupported file format ( 0x21 0x3C 0x61 0x72 0x63 0x68 0x3E 0x0A 0x2F 0x20 0x20 0x20 0x20 0x20 0x20 0x20 )
ld: warning: ignoring file ../InstrumentationEngine.Lib/libInstrumentationEngine.Lib.a, building for macOS-x86_64 but attempting to link with file built for unknown-unsupported file format ( 0x21 0x3C 0x61 0x72 0x63 0x68 0x3E 0x0A 0x2F 0x20 0x20 0x20 0x20 0x20 0x20 0x20 )

There are also issues with objcopy in macOS. I've tried 2 versions llvm-objcopy from llvm 11, and gobjcopy from binutils package. In both cases during linking there were issues and redefined library was ignored.

All my changes you can find on branch: https://github.com/jakubch1/CLRInstrumentationEngine/tree/dev/jachocho/macos

commented

cc @gregg-miskelly Who may be able to help with this specific issue.

  • Building for macOS is not something we have ever tried, or have resources to work on ourselves at the moment. We can try to help with any efforts here on your part, but this seems like a substantial feature rather than a small change.
  • In addition to code changes, there needs to be a new PR/CI build for macOS.
  • The pal should cross compile to macOS, but CLRIE itself may have code that doesn't work on macOS.
  • We found that the version of pal we are using doesn't compile properly with newer versions of clang. On Linux, we compile with clang 3.x.
commented

FYI It looks like the right stuff is happening with the CoreCLR PAL already (see here). Though obviously that code has never been tested. So maybe that is wrong.

From a quick browsing of the code, its not obvious to me why the various .a's are getting platform mismatches. I do see a few places where code is explicitly linking against .so's, which could be the problem (example). It is at least a problem.

At any rate, the only tweak I would make it so say that I don't know how much effort this would take. So if your team is willing to fund the effort, go for it. From the past I have generally seen after Windows C++ code is ported to Linux, it often fairly easy to port it to macOS. But of course that statement isn't always true. I don't think there is a good way of guessing a cost without trying it.