jasonmolenda added a comment. I don't know if I support bothering with checking ld's version, I think these tests should be skipped on Darwin.
Before macOS 12, if you built these tests arm64e, the address for something like `my_global_str` in lldb/test/API/commands/target/basic/globals.c would be the file address and an extra high bit set, a flag to dyld at runtime. As of macOS 12 and newer, on arm64 and arm64e, chained fixups are being used and now my_global_str as a file offset (not a file address) and a high bit to indicate the linker needs to fix it. On Intel, if you use Xcode 13's ld64 and have a deployment target of macOS 13 (macOS Ventura, the one in beta right now), you'll also get chained fixups. Old linker, newer deployment target, and the tests can fail. Using the Xcode 13 ld64 on a macOS 13 system would probably get you chained fixups by default. We already skip these tests for arm64 & arm64e because of the chained fixups and arm64e fixups before that -- and now we're going to skip them on x86_64 if the deployment target is new enough (that's the right way to do it, not the linker version) -- I say we skip them on Darwin outright. Pre-execution, we can't reliably view global variables, unless we talk with the ld64/dyld folks and see if we can reliably get the file offset out of these fields and work out the file address ourselves. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D131741/new/ https://reviews.llvm.org/D131741 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
