[lldb/utils] Add the lldb-env tool

[vsk]

Summary

Introduce lldb-env, a tool that prints out the environment variables
needed to launch lldb.

Usually, no environment variables need to be set to launch lldb: in
these cases lldb-env prints nothing.

In a sanitized build, lldb-env prints out any mandatory DYLD_* options
needed to set up sanitizer interceptors early. The Darwin-specific logic
is just a starting point. The end goal would be to support launching
lldb on any platform via export $(path/to/lldb-env); path/to/lldb. The
current logic is taken/moved from test/API/lit.cfg. As a follow-up, we
could have lldb-dotest use lldb-env as well.

Testing: check-lldb with LLVM_USE_SANITIZER='Address'

[JDevlieghere]

Can you explain the added value of the tool a bit more. I can see how it's nice to be able to run export $(lldb-env); path/to/lldb but I wonder how often you'd end up doing that. When I invoke lldb directly, it's mostly to debug a test case, in which case I'd need to run lldb under lldb and set the environment variables myself. It also means we have to configure an additional file which goes against my effort of making the lit.site.cfg file self contained (to be able to run the test suite against a different toolchain).

FWIW my plan was to deprecate lldb-dotest at some in favor of either using llvm-lit directly or by wrapping it. I hate maintaining the code in lldb-dotest/CMakeLists.txt because I always break the standalone build when I forget to add a variable.

[vsk]

In D90276#2357978, @JDevlieghere wrote:

Can you explain the added value of the tool a bit more. I can see how it's nice to be able to run export $(lldb-env); path/to/lldb but I wonder how often you'd end up doing that. When I invoke lldb directly, it's mostly to debug a test case, in which case I'd need to run lldb under lldb and set the environment variables myself. It also means we have to configure an additional file which goes against my effort of making the lit.site.cfg file self contained (to be able to run the test suite against a different toolchain).

The specific workflow I'm interested in is invoking lldb on a test program, then importing a script to drive a debug session in CI. Having the settings I need defined in one place is nice, this means I can avoid duplicating logic from a lit.cfg in my workflow. It also prevents the settings from getting out of sync (looking at this -- https://github.com/apple/llvm-project/blob/swift/main/lldb/test/Shell/lit.cfg.py#L45).

Re: making the lit.site.cfg self-contained, IIUC the situation is that there are a couple places where we shell out via subprocess, but that you'd like to get rid of these? I wonder whether we could bundle up the necessary scripts along with lit.site.cfg instead.

FWIW my plan was to deprecate lldb-dotest at some in favor of either using llvm-lit directly or by wrapping it. I hate maintaining the code in lldb-dotest/CMakeLists.txt because I always break the standalone build when I forget to add a variable.

My intention was to make sure we get an lldb-env everywhere we already expect a lldb-dotest. If that's not required, I'd be fine with moving the new tool elsewhere.

[JDevlieghere]

In D90276#2358016, @vsk wrote:

In D90276#2357978, @JDevlieghere wrote:

Can you explain the added value of the tool a bit more. I can see how it's nice to be able to run export $(lldb-env); path/to/lldb but I wonder how often you'd end up doing that. When I invoke lldb directly, it's mostly to debug a test case, in which case I'd need to run lldb under lldb and set the environment variables myself. It also means we have to configure an additional file which goes against my effort of making the lit.site.cfg file self contained (to be able to run the test suite against a different toolchain).

The specific workflow I'm interested in is invoking lldb on a test program, then importing a script to drive a debug session in CI. Having the settings I need defined in one place is nice, this means I can avoid duplicating logic from a lit.cfg in my workflow. It also prevents the settings from getting out of sync (looking at this -- https://github.com/apple/llvm-project/blob/swift/main/lldb/test/Shell/lit.cfg.py#L45).

Another way to solve that would be to move it up to the top level lit configuration rather than doing it once for the shell tests and once for the API tests.

Re: making the lit.site.cfg self-contained, IIUC the situation is that there are a couple places where we shell out via subprocess, but that you'd like to get rid of these? I wonder whether we could bundle up the necessary scripts along with lit.site.cfg instead.

My remark was not so much about the need for another tool but rather the need to configure it. Right now I can hand-write a lit.site.cfg.py, omit a bunch of values, and point lit to it. With this tool I'd need to also configure it (i.e. replacing @LLVM_USE_SANITIZER@ and @CMAKE_CXX_COMPILER@. I wonder if there's any way to make lldb-dotest and this tool load the lit.site.cfg.py and use the variables that we put in the config there.

FWIW my plan was to deprecate lldb-dotest at some in favor of either using llvm-lit directly or by wrapping it. I hate maintaining the code in lldb-dotest/CMakeLists.txt because I always break the standalone build when I forget to add a variable.

My intention was to make sure we get an lldb-env everywhere we already expect a lldb-dotest. If that's not required, I'd be fine with moving the new tool elsewhere.

I think that if we were to move this under lldb/test we might get that for free if we use the same @-variable names as the lit.site.cfg.py. I think that'd be a good idea regardless (and also most certainly a different patch).

[vsk]

Re: making the lit.site.cfg self-contained, IIUC the situation is that there are a couple places where we shell out via subprocess, but that you'd like to get rid of these? I wonder whether we could bundle up the necessary scripts along with lit.site.cfg instead.

My remark was not so much about the need for another tool but rather the need to configure it. Right now I can hand-write a lit.site.cfg.py, omit a bunch of values, and point lit to it. With this tool I'd need to also configure it (i.e. replacing @LLVM_USE_SANITIZER@ and @CMAKE_CXX_COMPILER@.

Not sure I follow: why would introducing an lldb-env tool make it necessary for the top-level lit.site.cfg.py to be configured by the build (i.e. why would it preclude using a hand-written lit.site.cfg.py)?

Or: if you meant, the need to configure lldb-env is in and of itself an issue, not sure I follow that either. We rely on other configured files (e.g. the lit.site.cfg.py's) - is the issue that the configuration logic in lldb-dotest/CMakeLists.txt is especially hard to maintain?

I wonder if there's any way to make lldb-dotest and this tool load the lit.site.cfg.py and use the variables that we put in the config there.

I think it's possible. The lit.site.cfg.py we want should have a known location relative to the lldb executable, so an lldb-env tool could import it. Perhaps I'm underestimating the complexity (there are actually at least two possible locations, $(dirname path/to/lldb)/{../tools/lldb/test, ../test}/lit.site.cfg.py).

FWIW my plan was to deprecate lldb-dotest at some in favor of either using llvm-lit directly or by wrapping it. I hate maintaining the code in lldb-dotest/CMakeLists.txt because I always break the standalone build when I forget to add a variable.

My intention was to make sure we get an lldb-env everywhere we already expect a lldb-dotest. If that's not required, I'd be fine with moving the new tool elsewhere.

I think that if we were to move this under lldb/test we might get that for free if we use the same @-variable names as the lit.site.cfg.py. I think that'd be a good idea regardless (and also most certainly a different patch).

I'm not sure what the suggestion is here exactly. Is it to move the lldb-env tool under TEST_EXEC_ROOT? That should work for what I'm trying to do -- from that location, lldb-env can look up all the build info it needs by importing the adjacent lit.site.cfg.py, without needing to be configured.

Happy to rework things, ultimately I'm just looking for a reliable/consistent way to invoke bin/lldb without "being" a test. Also happy to discuss further offline: it may turn out that we don't really want/need to support running the just-built lldb outside of test/. After all we're interested in setting up a test in CI that runs the lldb driver -- perhaps this can just live in lldb/test/Shell.

[vsk]

Jonas walked me through some of the issues here offline:

• Looks like this makes testing depend on having a configured lldb-env tool, this will make it hard to run testing against an lldb root.
• If we need to launch ./bin/lldb in some other workflow, we can consider having lldb-env derive all the info it needs from a root lit.site.cfg.py.

lldb/test/API/lit.cfg.py

try:
     os.makedirs(path)
   except OSError as e:
     if e.errno != errno.EEXIST:
       raise
   if not os.path.isdir(path):
     raise OSError(errno.ENOTDIR, "%s is not a directory"%path)
 
 
-def find_sanitizer_runtime(name):
-  resource_dir = subprocess.check_output(
-      [config.cmake_cxx_compiler,
-       '-print-resource-dir']).decode('utf-8').strip()
-  return os.path.join(resource_dir, 'lib', 'darwin', name)
-
-
 def find_shlibpath_var():
   if platform.system() in ['Linux', 'FreeBSD', 'NetBSD', 'SunOS']:
     yield 'LD_LIBRARY_PATH'
   elif platform.system() == 'Darwin':
     yield 'DYLD_LIBRARY_PATH'
   elif platform.system() == 'Windows':
     yield 'PATH'
 
def delete_module_cache(path):
 
   This is necessary in an incremental build whenever clang changes underneath,
   so doing it once per lit.py invocation is close enough. """
   if os.path.isdir(path):
     print("Deleting module cache at %s." % path)
     shutil.rmtree(path)
 
 if is_configured('llvm_use_sanitizer'):
-  if 'Address' in config.llvm_use_sanitizer:
-    config.environment['ASAN_OPTIONS'] = 'detect_stack_use_after_return=1'
-    if 'Darwin' in config.host_os and 'x86' in config.host_triple:
-      config.environment['DYLD_INSERT_LIBRARIES'] = find_sanitizer_runtime(
-          'libclang_rt.asan_osx_dynamic.dylib')
-
-  if 'Thread' in config.llvm_use_sanitizer:
-    if 'Darwin' in config.host_os and 'x86' in config.host_triple:
-      config.environment['DYLD_INSERT_LIBRARIES'] = find_sanitizer_runtime(
-          'libclang_rt.tsan_osx_dynamic.dylib')
+  lldb_env_path = os.path.join(os.path.dirname(config.lldb_executable),
+                               'lldb-env')
+  cmd = [config.python_executable, lldb_env_path]
+  env_vars = subprocess.check_output(cmd).decode('utf-8').split('\n')
+  for env_var in env_vars:
+    varname, _, val = env_var.partition('=')
+    config.environment[varname] = val
 
 if 'DYLD_INSERT_LIBRARIES' in config.environment and platform.system() == 'Darwin':
   config.python_executable = find_python_interpreter()
 
 # Shared library build of LLVM may require LD_LIBRARY_PATH or equivalent.
 if is_configured('shared_libs'):
   for shlibpath_var in find_shlibpath_var():
     # In stand-alone build llvm_shlib_dir specifies LLDB's lib directory while

lldb/test/CMakeLists.txt

 if(TARGET liblldb)
   add_lldb_test_dependency(liblldb)
 endif()
 
 if(TARGET lldb-framework)
   add_lldb_test_dependency(lldb-framework)
 endif()
 
+if(TARGET lldb-env)
+  add_lldb_test_dependency(lldb-env)
+endif()
+
 # Add dependencies that are not exported targets when building standalone.
 if(NOT LLDB_BUILT_STANDALONE)
   add_lldb_test_dependency(
     FileCheck
     count
     dsymutil
     llvm-strip
     not

lldb/utils/lldb-dotest/CMakeLists.txt

+# Make lldb-env a custom target.
+add_custom_target(lldb-env)
+set_target_properties(lldb-env PROPERTIES FOLDER "lldb utils")
+
 # Make lldb-dotest a custom target.
 add_custom_target(lldb-dotest)
 add_dependencies(lldb-dotest lldb-test-deps)
 set_target_properties(lldb-dotest PROPERTIES FOLDER "lldb utils")
 
 get_property(LLDB_DOTEST_ARGS GLOBAL PROPERTY LLDB_DOTEST_ARGS_PROPERTY)
 set(LLDB_LIBS_DIR "${LLVM_LIBRARY_OUTPUT_INTDIR}")
 
else()
       string(REPLACE ${CMAKE_CFG_INTDIR} "." LLDB_TEST_SERVER_CONFIGURED "${LLDB_TEST_SERVER}")
       string(REPLACE ${CMAKE_CFG_INTDIR} "." LLDB_LIBS_DIR_CONFIGURED "${LLDB_LIBS_DIR}")
     endif()
 
     configure_file(
       lldb-dotest.in
       ${config_runtime_output_dir}/lldb-dotest @ONLY
     )
+    configure_file(
+      lldb-env.in
+      ${config_runtime_output_dir}/lldb-env @ONLY
+    )
   endforeach()
 elseif(NOT "${CMAKE_CFG_INTDIR}" STREQUAL ".")
   foreach(LLVM_BUILD_MODE ${CMAKE_CONFIGURATION_TYPES})
     string(REPLACE ${CMAKE_CFG_INTDIR} ${LLVM_BUILD_MODE} LLDB_DOTEST_DIR ${LLVM_RUNTIME_OUTPUT_INTDIR})
     string(REPLACE ${CMAKE_CFG_INTDIR} ${LLVM_BUILD_MODE} LLDB_DOTEST_ARGS_CONFIGURED "${LLDB_DOTEST_ARGS}")
     string(REPLACE ${CMAKE_CFG_INTDIR} ${LLVM_BUILD_MODE} LLDB_SOURCE_DIR_CONFIGURED "${LLDB_SOURCE_DIR}")
     string(REPLACE ${CMAKE_CFG_INTDIR} ${LLVM_BUILD_MODE} LLDB_FRAMEWORK_DIR_CONFIGURED "${LLDB_FRAMEWORK_DIR}")
     string(REPLACE ${CMAKE_CFG_INTDIR} ${LLVM_BUILD_MODE} LLDB_TEST_BUILD_DIRECTORY_CONFIGURED "${LLDB_TEST_BUILD_DIRECTORY}")
     string(REPLACE ${CMAKE_CFG_INTDIR} ${LLVM_BUILD_MODE} LLDB_TEST_TRACE_DIRECTORY_CONFIGURED "${LLDB_TEST_TRACE_DIRECTORY}")
     string(REPLACE ${CMAKE_CFG_INTDIR} ${LLVM_BUILD_MODE} LLDB_TEST_EXECUTABLE_CONFIGURED "${LLDB_TEST_EXECUTABLE}")
     string(REPLACE ${CMAKE_CFG_INTDIR} ${LLVM_BUILD_MODE} LLDB_TEST_COMPILER_CONFIGURED "${LLDB_TEST_COMPILER}")
     string(REPLACE ${CMAKE_CFG_INTDIR} ${LLVM_BUILD_MODE} LLDB_TEST_DSYMUTIL_CONFIGURED "${LLDB_TEST_DSYMUTIL}")
     string(REPLACE ${CMAKE_CFG_INTDIR} ${LLVM_BUILD_MODE} LLDB_TEST_FILECHECK_CONFIGURED "${LLDB_TEST_FILECHECK}")
     string(REPLACE ${CMAKE_CFG_INTDIR} ${LLVM_BUILD_MODE} LLDB_TEST_YAML2OBJ_CONFIGURED "${LLDB_TEST_YAML2OBJ}")
     string(REPLACE ${CMAKE_CFG_INTDIR} ${LLVM_BUILD_MODE} LLDB_TEST_SERVER_CONFIGURED "${LLDB_TEST_SERVER}")
     string(REPLACE ${CMAKE_CFG_INTDIR} ${LLVM_BUILD_MODE} LLDB_LIBS_DIR_CONFIGURED "${LLDB_LIBS_DIR}")
 
     configure_file(
       lldb-dotest.in
       ${LLDB_DOTEST_DIR}/lldb-dotest
       )
+    configure_file(
+      lldb-env.in
+      ${LLDB_DOTEST_DIR}/lldb-env
+      )
   endforeach()
 else()
   set(LLDB_DOTEST_ARGS_CONFIGURED "${LLDB_DOTEST_ARGS}")
   set(LLDB_SOURCE_DIR_CONFIGURED "${LLDB_SOURCE_DIR}")
   set(LLDB_FRAMEWORK_DIR_CONFIGURED "${LLDB_FRAMEWORK_DIR}")
   set(LLDB_TEST_BUILD_DIRECTORY_CONFIGURED "${LLDB_TEST_BUILD_DIRECTORY}")
   set(LLDB_TEST_TRACE_DIRECTORY_CONFIGURED "${LLDB_TEST_TRACE_DIRECTORY}")
   set(LLDB_TEST_EXECUTABLE_CONFIGURED "${LLDB_TEST_EXECUTABLE}")
   set(LLDB_TEST_COMPILER_CONFIGURED "${LLDB_TEST_COMPILER}")
   set(LLDB_TEST_DSYMUTIL_CONFIGURED "${LLDB_TEST_DSYMUTIL}")
   set(LLDB_TEST_FILECHECK_CONFIGURED "${LLDB_TEST_FILECHECK}")
   set(LLDB_TEST_YAML2OBJ_CONFIGURED "${LLDB_TEST_YAML2OBJ}")
   set(LLDB_TEST_SERVER_CONFIGURED "${LLDB_TEST_SERVER}")
   set(LLDB_LIBS_DIR_CONFIGURED "${LLDB_LIBS_DIR}")
 
   configure_file(
     lldb-dotest.in
     ${LLVM_RUNTIME_OUTPUT_INTDIR}/lldb-dotest
     )
+  configure_file(
+    lldb-env.in
+    ${LLVM_RUNTIME_OUTPUT_INTDIR}/lldb-env
+    )
 endif()

lldb/utils/lldb-dotest/lldb-env.in

+#!@Python3_EXECUTABLE@
+import os
+import platform
+import subprocess
+import sys
+
+llvm_use_sanitizer = "@LLVM_USE_SANITIZER@"
+compiler = '@CMAKE_CXX_COMPILER@'
+
+def get_dyld_option_for_sanitizer(name):
+    # FIXME: Get the host OS from cmake, instead of assuming macOS.
+    resource_dir = subprocess.check_output(
+        [compiler, '-print-resource-dir']).decode('utf-8').strip()
+    rt_path = os.path.join(resource_dir, 'lib', 'darwin',
+                           'libclang_rt.{0}_osx_dynamic.dylib'.format(name))
+    return 'DYLD_INSERT_LIBRARIES={0}'.format(rt_path)
+
+if __name__ == '__main__':
+    env_vars = []
+
+    asan_enabled = 'Address' in llvm_use_sanitizer
+    tsan_enabled = 'Thread' in llvm_use_sanitizer
+
+    if asan_enabled:
+        env_vars.append("ASAN_OPTIONS='detect_stack_use_after_return=1'")
+
+    if platform.system() == 'Darwin':
+        if asan_enabled:
+            env_vars.append(get_dyld_option_for_sanitizer('asan'))
+
+        if tsan_enabled:
+            env_vars.append(get_dyld_option_for_sanitizer('tsan'))
+
+    if len(env_vars):
+        print('\n'.join(env_vars))
+
+    sys.exit(0)