Refactor libunwind to work on osx#284
Conversation
Addressing comments
In the same vein as "COR" and "URT", the terms "COM+"/"COMPLUS" appear frequently throughout the codebase, most notably in config settings (e.g. "COMPLUS_DefaultVersion"). I couldn't find any other explanation for what this means, and since I remember learning about it myself by asking older members of the team, I thought it would be helpful to have this documented for newcomers to the codebase.
Add definition of "COMPLUS" to the glossary
Correctly locate Clang [Fixes 250]
Fix wrong flag to rm when deleting intermediates folder.
Update the CoreCLR nuspec to deploy the files under the aspnetcore5 folder
Any managed code that touches the ThreadPool is currently crashing when the ThreadPool tries to initialize. This is due to it creating a semaphore via CreateSemaphoreExA/W in the pal, and those functions not being implemented. This commit just implements those functions by delegating to their non-Ex counterparts. With this change, ThreadPool.QueueUserWorkItem, Task.Run, etc. are able to successfully schedule work and have it executed.
The current PAL has binary check-ins of the config.h for Linux and MAC, long term this is not sustainable. This is a first pass at cleaning this up. Please note, there are some static platform independent defines as I tried to keep consistency with the current outputs of the not-checked-in configure.in. As we clean up the PAL the CMakeLists should be revisited and redundant pieces removed.
Implement CreateSemaphoreExA/W via CreateSemaphoreA/W
Simplify platform ifdefs like #if defined(_WIN64) || defined(_TARGET_ARM_) to #if !defined(_TARGET_X86_) based on @BruceForstall suggestion
When building debug, author the development package with an appropriate name
[tfs-changeset: 1415470]
Merge changes from TFS
Refactor the PAL build configuration to detect at configure time
Simplify platform ifdefs
[tfs-changeset: 1415626]
di can be built, but still cannot be linked.
Merge changes from TFS
This commit removes a bunch of dead checks in the configure stage, as well as fixing inconsistencies in HAVE_FTRUNCATE_LENGTH_ISSUE/HAVE_FTRUNCATE_LENGTH_BUG off_t in file.cpp was declared after the goto, making it a protected scope, so it needed to be moved up.
Add authors to code guide
761d9f5 to
1fa9f00
Compare
|
@janvorli We've had some back and forth on this. Want me to rebase and squash it down? |
|
@kangaroo Yes please, that would be nice. |
libunwind on linux exposes the unw_context_t directly as a ucontext_t, but on OSX its an opaque data structure. Additionally UNW_REG_SP is read/write on OSX, but read-only on Linux. As such we need to diverge the libunwind code a bit depending on what flavor we are running on. There is one OSXTODO around the context pointers, since we do not have unw_get_save_loc on OSX.
115dd5e to
551c976
Compare
|
Rebased into 551c976 |
|
LGTM |
|
@kangaroo Thank you very much for making it work on OSX! |
|
@janvorli No problem. Do we need 2 core members to sign this PR? Since its not targeting master (I submitted this against your branch), should we merge into there and continue review there? |
Conflicts: src/pal/src/config.h.linux src/pal/src/config.h.osx src/pal/src/exception/seh-unwind.cpp
|
I think we should merge right away and then I should reflect the feedback I got on my changes from @jkotas. But we'll have a cross platform weekly meeting in a minute, so I'll double check thatin there and will merge right after. |
|
Alright, I'm rebasing the branch onto master currently anyways, so if that passes tests I'll push that up to this branch as a separate commit as well. |
|
Build failure seems unrelated, something is flapping on windows. |
|
@dotnet-bot test this please |
|
@mmitche There is something strange going on with the windows build. It fails with |
|
taking a look now |
|
@kangaroo The failure doesn't appear on master on one of those machines that failed, so I don't think it's a machine issue. I'm checking the feature branch now. |
|
@dotnet-bot test this please I've been unable to reproduce the failure on that machine...attempting to get some more data now. |
|
@mmitche It was failing on DEBUG before, now RELEASE, and my patch doesn't touch windows. It seems to be flapping for some reason. |
|
@kangaroo Your patch does touch a few of the build files, probably from merges, so it's a possibility that that's related somehow. But when I checked out your branch I got none of those failures.. |
|
@dotnet-bot test this please |
|
@mmitche yeah thats from the master rebase |
|
And now it passed :) |
Refactor libunwind to work on osx
Initial pass at OS X support.
It still unwinds on linux. It doesn't succeed on OS X yet, but its not failing to compile/crashing anymore.
Test:
Linux:
Mac: