Support executables with multiple architectures (e.g. macOS)

[H-G-Hristov]

Type: Bug

macOS has the notion of "universal binary": https://developer.apple.com/documentation/apple-silicon/building-a-universal-macos-binary

A universal binary runs natively on both Apple silicon and Intel-based Mac computers, because it contains executable code for both architectures.

In CMake I can request to build an universal binary by e.g.
https://cmake.org/cmake/help/latest/variable/CMAKE_OSX_ARCHITECTURES.html

if (APPLE)
  if(AGENT_ARCHITECTURE MATCHES "universal")
    set(AGENT_ARCHITECTURE "arm64;x86_64")

...

endif (APPLE)

...

if (APPLE)
  set (CMAKE_OSX_ARCHITECTURES "${AGENT_ARCHITECTURE}")

...

And in CMakePresets.json:

      "cacheVariables": {
        "AGENT_ARCHITECTURE": {
          "type": "STRING",
          "value": "universal"
        }
      }

Originally reported as part of: #9776

Extension version: 1.12.4
VS Code version: Code 1.71.2 (Universal) (74b1f979648cc44d385a2286793c226e611f59e7, 2022-09-14T21:05:37.721Z)
OS version: Darwin arm64 21.6.0
Modes:
Sandboxed: No

System Info

Item	Value
CPUs	Apple M1 Pro (8 x 24)
GPU Status	2d_canvas: enabled canvas_oop_rasterization: disabled_off direct_rendering_display_compositor: disabled_off_ok gpu_compositing: enabled metal: disabled_off multiple_raster_threads: enabled_on opengl: enabled_on rasterization: enabled raw_draw: disabled_off_ok skia_renderer: enabled_on video_decode: enabled video_encode: enabled vulkan: disabled_off webgl: enabled webgl2: enabled webgpu: disabled_off
Load (avg)	1, 1, 1
Memory (System)	16.00GB (0.79GB free)
Process Argv	--crash-reporter-id a7eaff19-94ae-4653-b917-d9aaab19da5d
Screen Reader	no
VM	0%

A/B Experiments

vsliv368:30146709
vsreu685:30147344
python383cf:30185419
vspor879:30202332
vspor708:30202333
vspor363:30204092
vswsl492cf:30256860
vslsvsres303:30308271
pythonvspyl392:30443607
vserr242cf:30382550
pythontb:30283811
vsjup518:30340749
pythonptprofiler:30281270
vshan820:30294714
vstes263:30335439
pythondataviewer:30285071
vscod805:30301674
binariesv615:30325510
bridge0708:30335490
bridge0723:30353136
cmake_vspar411cf:30557515
vsaa593cf:30376535
pythonvs932:30410667
cppdebug:30492333
vsclangdc:30486549
c4g48928:30535728
hb751961:30553087
dsvsc012cf:30540253
azure-dev_surveyone:30548225
i497e931:30553904
vsccc:30566497
fc301958:30567733

[bobbrow]

@H-G-Hristov I don't think we've tested this yet. What is it that isn't working? Debug/Run buttons? CTest? All of these?

[sean-mcmanus]

I believe it's this error: "/usr/bin/clang -arch x86_64 -arch arm64 -E -x c++ /dev/null
clang: error: cannot use 'c++-cpp-output' output with multiple -arch options".

Root cause is CMake Tools is sending a custom configuration with "-arch x86_64 -arch arm64" which is invalid when -E is used, which is required by cpptools for compiler querying. We could also fix it on the cpptools side.

[bobbrow]

if two -arch switches are allowed while compiling, but not while probing the compiler, then I believe this is something cpptools needs to address. Configuration Providers should not need to send different arguments based on what is compatible with the probe switches.

[sean-mcmanus]

@H-G-Hristov Fixed with 1.13.1: https://github.com/microsoft/vscode-cpptools/releases/tag/v1.13.1

[H-G-Hristov]

@sean-mcmanus I started using v.1.13.1. It's still little bit early for me to confirm I'm all of the fixes that were included are woking.
I'm still facing an issue with IntelliSense getting stuck at updating. So I guess it is not related to the current topic (multiple architectures).
Is there a bug report that tracks such an issue? Is there something I can do to help?

[sean-mcmanus]

IntelliSense getting stuck might be #9688, although in that case cpptools should be getting stuck (you'd know it's that issue if a thread has wordexp on it). Our next release may have a fix or mitigation for that.