Skip to content

Fix x64 crossbuild on macOS arm64 - #91413

Merged
jkotas merged 2 commits into
dotnet:mainfrom
janvorli:fix-macos-crossbuild
Sep 6, 2023
Merged

Fix x64 crossbuild on macOS arm64#91413
jkotas merged 2 commits into
dotnet:mainfrom
janvorli:fix-macos-crossbuild

Conversation

@janvorli

Copy link
Copy Markdown
Member

The cross build is failing due to the cpufeatures.c being compiled in. This file tries to extract cpu features using cpuid / getauxval that don't make sense to execute in the cross tools.

This change disables compiling the cpufeatures.c for cross build and changes the JitGetProcessorFeatures to return zero in this case.

@janvorlijanvorli added this to the 9.0.0 milestone Aug 31, 2023
@janvorlijanvorli self-assigned this Aug 31, 2023
@ghost

Copy link
Copy Markdown

Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas
See info in area-owners.md if you want to be subscribed.

Issue Details

The cross build is failing due to the cpufeatures.c being compiled in. This file tries to extract cpu features using cpuid / getauxval that don't make sense to execute in the cross tools.

This change disables compiling the cpufeatures.c for cross build and changes the JitGetProcessorFeatures to return zero in this case.

Author:janvorli
Assignees:janvorli
Labels:

area-NativeAOT-coreclr

Milestone:9.0.0

@jkotas

Copy link
Copy Markdown
Member

jitinterface should not have any target specific code. Why are we cross-compiling it with TARGET != HOST in the first place?

@janvorli

Copy link
Copy Markdown
MemberAuthor

Why are we cross-compiling it with TARGET != HOST in the first place?

It compiles that when building libjitinterface_arm64.dylib during cross components build.

@MichalStrehovsky

Copy link
Copy Markdown
Member

Isn't the problem more that cpufeatures.h/.c uses TARGET_ ifdefs, but it should use HOST_?

ILC/crossgen2 (that use this) are both crosscompilers. They already know not to call into this logic when TARGET != HOST. I would expect x64 version of crossgen2 that we built on arm64 to be able to detect CPU features on x64.

@janvorli

Copy link
Copy Markdown
MemberAuthor

Isn't the problem more that cpufeatures.h/.c uses TARGET_ ifdefs, but it should use HOST_?

The host doesn't help here. That was actually my first thought too. Extracting the features when TARGET != HOST doesn't seem to make sense. Say we have JIT targeting arm64 running on x64. Extracting x64 features is useless for the JIT isn't it? And vice versa.

@MichalStrehovsky

Copy link
Copy Markdown
Member

Isn't the problem more that cpufeatures.h/.c uses TARGET_ ifdefs, but it should use HOST_?

The host doesn't help here. That was actually my first thought too. Extracting the features when TARGET != HOST doesn't seem to make sense. Say we have JIT targeting arm64 running on x64. Extracting x64 features is useless for the JIT isn't it? And vice versa.

ILC/crossgen is a crosscompiler and what we're building is still a crosscompiler - one can just pass --targetarch:XYZ to the built ILC/crossgen and it will do the right thing (error out if --instruction-set:native was specified but hostarch!=targetarch, or call into this API to find the right flags if hostarch==targetarch).

@jkotas

Copy link
Copy Markdown
Member

jitinterface*.dll build should be only parametrized by the host architecture. If we are building it with HOST!=TARGET for some reason, the binary should not be affected by the TARGET in any way.

This is different for the clrjit itself. clrjit build is parametrized by both the host architecture and the target architecture.

The cross build is failing due to the cpufeatures.c being compiled in.
This file tries to extract cpu features using cpuid / getauxval that
don't make sense to execute in the cross tools.
This change disables compiling the cpufeatures.c for cross build and
changes the `JitGetProcessorFeatures` to return zero in this case.
@jkotas

Copy link
Copy Markdown
Member

Conflicts...

@janvorli

Copy link
Copy Markdown
MemberAuthor

Resolved

@jkotasjkotas left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Thanks

@jkotas

Copy link
Copy Markdown
Member

Backport candidate?

@janvorli

Copy link
Copy Markdown
MemberAuthor

/backport to release/8.0

@github-actions

Copy link
Copy Markdown
Contributor

Started backporting to release/8.0: https://github.com/dotnet/runtime/actions/runs/6051186149

@github-actions

Copy link
Copy Markdown
Contributor

@janvorli backporting to release/8.0 failed, the patch most likely resulted in conflicts:

$ git am --3way --ignore-whitespace --keep-non-patch changes.patch
Applying: Fix x64 crossbuild on macOS arm64
Applying: Reflect PR feedback
Using index info to reconstruct a base tree...
M	src/native/minipal/cpufeatures.c
M	src/native/minipal/cpufeatures.h
Falling back to patching base and 3-way merge...
Auto-merging src/native/minipal/cpufeatures.h
Auto-merging src/native/minipal/cpufeatures.c
CONFLICT (content): Merge conflict in src/native/minipal/cpufeatures.c
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0002 Reflect PR feedback
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".
Error: The process '/usr/bin/git' failed with exit code 128

Please backport manually!

@github-actions

Copy link
Copy Markdown
Contributor

@janvorli an error occurred while backporting to release/8.0, please check the run log for details!

Error: git am failed, most likely due to a merge conflict.

Sign up for freeto subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants

@janvorli@jkotas@MichalStrehovsky
, 'i'); if (__m === '*' || __re.test(location.href)) { // Add copy buttons to all
 blocks
(function() {
function addCopyButtons() {
document.querySelectorAll('pre code').forEach(function(codeBlock) {
if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;
codeBlock.parentElement.setAttribute('data-copy-added', 'true');
var btn = document.createElement('button');
btn.textContent = 'Copy';
btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';
btn.onmouseover = function() { this.style.opacity = '1'; };
btn.onmouseout = function() { this.style.opacity = '0.7'; };
btn.onclick = function() {
navigator.clipboard.writeText(codeBlock.textContent).then(function() {
btn.textContent = 'Copied!';
setTimeout(function() { btn.textContent = 'Copy'; }, 1500);
});
};
codeBlock.parentElement.style.position = 'relative';
codeBlock.parentElement.appendChild(btn);
});
}
addCopyButtons();
// Re-run on dynamic content
var observer = new MutationObserver(addCopyButtons);
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '
Fix x64 crossbuild on macOS arm64 by janvorli · Pull Request #91413 · dotnet/runtime · GitHub
Skip to content

Fix x64 crossbuild on macOS arm64 - #91413

Merged
jkotas merged 2 commits into
dotnet:mainfrom
janvorli:fix-macos-crossbuild
Sep 6, 2023
Merged

Fix x64 crossbuild on macOS arm64#91413
jkotas merged 2 commits into
dotnet:mainfrom
janvorli:fix-macos-crossbuild

Conversation

@janvorli

Copy link
Copy Markdown
Member

The cross build is failing due to the cpufeatures.c being compiled in. This file tries to extract cpu features using cpuid / getauxval that don't make sense to execute in the cross tools.

This change disables compiling the cpufeatures.c for cross build and changes the JitGetProcessorFeatures to return zero in this case.

@janvorlijanvorli added this to the 9.0.0 milestone Aug 31, 2023
@janvorlijanvorli self-assigned this Aug 31, 2023
@ghost

Copy link
Copy Markdown

Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas
See info in area-owners.md if you want to be subscribed.

Issue Details

The cross build is failing due to the cpufeatures.c being compiled in. This file tries to extract cpu features using cpuid / getauxval that don't make sense to execute in the cross tools.

This change disables compiling the cpufeatures.c for cross build and changes the JitGetProcessorFeatures to return zero in this case.

Author:janvorli
Assignees:janvorli
Labels:

area-NativeAOT-coreclr

Milestone:9.0.0

@jkotas

Copy link
Copy Markdown
Member

jitinterface should not have any target specific code. Why are we cross-compiling it with TARGET != HOST in the first place?

@janvorli

Copy link
Copy Markdown
MemberAuthor

Why are we cross-compiling it with TARGET != HOST in the first place?

It compiles that when building libjitinterface_arm64.dylib during cross components build.

@MichalStrehovsky

Copy link
Copy Markdown
Member

Isn't the problem more that cpufeatures.h/.c uses TARGET_ ifdefs, but it should use HOST_?

ILC/crossgen2 (that use this) are both crosscompilers. They already know not to call into this logic when TARGET != HOST. I would expect x64 version of crossgen2 that we built on arm64 to be able to detect CPU features on x64.

@janvorli

Copy link
Copy Markdown
MemberAuthor

Isn't the problem more that cpufeatures.h/.c uses TARGET_ ifdefs, but it should use HOST_?

The host doesn't help here. That was actually my first thought too. Extracting the features when TARGET != HOST doesn't seem to make sense. Say we have JIT targeting arm64 running on x64. Extracting x64 features is useless for the JIT isn't it? And vice versa.

@MichalStrehovsky

Copy link
Copy Markdown
Member

Isn't the problem more that cpufeatures.h/.c uses TARGET_ ifdefs, but it should use HOST_?

The host doesn't help here. That was actually my first thought too. Extracting the features when TARGET != HOST doesn't seem to make sense. Say we have JIT targeting arm64 running on x64. Extracting x64 features is useless for the JIT isn't it? And vice versa.

ILC/crossgen is a crosscompiler and what we're building is still a crosscompiler - one can just pass --targetarch:XYZ to the built ILC/crossgen and it will do the right thing (error out if --instruction-set:native was specified but hostarch!=targetarch, or call into this API to find the right flags if hostarch==targetarch).

@jkotas

Copy link
Copy Markdown
Member

jitinterface*.dll build should be only parametrized by the host architecture. If we are building it with HOST!=TARGET for some reason, the binary should not be affected by the TARGET in any way.

This is different for the clrjit itself. clrjit build is parametrized by both the host architecture and the target architecture.

The cross build is failing due to the cpufeatures.c being compiled in.
This file tries to extract cpu features using cpuid / getauxval that
don't make sense to execute in the cross tools.
This change disables compiling the cpufeatures.c for cross build and
changes the `JitGetProcessorFeatures` to return zero in this case.
@jkotas

Copy link
Copy Markdown
Member

Conflicts...

@janvorli

Copy link
Copy Markdown
MemberAuthor

Resolved

@jkotasjkotas left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Thanks

@jkotas

Copy link
Copy Markdown
Member

Backport candidate?

@janvorli

Copy link
Copy Markdown
MemberAuthor

/backport to release/8.0

@github-actions

Copy link
Copy Markdown
Contributor

Started backporting to release/8.0: https://github.com/dotnet/runtime/actions/runs/6051186149

@github-actions

Copy link
Copy Markdown
Contributor

@janvorli backporting to release/8.0 failed, the patch most likely resulted in conflicts:

$ git am --3way --ignore-whitespace --keep-non-patch changes.patch
Applying: Fix x64 crossbuild on macOS arm64
Applying: Reflect PR feedback
Using index info to reconstruct a base tree...
M	src/native/minipal/cpufeatures.c
M	src/native/minipal/cpufeatures.h
Falling back to patching base and 3-way merge...
Auto-merging src/native/minipal/cpufeatures.h
Auto-merging src/native/minipal/cpufeatures.c
CONFLICT (content): Merge conflict in src/native/minipal/cpufeatures.c
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0002 Reflect PR feedback
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".
Error: The process '/usr/bin/git' failed with exit code 128

Please backport manually!

@github-actions

Copy link
Copy Markdown
Contributor

@janvorli an error occurred while backporting to release/8.0, please check the run log for details!

Error: git am failed, most likely due to a merge conflict.

Sign up for freeto subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants

@janvorli@jkotas@MichalStrehovsky
, 'i'); if (__m === '*' || __re.test(location.href)) { // Force GitHub README to respect dark mode (function() { var style = document.createElement('style'); style.textContent = ' .markdown-body { color-scheme: dark light; } .markdown-body pre { background: #161b22 !important; } .markdown-body code { background: rgba(110, 118, 129, 0.4) !important; } .markdown-body table th, .markdown-body table td { border-color: #30363d !important; } .markdown-body img { background: #0d1117; } .markdown-body blockquote { border-left-color: #8b949e; } .markdown-body hr { border-color: #30363d; } '; document.head.appendChild(style); })(); } } catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + ' Fix x64 crossbuild on macOS arm64 by janvorli · Pull Request #91413 · dotnet/runtime · GitHub
Skip to content

Fix x64 crossbuild on macOS arm64 - #91413

Merged
jkotas merged 2 commits into
dotnet:mainfrom
janvorli:fix-macos-crossbuild
Sep 6, 2023
Merged

Fix x64 crossbuild on macOS arm64#91413
jkotas merged 2 commits into
dotnet:mainfrom
janvorli:fix-macos-crossbuild

Conversation

@janvorli

Copy link
Copy Markdown
Member

The cross build is failing due to the cpufeatures.c being compiled in. This file tries to extract cpu features using cpuid / getauxval that don't make sense to execute in the cross tools.

This change disables compiling the cpufeatures.c for cross build and changes the JitGetProcessorFeatures to return zero in this case.

@janvorlijanvorli added this to the 9.0.0 milestone Aug 31, 2023
@janvorlijanvorli self-assigned this Aug 31, 2023
@ghost

Copy link
Copy Markdown

Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas
See info in area-owners.md if you want to be subscribed.

Issue Details

The cross build is failing due to the cpufeatures.c being compiled in. This file tries to extract cpu features using cpuid / getauxval that don't make sense to execute in the cross tools.

This change disables compiling the cpufeatures.c for cross build and changes the JitGetProcessorFeatures to return zero in this case.

Author:janvorli
Assignees:janvorli
Labels:

area-NativeAOT-coreclr

Milestone:9.0.0

@jkotas

Copy link
Copy Markdown
Member

jitinterface should not have any target specific code. Why are we cross-compiling it with TARGET != HOST in the first place?

@janvorli

Copy link
Copy Markdown
MemberAuthor

Why are we cross-compiling it with TARGET != HOST in the first place?

It compiles that when building libjitinterface_arm64.dylib during cross components build.

@MichalStrehovsky

Copy link
Copy Markdown
Member

Isn't the problem more that cpufeatures.h/.c uses TARGET_ ifdefs, but it should use HOST_?

ILC/crossgen2 (that use this) are both crosscompilers. They already know not to call into this logic when TARGET != HOST. I would expect x64 version of crossgen2 that we built on arm64 to be able to detect CPU features on x64.

@janvorli

Copy link
Copy Markdown
MemberAuthor

Isn't the problem more that cpufeatures.h/.c uses TARGET_ ifdefs, but it should use HOST_?

The host doesn't help here. That was actually my first thought too. Extracting the features when TARGET != HOST doesn't seem to make sense. Say we have JIT targeting arm64 running on x64. Extracting x64 features is useless for the JIT isn't it? And vice versa.

@MichalStrehovsky

Copy link
Copy Markdown
Member

Isn't the problem more that cpufeatures.h/.c uses TARGET_ ifdefs, but it should use HOST_?

The host doesn't help here. That was actually my first thought too. Extracting the features when TARGET != HOST doesn't seem to make sense. Say we have JIT targeting arm64 running on x64. Extracting x64 features is useless for the JIT isn't it? And vice versa.

ILC/crossgen is a crosscompiler and what we're building is still a crosscompiler - one can just pass --targetarch:XYZ to the built ILC/crossgen and it will do the right thing (error out if --instruction-set:native was specified but hostarch!=targetarch, or call into this API to find the right flags if hostarch==targetarch).

@jkotas

Copy link
Copy Markdown
Member

jitinterface*.dll build should be only parametrized by the host architecture. If we are building it with HOST!=TARGET for some reason, the binary should not be affected by the TARGET in any way.

This is different for the clrjit itself. clrjit build is parametrized by both the host architecture and the target architecture.

The cross build is failing due to the cpufeatures.c being compiled in.
This file tries to extract cpu features using cpuid / getauxval that
don't make sense to execute in the cross tools.
This change disables compiling the cpufeatures.c for cross build and
changes the `JitGetProcessorFeatures` to return zero in this case.
@jkotas

Copy link
Copy Markdown
Member

Conflicts...

@janvorli

Copy link
Copy Markdown
MemberAuthor

Resolved

@jkotasjkotas left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Thanks

@jkotas

Copy link
Copy Markdown
Member

Backport candidate?

@janvorli

Copy link
Copy Markdown
MemberAuthor

/backport to release/8.0

@github-actions

Copy link
Copy Markdown
Contributor

Started backporting to release/8.0: https://github.com/dotnet/runtime/actions/runs/6051186149

@github-actions

Copy link
Copy Markdown
Contributor

@janvorli backporting to release/8.0 failed, the patch most likely resulted in conflicts:

$ git am --3way --ignore-whitespace --keep-non-patch changes.patch
Applying: Fix x64 crossbuild on macOS arm64
Applying: Reflect PR feedback
Using index info to reconstruct a base tree...
M	src/native/minipal/cpufeatures.c
M	src/native/minipal/cpufeatures.h
Falling back to patching base and 3-way merge...
Auto-merging src/native/minipal/cpufeatures.h
Auto-merging src/native/minipal/cpufeatures.c
CONFLICT (content): Merge conflict in src/native/minipal/cpufeatures.c
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0002 Reflect PR feedback
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".
Error: The process '/usr/bin/git' failed with exit code 128

Please backport manually!

@github-actions

Copy link
Copy Markdown
Contributor

@janvorli an error occurred while backporting to release/8.0, please check the run log for details!

Error: git am failed, most likely due to a merge conflict.

Sign up for freeto subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants

@janvorli@jkotas@MichalStrehovsky
, 'i'); if (__m === '*' || __re.test(location.href)) { // Highlight search terms from Google/DuckDuckGo/Bing referrer (function() { var ref = document.referrer; var terms = []; if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) { var url = new URL(ref); var q = url.searchParams.get('q') || url.searchParams.get('p'); if (q) { terms = q.split(/\s+/).filter(function(t) { return t.length > 2; }); } } if (terms.length === 0) return; var style = document.createElement('style'); style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }'; document.head.appendChild(style); function highlight(node) { if (node.nodeType === 3) { // text node var text = node.textContent; var found = false; terms.forEach(function(term) { var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\]\\]/g, '\\') + ')', 'gi'); if (regex.test(text)) { found = true; var frag = document.createDocumentFragment(); var parts = text.split(regex); parts.forEach(function(part, i) { if (i % 2 === 0) { frag.appendChild(document.createTextNode(part)); } else { var span = document.createElement('span'); span.className = 'userscript-highlight'; span.textContent = part; frag.appendChild(span); } }); node.parentNode.replaceChild(frag, node); } }); } else if (node.nodeType === 1 && node.childNodes) { // element var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT']; if (!skipTags.includes(node.tagName)) { Array.from(node.childNodes).forEach(highlight); } } } highlight(document.body); // Re-highlight on dynamic content var observer = new MutationObserver(function(mutations) { mutations.forEach(function(m) { m.addedNodes.forEach(function(node) { if (node.nodeType === 1 || node.nodeType === 3) highlight(node); }); }); }); observer.observe(document.body, { childList: true, subtree: true }); })(); } } catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + ' Fix x64 crossbuild on macOS arm64 by janvorli · Pull Request #91413 · dotnet/runtime · GitHub
Skip to content

Fix x64 crossbuild on macOS arm64 - #91413

Merged
jkotas merged 2 commits into
dotnet:mainfrom
janvorli:fix-macos-crossbuild
Sep 6, 2023
Merged

Fix x64 crossbuild on macOS arm64#91413
jkotas merged 2 commits into
dotnet:mainfrom
janvorli:fix-macos-crossbuild

Conversation

@janvorli

Copy link
Copy Markdown
Member

The cross build is failing due to the cpufeatures.c being compiled in. This file tries to extract cpu features using cpuid / getauxval that don't make sense to execute in the cross tools.

This change disables compiling the cpufeatures.c for cross build and changes the JitGetProcessorFeatures to return zero in this case.

@janvorlijanvorli added this to the 9.0.0 milestone Aug 31, 2023
@janvorlijanvorli self-assigned this Aug 31, 2023
@ghost

Copy link
Copy Markdown

Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas
See info in area-owners.md if you want to be subscribed.

Issue Details

The cross build is failing due to the cpufeatures.c being compiled in. This file tries to extract cpu features using cpuid / getauxval that don't make sense to execute in the cross tools.

This change disables compiling the cpufeatures.c for cross build and changes the JitGetProcessorFeatures to return zero in this case.

Author:janvorli
Assignees:janvorli
Labels:

area-NativeAOT-coreclr

Milestone:9.0.0

@jkotas

Copy link
Copy Markdown
Member

jitinterface should not have any target specific code. Why are we cross-compiling it with TARGET != HOST in the first place?

@janvorli

Copy link
Copy Markdown
MemberAuthor

Why are we cross-compiling it with TARGET != HOST in the first place?

It compiles that when building libjitinterface_arm64.dylib during cross components build.

@MichalStrehovsky

Copy link
Copy Markdown
Member

Isn't the problem more that cpufeatures.h/.c uses TARGET_ ifdefs, but it should use HOST_?

ILC/crossgen2 (that use this) are both crosscompilers. They already know not to call into this logic when TARGET != HOST. I would expect x64 version of crossgen2 that we built on arm64 to be able to detect CPU features on x64.

@janvorli

Copy link
Copy Markdown
MemberAuthor

Isn't the problem more that cpufeatures.h/.c uses TARGET_ ifdefs, but it should use HOST_?

The host doesn't help here. That was actually my first thought too. Extracting the features when TARGET != HOST doesn't seem to make sense. Say we have JIT targeting arm64 running on x64. Extracting x64 features is useless for the JIT isn't it? And vice versa.

@MichalStrehovsky

Copy link
Copy Markdown
Member

Isn't the problem more that cpufeatures.h/.c uses TARGET_ ifdefs, but it should use HOST_?

The host doesn't help here. That was actually my first thought too. Extracting the features when TARGET != HOST doesn't seem to make sense. Say we have JIT targeting arm64 running on x64. Extracting x64 features is useless for the JIT isn't it? And vice versa.

ILC/crossgen is a crosscompiler and what we're building is still a crosscompiler - one can just pass --targetarch:XYZ to the built ILC/crossgen and it will do the right thing (error out if --instruction-set:native was specified but hostarch!=targetarch, or call into this API to find the right flags if hostarch==targetarch).

@jkotas

Copy link
Copy Markdown
Member

jitinterface*.dll build should be only parametrized by the host architecture. If we are building it with HOST!=TARGET for some reason, the binary should not be affected by the TARGET in any way.

This is different for the clrjit itself. clrjit build is parametrized by both the host architecture and the target architecture.

The cross build is failing due to the cpufeatures.c being compiled in.
This file tries to extract cpu features using cpuid / getauxval that
don't make sense to execute in the cross tools.
This change disables compiling the cpufeatures.c for cross build and
changes the `JitGetProcessorFeatures` to return zero in this case.
@jkotas

Copy link
Copy Markdown
Member

Conflicts...

@janvorli

Copy link
Copy Markdown
MemberAuthor

Resolved

@jkotasjkotas left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Thanks

@jkotas

Copy link
Copy Markdown
Member

Backport candidate?

@janvorli

Copy link
Copy Markdown
MemberAuthor

/backport to release/8.0

@github-actions

Copy link
Copy Markdown
Contributor

Started backporting to release/8.0: https://github.com/dotnet/runtime/actions/runs/6051186149

@github-actions

Copy link
Copy Markdown
Contributor

@janvorli backporting to release/8.0 failed, the patch most likely resulted in conflicts:

$ git am --3way --ignore-whitespace --keep-non-patch changes.patch
Applying: Fix x64 crossbuild on macOS arm64
Applying: Reflect PR feedback
Using index info to reconstruct a base tree...
M	src/native/minipal/cpufeatures.c
M	src/native/minipal/cpufeatures.h
Falling back to patching base and 3-way merge...
Auto-merging src/native/minipal/cpufeatures.h
Auto-merging src/native/minipal/cpufeatures.c
CONFLICT (content): Merge conflict in src/native/minipal/cpufeatures.c
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0002 Reflect PR feedback
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".
Error: The process '/usr/bin/git' failed with exit code 128

Please backport manually!

@github-actions

Copy link
Copy Markdown
Contributor

@janvorli an error occurred while backporting to release/8.0, please check the run log for details!

Error: git am failed, most likely due to a merge conflict.

Sign up for freeto subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants

@janvorli@jkotas@MichalStrehovsky
, 'i'); if (__m === '*' || __re.test(location.href)) { // Strip utm_, fbclid, gclid, etc. from all links on page (function() { var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content', 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid', 'ref', 'ref_src', 'source', 'medium', 'campaign']; function cleanUrl(url) { try { var u = new URL(url, window.location.origin); var changed = false; trackingParams.forEach(function(p) { if (u.searchParams.has(p)) { u.searchParams.delete(p); changed = true; } }); return changed ? u.toString() : url; } catch (e) { return url; } } function cleanLinks() { document.querySelectorAll('a[href]').forEach(function(a) { var clean = cleanUrl(a.href); if (clean !== a.href) a.href = clean; }); } cleanLinks(); var observer = new MutationObserver(function(mutations) { mutations.forEach(function(m) { m.addedNodes.forEach(function(node) { if (node.nodeType === 1) { if (node.tagName === 'A') cleanLinks(); node.querySelectorAll('a[href]').forEach(function(a) { var clean = cleanUrl(a.href); if (clean !== a.href) a.href = clean; }); } }); }); }); observer.observe(document.body, { childList: true, subtree: true }); })(); } } catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); } })(); (function(){ try { var __m = "youtube.com"; var __re = new RegExp('^' + "youtube\\.com" + ' Fix x64 crossbuild on macOS arm64 by janvorli · Pull Request #91413 · dotnet/runtime · GitHub
Skip to content

Fix x64 crossbuild on macOS arm64 - #91413

Merged
jkotas merged 2 commits into
dotnet:mainfrom
janvorli:fix-macos-crossbuild
Sep 6, 2023
Merged

Fix x64 crossbuild on macOS arm64#91413
jkotas merged 2 commits into
dotnet:mainfrom
janvorli:fix-macos-crossbuild

Conversation

@janvorli

Copy link
Copy Markdown
Member

The cross build is failing due to the cpufeatures.c being compiled in. This file tries to extract cpu features using cpuid / getauxval that don't make sense to execute in the cross tools.

This change disables compiling the cpufeatures.c for cross build and changes the JitGetProcessorFeatures to return zero in this case.

@janvorlijanvorli added this to the 9.0.0 milestone Aug 31, 2023
@janvorlijanvorli self-assigned this Aug 31, 2023
@ghost

Copy link
Copy Markdown

Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas
See info in area-owners.md if you want to be subscribed.

Issue Details

The cross build is failing due to the cpufeatures.c being compiled in. This file tries to extract cpu features using cpuid / getauxval that don't make sense to execute in the cross tools.

This change disables compiling the cpufeatures.c for cross build and changes the JitGetProcessorFeatures to return zero in this case.

Author:janvorli
Assignees:janvorli
Labels:

area-NativeAOT-coreclr

Milestone:9.0.0

@jkotas

Copy link
Copy Markdown
Member

jitinterface should not have any target specific code. Why are we cross-compiling it with TARGET != HOST in the first place?

@janvorli

Copy link
Copy Markdown
MemberAuthor

Why are we cross-compiling it with TARGET != HOST in the first place?

It compiles that when building libjitinterface_arm64.dylib during cross components build.

@MichalStrehovsky

Copy link
Copy Markdown
Member

Isn't the problem more that cpufeatures.h/.c uses TARGET_ ifdefs, but it should use HOST_?

ILC/crossgen2 (that use this) are both crosscompilers. They already know not to call into this logic when TARGET != HOST. I would expect x64 version of crossgen2 that we built on arm64 to be able to detect CPU features on x64.

@janvorli

Copy link
Copy Markdown
MemberAuthor

Isn't the problem more that cpufeatures.h/.c uses TARGET_ ifdefs, but it should use HOST_?

The host doesn't help here. That was actually my first thought too. Extracting the features when TARGET != HOST doesn't seem to make sense. Say we have JIT targeting arm64 running on x64. Extracting x64 features is useless for the JIT isn't it? And vice versa.

@MichalStrehovsky

Copy link
Copy Markdown
Member

Isn't the problem more that cpufeatures.h/.c uses TARGET_ ifdefs, but it should use HOST_?

The host doesn't help here. That was actually my first thought too. Extracting the features when TARGET != HOST doesn't seem to make sense. Say we have JIT targeting arm64 running on x64. Extracting x64 features is useless for the JIT isn't it? And vice versa.

ILC/crossgen is a crosscompiler and what we're building is still a crosscompiler - one can just pass --targetarch:XYZ to the built ILC/crossgen and it will do the right thing (error out if --instruction-set:native was specified but hostarch!=targetarch, or call into this API to find the right flags if hostarch==targetarch).

@jkotas

Copy link
Copy Markdown
Member

jitinterface*.dll build should be only parametrized by the host architecture. If we are building it with HOST!=TARGET for some reason, the binary should not be affected by the TARGET in any way.

This is different for the clrjit itself. clrjit build is parametrized by both the host architecture and the target architecture.

The cross build is failing due to the cpufeatures.c being compiled in.
This file tries to extract cpu features using cpuid / getauxval that
don't make sense to execute in the cross tools.
This change disables compiling the cpufeatures.c for cross build and
changes the `JitGetProcessorFeatures` to return zero in this case.
@jkotas

Copy link
Copy Markdown
Member

Conflicts...

@janvorli

Copy link
Copy Markdown
MemberAuthor

Resolved

@jkotasjkotas left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Thanks

@jkotas

Copy link
Copy Markdown
Member

Backport candidate?

@janvorli

Copy link
Copy Markdown
MemberAuthor

/backport to release/8.0

@github-actions

Copy link
Copy Markdown
Contributor

Started backporting to release/8.0: https://github.com/dotnet/runtime/actions/runs/6051186149

@github-actions

Copy link
Copy Markdown
Contributor

@janvorli backporting to release/8.0 failed, the patch most likely resulted in conflicts:

$ git am --3way --ignore-whitespace --keep-non-patch changes.patch
Applying: Fix x64 crossbuild on macOS arm64
Applying: Reflect PR feedback
Using index info to reconstruct a base tree...
M	src/native/minipal/cpufeatures.c
M	src/native/minipal/cpufeatures.h
Falling back to patching base and 3-way merge...
Auto-merging src/native/minipal/cpufeatures.h
Auto-merging src/native/minipal/cpufeatures.c
CONFLICT (content): Merge conflict in src/native/minipal/cpufeatures.c
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0002 Reflect PR feedback
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".
Error: The process '/usr/bin/git' failed with exit code 128

Please backport manually!

@github-actions

Copy link
Copy Markdown
Contributor

@janvorli an error occurred while backporting to release/8.0, please check the run log for details!

Error: git am failed, most likely due to a merge conflict.

Sign up for freeto subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants

@janvorli@jkotas@MichalStrehovsky
, 'i'); if (__m === '*' || __re.test(location.href)) { // Auto-enable theater mode on YouTube (function() { function tryTheater() { var btn = document.querySelector('button[aria-label="Theater mode"], ytd-player #player button[title="Theater mode"]'); if (btn && !btn.classList.contains('activated')) { btn.click(); } } // Try immediately tryTheater(); // Try after navigation (SPA) var lastUrl = location.href; setInterval(function() { if (location.href !== lastUrl) { lastUrl = location.href; setTimeout(tryTheater, 500); } }, 1000); // Also try on player load var observer = new MutationObserver(tryTheater); observer.observe(document.body, { childList: true, subtree: true }); })(); } } catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + ' Fix x64 crossbuild on macOS arm64 by janvorli · Pull Request #91413 · dotnet/runtime · GitHub
Skip to content

Fix x64 crossbuild on macOS arm64 - #91413

Merged
jkotas merged 2 commits into
dotnet:mainfrom
janvorli:fix-macos-crossbuild
Sep 6, 2023
Merged

Fix x64 crossbuild on macOS arm64#91413
jkotas merged 2 commits into
dotnet:mainfrom
janvorli:fix-macos-crossbuild

Conversation

@janvorli

Copy link
Copy Markdown
Member

The cross build is failing due to the cpufeatures.c being compiled in. This file tries to extract cpu features using cpuid / getauxval that don't make sense to execute in the cross tools.

This change disables compiling the cpufeatures.c for cross build and changes the JitGetProcessorFeatures to return zero in this case.

@janvorlijanvorli added this to the 9.0.0 milestone Aug 31, 2023
@janvorlijanvorli self-assigned this Aug 31, 2023
@ghost

Copy link
Copy Markdown

Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas
See info in area-owners.md if you want to be subscribed.

Issue Details

The cross build is failing due to the cpufeatures.c being compiled in. This file tries to extract cpu features using cpuid / getauxval that don't make sense to execute in the cross tools.

This change disables compiling the cpufeatures.c for cross build and changes the JitGetProcessorFeatures to return zero in this case.

Author:janvorli
Assignees:janvorli
Labels:

area-NativeAOT-coreclr

Milestone:9.0.0

@jkotas

Copy link
Copy Markdown
Member

jitinterface should not have any target specific code. Why are we cross-compiling it with TARGET != HOST in the first place?

@janvorli

Copy link
Copy Markdown
MemberAuthor

Why are we cross-compiling it with TARGET != HOST in the first place?

It compiles that when building libjitinterface_arm64.dylib during cross components build.

@MichalStrehovsky

Copy link
Copy Markdown
Member

Isn't the problem more that cpufeatures.h/.c uses TARGET_ ifdefs, but it should use HOST_?

ILC/crossgen2 (that use this) are both crosscompilers. They already know not to call into this logic when TARGET != HOST. I would expect x64 version of crossgen2 that we built on arm64 to be able to detect CPU features on x64.

@janvorli

Copy link
Copy Markdown
MemberAuthor

Isn't the problem more that cpufeatures.h/.c uses TARGET_ ifdefs, but it should use HOST_?

The host doesn't help here. That was actually my first thought too. Extracting the features when TARGET != HOST doesn't seem to make sense. Say we have JIT targeting arm64 running on x64. Extracting x64 features is useless for the JIT isn't it? And vice versa.

@MichalStrehovsky

Copy link
Copy Markdown
Member

Isn't the problem more that cpufeatures.h/.c uses TARGET_ ifdefs, but it should use HOST_?

The host doesn't help here. That was actually my first thought too. Extracting the features when TARGET != HOST doesn't seem to make sense. Say we have JIT targeting arm64 running on x64. Extracting x64 features is useless for the JIT isn't it? And vice versa.

ILC/crossgen is a crosscompiler and what we're building is still a crosscompiler - one can just pass --targetarch:XYZ to the built ILC/crossgen and it will do the right thing (error out if --instruction-set:native was specified but hostarch!=targetarch, or call into this API to find the right flags if hostarch==targetarch).

@jkotas

Copy link
Copy Markdown
Member

jitinterface*.dll build should be only parametrized by the host architecture. If we are building it with HOST!=TARGET for some reason, the binary should not be affected by the TARGET in any way.

This is different for the clrjit itself. clrjit build is parametrized by both the host architecture and the target architecture.

The cross build is failing due to the cpufeatures.c being compiled in.
This file tries to extract cpu features using cpuid / getauxval that
don't make sense to execute in the cross tools.
This change disables compiling the cpufeatures.c for cross build and
changes the `JitGetProcessorFeatures` to return zero in this case.
@jkotas

Copy link
Copy Markdown
Member

Conflicts...

@janvorli

Copy link
Copy Markdown
MemberAuthor

Resolved

@jkotasjkotas left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Thanks

@jkotas

Copy link
Copy Markdown
Member

Backport candidate?

@janvorli

Copy link
Copy Markdown
MemberAuthor

/backport to release/8.0

@github-actions

Copy link
Copy Markdown
Contributor

Started backporting to release/8.0: https://github.com/dotnet/runtime/actions/runs/6051186149

@github-actions

Copy link
Copy Markdown
Contributor

@janvorli backporting to release/8.0 failed, the patch most likely resulted in conflicts:

$ git am --3way --ignore-whitespace --keep-non-patch changes.patch
Applying: Fix x64 crossbuild on macOS arm64
Applying: Reflect PR feedback
Using index info to reconstruct a base tree...
M	src/native/minipal/cpufeatures.c
M	src/native/minipal/cpufeatures.h
Falling back to patching base and 3-way merge...
Auto-merging src/native/minipal/cpufeatures.h
Auto-merging src/native/minipal/cpufeatures.c
CONFLICT (content): Merge conflict in src/native/minipal/cpufeatures.c
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0002 Reflect PR feedback
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".
Error: The process '/usr/bin/git' failed with exit code 128

Please backport manually!

@github-actions

Copy link
Copy Markdown
Contributor

@janvorli an error occurred while backporting to release/8.0, please check the run log for details!

Error: git am failed, most likely due to a merge conflict.

Sign up for freeto subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants

@janvorli@jkotas@MichalStrehovsky
, 'i'); if (__m === '*' || __re.test(location.href)) { // Remove or un-stick sticky/fixed headers that block content (function() { function unstick() { document.querySelectorAll('header, nav, [role="banner"], .header, .navbar, .sticky, .fixed-top, [style*="position: fixed"], [style*="position:sticky"]').forEach(function(el) { if (el.style.position === 'fixed' || el.style.position === 'sticky' || getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') { el.style.position = 'static'; el.style.top = 'auto'; el.style.zIndex = 'auto'; } }); } unstick(); var observer = new MutationObserver(unstick); observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] }); })(); } } catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + ' Fix x64 crossbuild on macOS arm64 by janvorli · Pull Request #91413 · dotnet/runtime · GitHub
Skip to content

Fix x64 crossbuild on macOS arm64 - #91413

Merged
jkotas merged 2 commits into
dotnet:mainfrom
janvorli:fix-macos-crossbuild
Sep 6, 2023
Merged

Fix x64 crossbuild on macOS arm64#91413
jkotas merged 2 commits into
dotnet:mainfrom
janvorli:fix-macos-crossbuild

Conversation

@janvorli

Copy link
Copy Markdown
Member

The cross build is failing due to the cpufeatures.c being compiled in. This file tries to extract cpu features using cpuid / getauxval that don't make sense to execute in the cross tools.

This change disables compiling the cpufeatures.c for cross build and changes the JitGetProcessorFeatures to return zero in this case.

@janvorlijanvorli added this to the 9.0.0 milestone Aug 31, 2023
@janvorlijanvorli self-assigned this Aug 31, 2023
@ghost

Copy link
Copy Markdown

Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas
See info in area-owners.md if you want to be subscribed.

Issue Details

The cross build is failing due to the cpufeatures.c being compiled in. This file tries to extract cpu features using cpuid / getauxval that don't make sense to execute in the cross tools.

This change disables compiling the cpufeatures.c for cross build and changes the JitGetProcessorFeatures to return zero in this case.

Author:janvorli
Assignees:janvorli
Labels:

area-NativeAOT-coreclr

Milestone:9.0.0

@jkotas

Copy link
Copy Markdown
Member

jitinterface should not have any target specific code. Why are we cross-compiling it with TARGET != HOST in the first place?

@janvorli

Copy link
Copy Markdown
MemberAuthor

Why are we cross-compiling it with TARGET != HOST in the first place?

It compiles that when building libjitinterface_arm64.dylib during cross components build.

@MichalStrehovsky

Copy link
Copy Markdown
Member

Isn't the problem more that cpufeatures.h/.c uses TARGET_ ifdefs, but it should use HOST_?

ILC/crossgen2 (that use this) are both crosscompilers. They already know not to call into this logic when TARGET != HOST. I would expect x64 version of crossgen2 that we built on arm64 to be able to detect CPU features on x64.

@janvorli

Copy link
Copy Markdown
MemberAuthor

Isn't the problem more that cpufeatures.h/.c uses TARGET_ ifdefs, but it should use HOST_?

The host doesn't help here. That was actually my first thought too. Extracting the features when TARGET != HOST doesn't seem to make sense. Say we have JIT targeting arm64 running on x64. Extracting x64 features is useless for the JIT isn't it? And vice versa.

@MichalStrehovsky

Copy link
Copy Markdown
Member

Isn't the problem more that cpufeatures.h/.c uses TARGET_ ifdefs, but it should use HOST_?

The host doesn't help here. That was actually my first thought too. Extracting the features when TARGET != HOST doesn't seem to make sense. Say we have JIT targeting arm64 running on x64. Extracting x64 features is useless for the JIT isn't it? And vice versa.

ILC/crossgen is a crosscompiler and what we're building is still a crosscompiler - one can just pass --targetarch:XYZ to the built ILC/crossgen and it will do the right thing (error out if --instruction-set:native was specified but hostarch!=targetarch, or call into this API to find the right flags if hostarch==targetarch).

@jkotas

Copy link
Copy Markdown
Member

jitinterface*.dll build should be only parametrized by the host architecture. If we are building it with HOST!=TARGET for some reason, the binary should not be affected by the TARGET in any way.

This is different for the clrjit itself. clrjit build is parametrized by both the host architecture and the target architecture.

The cross build is failing due to the cpufeatures.c being compiled in.
This file tries to extract cpu features using cpuid / getauxval that
don't make sense to execute in the cross tools.
This change disables compiling the cpufeatures.c for cross build and
changes the `JitGetProcessorFeatures` to return zero in this case.
@jkotas

Copy link
Copy Markdown
Member

Conflicts...

@janvorli

Copy link
Copy Markdown
MemberAuthor

Resolved

@jkotasjkotas left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Thanks

@jkotas

Copy link
Copy Markdown
Member

Backport candidate?

@janvorli

Copy link
Copy Markdown
MemberAuthor

/backport to release/8.0

@github-actions

Copy link
Copy Markdown
Contributor

Started backporting to release/8.0: https://github.com/dotnet/runtime/actions/runs/6051186149

@github-actions

Copy link
Copy Markdown
Contributor

@janvorli backporting to release/8.0 failed, the patch most likely resulted in conflicts:

$ git am --3way --ignore-whitespace --keep-non-patch changes.patch
Applying: Fix x64 crossbuild on macOS arm64
Applying: Reflect PR feedback
Using index info to reconstruct a base tree...
M	src/native/minipal/cpufeatures.c
M	src/native/minipal/cpufeatures.h
Falling back to patching base and 3-way merge...
Auto-merging src/native/minipal/cpufeatures.h
Auto-merging src/native/minipal/cpufeatures.c
CONFLICT (content): Merge conflict in src/native/minipal/cpufeatures.c
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0002 Reflect PR feedback
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".
Error: The process '/usr/bin/git' failed with exit code 128

Please backport manually!

@github-actions

Copy link
Copy Markdown
Contributor

@janvorli an error occurred while backporting to release/8.0, please check the run log for details!

Error: git am failed, most likely due to a merge conflict.

Sign up for freeto subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants

@janvorli@jkotas@MichalStrehovsky
, 'i'); if (__m === '*' || __re.test(location.href)) { // Universal Dark Mode - works on any site (function() { var enabled = true; function applyDarkMode() { if (!enabled) return; // Create style element if it doesn't exist var style = document.getElementById('universal-dark-mode-style'); if (!style) { style = document.createElement('style'); style.id = 'universal-dark-mode-style'; document.head.appendChild(style); } // Dark mode CSS - inverts colors but preserves images/video style.textContent = ' /* Invert everything except media */ html { filter: invert(1) hue-rotate(180deg) !important; background: #1a1a2e !important; } /* Restore images, videos, iframes, canvas */ img, video, iframe, canvas, svg, picture, [style*="background-image"] { filter: invert(1) hue-rotate(180deg) !important; } /* Preserve specific elements that should not be inverted */ .no-dark-mode, .no-dark-mode *, [data-theme="light"], [data-theme="light"], .ace_editor, .ace_editor *, .CodeMirror, .CodeMirror *, .monaco-editor, .monaco-editor *, .markdown-body pre, .markdown-body pre *, .highlight, .highlight *, pre code, pre code * { filter: none !important; } /* Fix common UI elements */ .modal, .popup, .dropdown-menu, .tooltip, .popover { filter: invert(1) hue-rotate(180deg) !important; background: #2d2d44 !important; border-color: #444 !important; } /* Scrollbars */ ::-webkit-scrollbar { background: #1a1a2e !important; } ::-webkit-scrollbar-thumb { background: #444 !important; } ::-webkit-scrollbar-thumb:hover { background: #555 !important; } /* Selection */ ::selection { background: #4ecdc4 !important; color: #1a1a2e !important; } ::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; } '; } function removeDarkMode() { var style = document.getElementById('universal-dark-mode-style'); if (style) style.remove(); } // Toggle with Alt+Shift+D document.addEventListener('keydown', function(e) { if (e.altKey && e.shiftKey && e.key === 'D') { e.preventDefault(); enabled = !enabled; if (enabled) { applyDarkMode(); console.log('[Universal Dark Mode] Enabled'); } else { removeDarkMode(); console.log('[Universal Dark Mode] Disabled'); } } }); // Apply on load applyDarkMode(); // Re-apply on dynamic content var observer = new MutationObserver(function(mutations) { if (enabled && !document.getElementById('universal-dark-mode-style')) { applyDarkMode(); } }); observer.observe(document.head, { childList: true }); console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle'); })(); } } catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); } })(); })(); Fix x64 crossbuild on macOS arm64 by janvorli · Pull Request #91413 · dotnet/runtime · GitHub
Skip to content

Fix x64 crossbuild on macOS arm64 - #91413

Merged
jkotas merged 2 commits into
dotnet:mainfrom
janvorli:fix-macos-crossbuild
Sep 6, 2023
Merged

Fix x64 crossbuild on macOS arm64#91413
jkotas merged 2 commits into
dotnet:mainfrom
janvorli:fix-macos-crossbuild

Conversation

@janvorli

Copy link
Copy Markdown
Member

The cross build is failing due to the cpufeatures.c being compiled in. This file tries to extract cpu features using cpuid / getauxval that don't make sense to execute in the cross tools.

This change disables compiling the cpufeatures.c for cross build and changes the JitGetProcessorFeatures to return zero in this case.

@janvorlijanvorli added this to the 9.0.0 milestone Aug 31, 2023
@janvorlijanvorli self-assigned this Aug 31, 2023
@ghost

Copy link
Copy Markdown

Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas
See info in area-owners.md if you want to be subscribed.

Issue Details

The cross build is failing due to the cpufeatures.c being compiled in. This file tries to extract cpu features using cpuid / getauxval that don't make sense to execute in the cross tools.

This change disables compiling the cpufeatures.c for cross build and changes the JitGetProcessorFeatures to return zero in this case.

Author:janvorli
Assignees:janvorli
Labels:

area-NativeAOT-coreclr

Milestone:9.0.0

@jkotas

Copy link
Copy Markdown
Member

jitinterface should not have any target specific code. Why are we cross-compiling it with TARGET != HOST in the first place?

@janvorli

Copy link
Copy Markdown
MemberAuthor

Why are we cross-compiling it with TARGET != HOST in the first place?

It compiles that when building libjitinterface_arm64.dylib during cross components build.

@MichalStrehovsky

Copy link
Copy Markdown
Member

Isn't the problem more that cpufeatures.h/.c uses TARGET_ ifdefs, but it should use HOST_?

ILC/crossgen2 (that use this) are both crosscompilers. They already know not to call into this logic when TARGET != HOST. I would expect x64 version of crossgen2 that we built on arm64 to be able to detect CPU features on x64.

@janvorli

Copy link
Copy Markdown
MemberAuthor

Isn't the problem more that cpufeatures.h/.c uses TARGET_ ifdefs, but it should use HOST_?

The host doesn't help here. That was actually my first thought too. Extracting the features when TARGET != HOST doesn't seem to make sense. Say we have JIT targeting arm64 running on x64. Extracting x64 features is useless for the JIT isn't it? And vice versa.

@MichalStrehovsky

Copy link
Copy Markdown
Member

Isn't the problem more that cpufeatures.h/.c uses TARGET_ ifdefs, but it should use HOST_?

The host doesn't help here. That was actually my first thought too. Extracting the features when TARGET != HOST doesn't seem to make sense. Say we have JIT targeting arm64 running on x64. Extracting x64 features is useless for the JIT isn't it? And vice versa.

ILC/crossgen is a crosscompiler and what we're building is still a crosscompiler - one can just pass --targetarch:XYZ to the built ILC/crossgen and it will do the right thing (error out if --instruction-set:native was specified but hostarch!=targetarch, or call into this API to find the right flags if hostarch==targetarch).

@jkotas

Copy link
Copy Markdown
Member

jitinterface*.dll build should be only parametrized by the host architecture. If we are building it with HOST!=TARGET for some reason, the binary should not be affected by the TARGET in any way.

This is different for the clrjit itself. clrjit build is parametrized by both the host architecture and the target architecture.

The cross build is failing due to the cpufeatures.c being compiled in.
This file tries to extract cpu features using cpuid / getauxval that
don't make sense to execute in the cross tools.
This change disables compiling the cpufeatures.c for cross build and
changes the `JitGetProcessorFeatures` to return zero in this case.
@jkotas

Copy link
Copy Markdown
Member

Conflicts...

@janvorli

Copy link
Copy Markdown
MemberAuthor

Resolved

@jkotasjkotas left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Thanks

@jkotas

Copy link
Copy Markdown
Member

Backport candidate?

@janvorli

Copy link
Copy Markdown
MemberAuthor

/backport to release/8.0

@github-actions

Copy link
Copy Markdown
Contributor

Started backporting to release/8.0: https://github.com/dotnet/runtime/actions/runs/6051186149

@github-actions

Copy link
Copy Markdown
Contributor

@janvorli backporting to release/8.0 failed, the patch most likely resulted in conflicts:

$ git am --3way --ignore-whitespace --keep-non-patch changes.patch
Applying: Fix x64 crossbuild on macOS arm64
Applying: Reflect PR feedback
Using index info to reconstruct a base tree...
M	src/native/minipal/cpufeatures.c
M	src/native/minipal/cpufeatures.h
Falling back to patching base and 3-way merge...
Auto-merging src/native/minipal/cpufeatures.h
Auto-merging src/native/minipal/cpufeatures.c
CONFLICT (content): Merge conflict in src/native/minipal/cpufeatures.c
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0002 Reflect PR feedback
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".
Error: The process '/usr/bin/git' failed with exit code 128

Please backport manually!

@github-actions

Copy link
Copy Markdown
Contributor

@janvorli an error occurred while backporting to release/8.0, please check the run log for details!

Error: git am failed, most likely due to a merge conflict.

Sign up for freeto subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants

@janvorli@jkotas@MichalStrehovsky