Page MenuHomePhabricator

[lldb/utils] Add the lldb-env tool
AbandonedPublic

Authored by vsk on Oct 27 2020, 5:42 PM.

Details

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'

Diff Detail

Event Timeline

vsk created this revision.Oct 27 2020, 5:42 PM
Herald added a project: Restricted Project. · View Herald TranscriptOct 27 2020, 5:42 PM
vsk requested review of this revision.Oct 27 2020, 5:42 PM

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 added a comment.Oct 27 2020, 6:26 PM

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.

In D90276#2358016, @vsk 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 added a comment.Oct 28 2020, 9:45 AM

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 abandoned this revision.Oct 28 2020, 11:17 AM

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.