LLDB usage of DW_AT_LLVM_isysroot

Development LLDB
1

We're looking at improving the hermeticity of .o files with Bazel. From on macOS isysroot should be set to a stable execroot relative path · Issue #966 · bazelbuild/rules_apple · GitHub, both Swift/Clang emit debug information with absolute DW_AT_LLVM_isysroot paths. This is problematic since it could vary locally vs. remotely (e.g. Xcode.app vs Xcode_12.app).

Debug prefix map seems like one solution here, but do we need to remap it back for LLDB to work properly? This post seems to claim it's not necessary to remap it for LLDB? Is that also the case for code compiled by Clang?

1 Like
2

Looking further into this, it looks like DEVELOPER_DIR leaks into the debug information in other ways:

find bazel-out/ios-x86_64-min11.0-applebin_ios-ios_x86_64-dbg -name "*.o" | xargs dwarfdump  | grep Xcode -C 5

gives lots of entries like

0x0000551e:         DW_TAG_member
                      DW_AT_name	("round_style")
                      DW_AT_type	(0x0000a107 "const float_round_style")
                      DW_AT_decl_file	("/Applications/Xcode_11.7.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/limits")
                      DW_AT_decl_line	(249)
                      DW_AT_external	(true)
                      DW_AT_declaration	(true)
                      DW_AT_accessibility	(DW_ACCESS_protected)
3

For situations like this I think it would be best to use -fdebug-prefix-map to replace all occurrences of the sysroot with a placeholder such as $SDKROOT and then modify the DBGSourcePathRemapping dictionary in the .dSYM bundle to automatically change it back to a location that makes sense on the developer's machine. (See also my summary in 44213 – DW_AT_LLVM_isysroot isn't useful which I think is mostly complete now).

4

Sorry! I replied before I finished my morning coffee.

This of course correct. As of 5.3, LLDB effectively ignores the concrete value of the sysroot attribute (it will search for a local, compatible SDK) so the last step of remapping it is not necessary! You might still want to remap the sysroot on the build server to get reproducible results though.

1 Like
5

Gotcha, thanks! So we can remap to $CLANG_SYSROOT or something like that for hermeticity.

From my second post we also see paths of the form DW_AT_decl_file ("/Applications/Xcode_11.7.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/limits") for Clang. We'll need to remap $DEVELOPER_DIR or $TOOLCHAIN for hermeticity and then remap it again for the debugger?

6

This is what I referred to as the Clang resource dir in the llvm bugreport. We should probably use a similar scheme for it, but we don't have the automatic support yet that we have for the SDK. So, yes, you'll have to remap this first to a recognizable token and then do the reverse mapping on the client (e.g., in the dSYM dictionary).

7

Ah, gotcha, did you mean Clang's resource dir?

❯ xcrun clang --print-resource-dir
/Applications/Xcode_12.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/12.0.0

Which seems to be a bit different (usr/lib), so I think we might just go ahead and remap DEVELOPER_DIR itself although maybe it should be the toolchain path.

8

Oh. Thanks for pointing that out! I didn't realize that libc++ was not in the resource dir but rather installed alongside Clang. $TOOLCHAIN_ROOT or something would be more appropriate it seems.