Skip to content
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

Use common CLR_CMAKE_* variables in more places #31659

Merged
merged 5 commits into from
Feb 6, 2020
Merged

Use common CLR_CMAKE_* variables in more places #31659

merged 5 commits into from
Feb 6, 2020

Conversation

am11
Copy link
Member

@am11 am11 commented Feb 3, 2020

  • Use eng/native/configureplatform.cmake in libraries (coreclr and installer are already using it).
  • Extend PIE support introspection for C language (for libraries) and deduplicate code in src/libraries/Native/Unix/CMakeLists.txt.
  • Define CLR_CMAKE_{ARCH_}{HOST,TARGET}_ARMV71 and CLR_CMAKE_{HOST,TARGET}_ANDROID.
  • Replace CMAKE_SYSTEM_PROCESSOR and CMAKE_SYSTEM_NAME with already defined CLR_CMAKE_* counterparts.
  • Replace if(APPLE) and if(WIN32) with CLR_CMAKE_TARGET_DARWIN and CLR_CMAKE_TARGET_WIN32 respectively.

@jkotas jkotas requested a review from sdmaclea February 3, 2020 17:04
@sdmaclea
Copy link
Contributor

sdmaclea commented Feb 3, 2020

Replace if(APPLE) and if(WIN32) with CLR_CMAKE_TARGET_DARWIN and CLR_CMAKE_TARGET_WIN32 respectively.

In some places WIN32 is coupled to the HOST compiler not the target. If the CMAKE setting is affecting compiler settings, I was using HOST settings. So in CoreCLR I would expect (WIN32) to typically map to CLR_CMAKE_HOST_WIN32.

DARWIN. We are not consistent. In the coreclr native code we were using MAC64 and OSX. I just changed the MAC64 to use OSX. I wonder if OSX might be more recognizable than Darwin to non Mac people.

I haven't looked at the content of the PR yet... Since it is marked Draft...

@am11 am11 marked this pull request as ready for review February 3, 2020 22:57
@am11
Copy link
Member Author

am11 commented Feb 3, 2020

CLR_CMAKE_HOST_WIN32 is not defined in master or by the PR. However, replacing if(WIN32) with if(CLR_CMAKE_TARGET_WIN32) seems to be working. In my understanding, in most (if not all) cases on the consumer side, _TARGET_ is the correct choice over _HOST_; as host-to-target mapping (even for cross scenarios) is correctly done in common place: eng/native/configureplaform.cmake.

Darwin: the official (renewed) OS name is macOS, and base system for iOS, macOS, tvOS etc. is Darwin. CMake, uname, python, perl, node.js etc. on macOS return [Dd]arwin as system name, so our use of CLR_CMAKE_TARGET_DARWIN is not unordinary . There were two places in libraries using if(APPLE) which are replaced with if(CLR_CMAKE_TARGET_DARWIN).

OSX might be more recognizable than Darwin to non Mac people.

imo, System.Runtime.InteropServices.OSPlatform.OSX could be obsoleted in favor of Darwin and macOS, to reflect the vendor's preference and what uname, python etc. return on that platform, so the non-mac people don't get confused by obsolete names like osx in dotnet, and Darwin/macOS everywhere else. :)

Please note that PR only deals with the CLR cmake platform variables; the symbols/macros defined for the code have not changed by this PR; although with convergence in place, it is now easy to form a convention / bring about uniformity there as well (e.g. use _TARGET_X86 etc. in all three directories: coreclr, installer and libraries).


Failures look unrelated:

cc @janvorli, @jkotas

@am11
Copy link
Member Author

am11 commented Feb 3, 2020

e.g. use _TARGET_X86 etc. in all three directories: coreclr, installer and libraries

looks like it is already started: #31668 👍

Copy link
Contributor

@sdmaclea sdmaclea left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Before this change WIN32 was configured by the HOST compiler and platform. This change is switching it all to be controlled by TARGET platform.

In general the safer rename would be to introduce a CLR_CMAKE_HOST_WIN32 variable. Then use that for the WIN32 rename.

I reviewed the first several dozen files and there were some cases where your rename was correct and other where it was incorrect.

As I mentioned previously. The heuristic I have been using is that compiler setting/configuration should be tied to HOST. This includes things like MT, WIN32, WIN32_LEAN_AND_MEAN. It also includes choice of assembler and assembly language. It would also include references to HOST specific libraries. kernel32.lib ...

I would prefer either

  • Rename WIN32 to CLR_CMAKE_HOST_WIN32
  • Audit all uses of WIN32 and correctly select HOST or TARGET

We can open an issue to toggle CLR_CMAKE_HOST_WIN32 to CLR_CMAKE_TARGET_WIN32 as needed later if you chose the first option.

The review was getting repetitive and I don't think I was adding useful comments. So I stopped reviewing...

src/coreclr/CMakeLists.txt Outdated Show resolved Hide resolved
src/coreclr/CMakeLists.txt Outdated Show resolved Hide resolved
src/coreclr/CMakeLists.txt Outdated Show resolved Hide resolved
src/coreclr/CMakeLists.txt Outdated Show resolved Hide resolved
src/coreclr/CMakeLists.txt Outdated Show resolved Hide resolved
src/coreclr/src/debug/ildbsymlib/CMakeLists.txt Outdated Show resolved Hide resolved
src/coreclr/src/debug/shim/CMakeLists.txt Outdated Show resolved Hide resolved
src/coreclr/src/dlls/clretwrc/CMakeLists.txt Outdated Show resolved Hide resolved
src/coreclr/src/dlls/dbgshim/CMakeLists.txt Show resolved Hide resolved
src/coreclr/src/dlls/mscordbi/CMakeLists.txt Outdated Show resolved Hide resolved
@am11
Copy link
Member Author

am11 commented Feb 4, 2020

Thanks for your persistence, @sdmaclea! I went with preference no. 2. :)
Using your heuristic, fixed up various places where _HOST_ should be used instead of _TARGET_. In few places I had to hoist out compiler definition from set(sources) block into a separate if()-block.

@am11
Copy link
Member Author

am11 commented Feb 5, 2020

@jkotas, System.IO.FileSystem.Tests failure is another case of Internal CLR error. (0x80131506) (there were few reports in past), but none matching System.IO.FileSystem.Tests with this stack

  Starting:    System.IO.FileSystem.Tests (parallel test collections = on, max threads = 2)
    System.IO.Tests.DirectoryInfo_Create.RootPath_AppContainer [SKIP]
      Condition(s) not met: "IsInAppContainer"
    System.IO.Tests.DirectoryInfo_GetSetTimes.TimesIncludeMillisecondPart_HFS [SKIP]
      Condition(s) not met: "isHFS"
Fatal error. Internal CLR error. (0x80131506)
   at Xunit.DelegatingXmlCreationSink.CreateTestResultElement(Xunit.Abstractions.ITestResultMessage, System.String)
   at Xunit.DelegatingXmlCreationSink.HandleTestPassed(Xunit.MessageHandlerArgs`1<Xunit.Abstractions.ITestPassed>)
   at MessageSinkMessageExtensions.Dispatch[[System.__Canon, System.Private.CoreLib, Version=5.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e]](Xunit.Abstractions.IMessageSinkMessage, System.Collections.Generic.HashSet`1<System.String>, Xunit.MessageHandler`1<System.__Canon>)
   at Xunit.DelegatingXmlCreationSink.OnMessageWithTypes(Xunit.Abstractions.IMessageSinkMessage, System.Collections.Generic.HashSet`1<System.String>)
   at Xunit.DelegatingLongRunningTestDetectionSink.OnMessageWithTypes(Xunit.Abstractions.IMessageSinkMessage, System.Collections.Generic.HashSet`1<System.String>)
   at Xunit.MessageSinkAdapter.OnMessageWithTypes(Xunit.Abstractions.IMessageSinkMessage, System.Collections.Generic.HashSet`1<System.String>)
   at Xunit.OptimizedRemoteMessageSink.OnMessage(Xunit.Abstractions.IMessageSinkMessage)
   at Xunit.Sdk.MessageBus.DispatchMessages()
   at Xunit.Sdk.MessageBus.ReporterWorker()
   at Xunit.Sdk.XunitWorkerThread+<>c.<QueueUserWorkItem>b__5_0(System.Object)
   at System.Threading.Tasks.Task.InnerInvoke()
   at System.Threading.Tasks.Task+<>c.<.cctor>b__274_0(System.Object)
   at System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
   at System.Threading.Tasks.Task.ExecuteWithThreadLocal(System.Threading.Tasks.Task ByRef, System.Threading.Thread)
   at System.Threading.Tasks.Task.ExecuteEntryUnsafe(System.Threading.Thread)
   at System.Threading.Tasks.ThreadPoolTaskScheduler+<>c.<.cctor>b__10_0(System.Object)
   at System.Threading.ThreadHelper.ThreadStart_Context(System.Object)
   at System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
   at System.Threading.ThreadHelper.ThreadStart(System.Object)
----- end 04/02/2020 23:49:18,98 ----- exit code -1073741819 ----------------------------------------------------------

should I open an issue?

@jkotas
Copy link
Member

jkotas commented Feb 5, 2020

The crash is #31809

@am11
Copy link
Member Author

am11 commented Feb 5, 2020

There were few others crashing found in the history (since 01/26/2020) in Linux as well, so I have filed #31812.

Copy link
Contributor

@sdmaclea sdmaclea left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks much better. Thanks

There are a few places where the CLR_CMAKE_TARGET_ is used to select HOST specific libraries. These should be fixed. I stopped commenting on the issue after a while, but I did look through all the files.

Copy link
Contributor

@sdmaclea sdmaclea left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM Thanks.

@sdmaclea sdmaclea merged commit 34f316e into dotnet:master Feb 6, 2020
@am11 am11 deleted the feature/consolidations branch February 6, 2020 11:40
sdmaclea added a commit to sdmaclea/runtime that referenced this pull request Feb 7, 2020
Fix DAC cross OS compilations regressions introduced by dotnet#31659
sdmaclea added a commit that referenced this pull request Feb 7, 2020
Fix DAC cross OS compilations regressions introduced by #31659
@sdmaclea sdmaclea added this to In progress in Cross OS DAC enablement via automation Mar 12, 2020
@sdmaclea sdmaclea moved this from In progress to In Draft 3.1 Backport in Cross OS DAC enablement Mar 12, 2020
@sdmaclea sdmaclea moved this from In Draft 3.1 Backport to In progress in Cross OS DAC enablement Mar 12, 2020
@sdmaclea sdmaclea moved this from In progress to In Draft 3.1 Backport in Cross OS DAC enablement Mar 12, 2020
@ghost ghost locked as resolved and limited conversation to collaborators Dec 10, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
No open projects
Cross OS DAC enablement
  
In Draft 3.1 Backport
Development

Successfully merging this pull request may close these issues.

None yet

4 participants