[BoundsSafety][LLDB] Implement instrumentation plugin for -fbounds-safety soft traps

[delcypher]

This patch implements an instrumentation plugin for the
-fbounds-safety soft trap mode first implemented in
#11645 (rdar://158088757).

The current implementation of -fbounds-safety traps works by emitting
calls to runtime functions intended to log the occurrence of a soft trap.
While the user could just set a breakpoint of these functions the
instrumentation plugin sets it automatically and provides several
additional features:

When debug info is available:

• It adjusts the stop reason to be the reason for trapping. This is
  extracted from the artificial frame in the debug info (similar to
  -fbounds-safety hard traps).
• It adjusts the selected frame to be the frame where the soft trap
  occurred.

When debug info is not available:

• For the call-with-str soft trap mode the soft trap reason is
  read from the first argument register.
• For the call-minimal soft trap mode the stop reason is adjusted
  to note its a bounds check failure but does not give further
  information because none is available.
• In this situation the selected frame is not adjusted because in
  this mode the user will be looking at assembly and adjusting the
  frame makes things confusing.

This patch includes shell and api tests. The shell tests seemed like the
best way to test behavior when debug info is missing because those tests
make it easy to disable building with debug info completely.

rdar://163230807

[delcypher]

@swift-ci test

[delcypher]

@swift-ci test llvm

[delcypher]

@swift-ci test

[delcypher]

@swift-ci test llvm

[delcypher]

Windows failure looks completely unrelated to this PR:

21:30:12  C:\Program Files\CMake\bin\cmake.exe -B T:\x86_64-unknown-windows-msvc\DocC -S C:\Users\swift-ci\jenkins\workspace\apple-llvm-project-pull-request-windows\swift-docc -G Ninja -D ArgumentParser_DIR=T:/x86_64-unknown-windows-msvc/ArgumentParser/cmake/modules -D BUILD_SHARED_LIBS=YES -D CMAKE_BUILD_TYPE=Release -D CMAKE_C_COMPILER=T:/5/bin/clang-cl.exe -D CMAKE_C_COMPILER_TARGET=x86_64-unknown-windows-msvc -D CMAKE_C_FLAGS=/GS- /Gw /Gy /Oy /Oi /Zc:inline -D CMAKE_EXE_LINKER_FLAGS=/INCREMENTAL:NO /OPT:REF /OPT:ICF -D CMAKE_FIND_PACKAGE_PREFER_CONFIG=YES -D CMAKE_INSTALL_PREFIX=T:/Program Files/Swift/Toolchains/0.0.0+Asserts/usr -D CMAKE_MAKE_PROGRAM=C:/Program Files/Microsoft Visual Studio/2022/Community/Common7/IDE/CommonExtensions/Microsoft/CMake/Ninja/ninja.exe -D CMAKE_SHARED_LINKER_FLAGS=/INCREMENTAL:NO /OPT:REF /OPT:ICF -D CMAKE_STATIC_LIBRARY_PREFIX_Swift=lib -D CMAKE_Swift_COMPILER=T:/5/bin/swiftc.exe -D CMAKE_Swift_COMPILER_TARGET=x86_64-unknown-windows-msvc -D CMAKE_Swift_COMPILER_WORKS=YES -D CMAKE_Swift_FLAGS=-sdk \"T:/Program Files/Swift/Platforms/Windows.platform/Developer/SDKs/Windows.sdk\" -gnone -Xlinker /INCREMENTAL:NO -Xlinker /OPT:REF -Xlinker /OPT:ICF -D CMAKE_Swift_FLAGS_RELEASE=-O -D CMAKE_Swift_FLAGS_RELWITHDEBINFO=-O -D cmark-gfm_DIR=T:/Program Files/Swift/Toolchains/0.0.0+Asserts/usr/lib/cmake -D LMDB_DIR=T:/x86_64-unknown-windows-msvc/LMDB/cmake/modules -D SwiftASN1_DIR=T:/x86_64-unknown-windows-msvc/ASN1/cmake/modules -D SwiftCrypto_DIR=T:/x86_64-unknown-windows-msvc/Crypto/cmake/modules -D SwiftMarkdown_DIR=T:/x86_64-unknown-windows-msvc/Markdown/cmake/modules -D SymbolKit_DIR=T:/x86_64-unknown-windows-msvc/SymbolKit/cmake/modules
21:30:12  -- The C compiler identification is Clang 21.1.6 with MSVC-like command-line
21:30:12  -- The Swift compiler identification is Apple 6.3
21:30:13  -- Detecting C compiler ABI info
21:30:13  -- Detecting C compiler ABI info - done
21:30:13  -- Check for working C compiler: T:/5/bin/clang-cl.exe - skipped
21:30:13  -- Detecting C compile features
21:30:13  -- Detecting C compile features - done
21:30:13  CMake Error at Sources/CMakeLists.txt:11 (add_subdirectory):
21:30:13    The source directory
21:30:13  
21:30:13      C:/Users/swift-ci/jenkins/workspace/apple-llvm-project-pull-request-windows/swift-docc/Sources/SwiftDocCUtilities
21:30:13  
21:30:13    does not contain a CMakeLists.txt file.
21:30:13  
21:30:13  
21:30:13  -- Configuring incomplete, errors occurred!
21:30:13  Error: Error: cmake.exe exited with code 1.

likely caused by swiftlang/swift-docc#1331. Looks like swiftlang/swift-docc#1352 is out to revert this change.

[delcypher]

@swift-ci please test windows platform

[delcypher]

@swift-ci test

[delcypher]

I've squash the feedback commits into the relevant commit and I've kicked off PR testing.

[Michael137]

2. Call to one of the soft trap functions where debug info is not available in the caller. In this case we inspect register state (only for one of the soft trap functions) to try to get the stop reason. This is something that the verbose frame recognizer doesn't do currently.

Pulling all that logic into the existing verbose stackframe recognizer doesn't make sense to me because __builtin_verbose_trap() doesn't emit code+debug info like this. It would also really over complicate the implementation just for this use case. If we did decide to move the logic into a stackframe recognizer I'd argue it probably should be its own separate one.

Ok that makes sense. I naively thought we'd be able to share the logic which recognizes the stop reason in the no-debug-info case. But sounds like for verbose_trap that would have to look very different to the soft trap case.

I would prefer to just merge. I'll file a radar about considering moving some of the logic into a stackframe recognizer.

Sounds good to me!

[delcypher]

@swift-ci test windows platform

[delcypher]

So the windows build is failing because the api tests don't pass there. The assert where the stop reason is checked fails. The stop reason is supposed to be eStopReasonInstrumentation but its eStopReasonNone instead. I don't know why that would be and I don't have a Windows machine to debug this so it's probably simpler to just disable the test on Windows.

[2025-11-20T08:00:56.506Z] FAIL: test_call_with_str_dwarf (TestBoundsSafetyInstrumentationPlugin.BoundsSafetyTestSoftTrapPlugin)

[2025-11-20T08:00:56.506Z]    Test the plugin on code built with

[2025-11-20T08:00:56.506Z] ----------------------------------------------------------------------

[2025-11-20T08:00:56.506Z] Traceback (most recent call last):

[2025-11-20T08:00:56.506Z]   File "C:\Users\swift-ci\jenkins\workspace\apple-llvm-project-pull-request-windows\llvm-project\lldb\packages\Python\lldbsuite\test\lldbtest.py", line 1843, in test_method

[2025-11-20T08:00:56.506Z]     return attrvalue(self)

[2025-11-20T08:00:56.506Z]   File "C:\Users\swift-ci\jenkins\workspace\apple-llvm-project-pull-request-windows\llvm-project\lldb\test\API\lang\BoundsSafety\soft_trap\TestBoundsSafetyInstrumentationPlugin.py", line 128, in test_call_with_str

[2025-11-20T08:00:56.506Z]     self.check_state_soft_trap_with_str(

[2025-11-20T08:00:56.506Z]   File "C:\Users\swift-ci\jenkins\workspace\apple-llvm-project-pull-request-windows\llvm-project\lldb\test\API\lang\BoundsSafety\soft_trap\TestBoundsSafetyInstrumentationPlugin.py", line 82, in check_state_soft_trap_with_str

[2025-11-20T08:00:56.506Z]     self._check_stop_reason_impl(SOFT_TRAP_FUNC_WITH_STR,

[2025-11-20T08:00:56.506Z]   File "C:\Users\swift-ci\jenkins\workspace\apple-llvm-project-pull-request-windows\llvm-project\lldb\test\API\lang\BoundsSafety\soft_trap\TestBoundsSafetyInstrumentationPlugin.py", line 22, in _check_stop_reason_impl

[2025-11-20T08:00:56.506Z]     self.assertEqual(

[2025-11-20T08:00:56.506Z] AssertionError: 1 != 10

[2025-11-20T08:00:56.506Z] Config=x86_64-T:\5\bin\clang.exe

[2025-11-20T08:00:56.506Z] ----------------------------------------------------------------------

[delcypher]

@swift-ci test

[delcypher]

@swift-ci please test Windows platform

[Michael137]

@charles-zablit has been working on LLDB's Windows support. Mind giving this a try on your Windows machine once you have a free second?

CC @adrian-prantl

[JDevlieghere]

I discussed this with Dan offline. The plugin can go upstream, only the tests depend on having bounds safety support. You can configure LLDB to use a different compiler than the in-tree one, which provides path to landing this upstream.

I'm approving this so we can merge this PR before the branches lock later today. I spotted some minor issues which we can address when landing this upstream.