Swift: macro plugin host fails with "Bad CPU type in executable" when tracing an Xcode 27 build on Apple Silicon #22742

Description

Creating a Swift database for an iOS app that uses SwiftData macros (@Model, #Predicate) fails on an Apple Silicon Mac with Xcode 27. swift-frontend runs under the tracer, but it cannot launch the macro plugin host, so every macro expansion fails and the build stops.

Environment

• CodeQL CLI 2.27.1 (Homebrew cask codeql); the tracer runs from tools/osx64/preload_tracer
• macOS 27.0.1 on Apple M1 Pro
• Rosetta 2 installed
• Xcode 27.0 (27A266a), iOS 27 SDK
• lipo -archs reports arm64 only for both of these:
  • /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/swift-plugin-server
  • /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swift-frontend

Steps to reproduce

1. Use an iOS project containing any SwiftData @Model class.
2. Put the build in a script, build.sh:

   #!/bin/bash
   set -euo pipefail
   xcodebuild -project App.xcodeproj -scheme App -destination 'generic/platform=iOS Simulator' -derivedDataPath /tmp/dd-codeql CODE_SIGNING_ALLOWED=NO clean build

3. Run:

   codeql database create /tmp/db --language=swift --overwrite --command=./build.sh

Expected behaviour

The database is created. Running ./build.sh without CodeQL ends in ** BUILD SUCCEEDED **.

Actual behaviour

The build fails with exit code 65. Every file using a SwiftData macro reports:

error: external macro implementation type 'SwiftDataMacros.PersistentModelMacro' could not be found for macro 'Model()'; compiler plugin '/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/swift-plugin-server' could not be loaded: Bad CPU type in executable

Related observations

1. Without the macro plugin, the tracer copes with the arm64-only toolchain. A probe with --command="xcodebuild -version" runs xcodebuild and prints Xcode 27.0 / Build version 27A266a, and the plain build of the same project (without CodeQL) succeeds. So the failure seems specific to how the traced swift-frontend launches swift-plugin-server.
2. During the traced build, the relocator makes patched .slice.arm64 copies of xcodebuild, SWBBuildService, actool, ibtoold and ld. Each one logs an install_name_tool header-padding error and then falls back to a short symlink, after which tracing continues normally. I include this in case it's related:

   error: .../install_name_tool: changing install names or rpaths can't be redone for: .../xcodebuild.semmle.<id>.slice.arm64 (for architecture arm64) because larger updated load commands do not fit (the program must be relinked, and you may need to use -headerpad or -headerpad_max_install_names)
   relocator: resorting to replacing "/Applications/Xcode.app/Contents/Developer/usr/bin" with short symlink "/tmp/<random>"