Revision tags: llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5 |
|
#
2238dcc3 |
| 25-May-2023 |
Jonas Devlieghere <jonas@devlieghere.com> |
[NFC][Py Reformat] Reformat python files in lldb
This is an ongoing series of commits that are reformatting our Python code. Reformatting is done with `black` (23.1.0).
If you end up having problem
[NFC][Py Reformat] Reformat python files in lldb
This is an ongoing series of commits that are reformatting our Python code. Reformatting is done with `black` (23.1.0).
If you end up having problems merging this commit because you have made changes to a python file, the best way to handle that is to run `git checkout --ours <yourfile>` and then reformat it with black.
RFC: https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style
Differential revision: https://reviews.llvm.org/D151460
show more ...
|
Revision tags: llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, working, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init, llvmorg-14.0.6, llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1, llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1, llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2 |
|
#
249a5fb0 |
| 30-Dec-2021 |
Pavel Labath <pavel@labath.sk> |
[lldb/qemu] Support setting arg0 of the debugged program
Just what it says on the box.
|
#
45aa4356 |
| 29-Nov-2021 |
Pavel Labath <pavel@labath.sk> |
[lldb/qemu] Separate host and target environments
Qemu normally forwards its (host) environment variables to the emulated process. While this works fine for most variables, there are some (few, but
[lldb/qemu] Separate host and target environments
Qemu normally forwards its (host) environment variables to the emulated process. While this works fine for most variables, there are some (few, but fairly important) variables where this is not possible. LD_LIBRARY_PATH is the probably the most important of those -- we don't want the library search path for the emulated libraries to interfere with the libraries that the emulator itself needs.
For this reason, qemu provides a mechanism (QEMU_SET_ENV, QEMU_UNSET_ENV) to set variables only for the emulated process. This patch makes use of that functionality to pass any user-provided variables to the emulated process. Since we're piggy-backing on the normal lldb environment-handling mechanism, all the usual mechanism to provide environment (target.env-vars setting, SBLaunchInfo, etc.) work out-of-the-box, and the only thing we need to do is to properly construct the qemu environment variables.
This patch also adds a new setting -- target-env-vars, which represents environment variables which are added (on top of the host environment) to the default launch environments of all (qemu) targets. The reason for its existence is to enable the configuration (e.g., from a startup script) of the default launch environment, before any target is created. The idea is that this would contain the variables (like the aforementioned LD_LIBRARY_PATH) common to all targets being debugged on the given system. The user is, of course, free to customize the environment for a particular target in the usual manner.
The reason I do not want to use/recommend the "global" version of the target.env-vars setting for this purpose is that the setting would apply to all targets, whereas the settings (their values) I have mentioned would be specific to the given platform.
Differential Revision: https://reviews.llvm.org/D115246
show more ...
|
#
d4083a29 |
| 07-Dec-2021 |
Pavel Labath <pavel@labath.sk> |
[lldb] Fix flakyness in TestQemuLaunch.test_stdio_redirect
The test was flaky because it was trying to read from the (redirected) stdout file before the data was been flushed to it. This would not b
[lldb] Fix flakyness in TestQemuLaunch.test_stdio_redirect
The test was flaky because it was trying to read from the (redirected) stdout file before the data was been flushed to it. This would not be a problem for a "normal" debug session, but since here the emulator and the target binary coexist in the same process (and this is true both for real qemu and our fake implementation), there is a window of time between the stub returning an exit packet (which is the event that the test is waiting for) and the process really exiting (which is when the normal flushing happens).
This patch adds an explicit flush to work around this. Theoretically, it's possible that real code could run into this issue as well, but such a use case is not very likely. If we wanted to fix this for real, we could add some code which waits for the host process to terminate (in addition to receiving the termination packet), but this is somewhat complicated by the fact that this code lives in the gdb-remote process plugin.
show more ...
|
#
611fdde4 |
| 26-Nov-2021 |
Pavel Labath <pavel@labath.sk> |
[lldb/qemu] Add emulator-args setting
This setting allows the user to pass additional arguments to the qemu instance. While we may want to introduce dedicated settings for the most common qemu argum
[lldb/qemu] Add emulator-args setting
This setting allows the user to pass additional arguments to the qemu instance. While we may want to introduce dedicated settings for the most common qemu arguments (-cpu, for one), having this setting allows us to avoid creating a setting for every possible argument.
Differential Revision: https://reviews.llvm.org/D115151
show more ...
|
#
5c4cb323 |
| 26-Nov-2021 |
Pavel Labath <pavel@labath.sk> |
[lldb/qemu] Add support for pty redirection
Lldb uses a pty to read/write to the standard input and output of the debugged process. For host processes this would be automatically set up by Target::F
[lldb/qemu] Add support for pty redirection
Lldb uses a pty to read/write to the standard input and output of the debugged process. For host processes this would be automatically set up by Target::FinalizeFileActions. The Qemu platform is in a unique position of not really being a host platform, but not being remote either. It reports IsHost() = false, but it is sufficiently host-like that we can use the usual pty mechanism.
This patch adds the necessary glue code to enable pty redirection. It includes a small refactor of Target::FinalizeFileActions and ProcessLaunchInfo::SetUpPtyRedirection to reduce the amount of boilerplate that would need to be copied.
I will note that qemu is not able to separate output from the emulated program from the output of the emulator itself, so the two will arrive intertwined. Normally this should not be a problem since qemu should not produce any output during regular operation, but some output can slip through in case of errors. This situation should be pretty obvious (to a human), and it is the best we can do anyway.
For testing purposes, and inspired by lldb-server tests, I have extended the mock emulator with the ability "program" the behavior of the "emulated" program via command-line arguments.
Differential Revision: https://reviews.llvm.org/D114796
show more ...
|
Revision tags: llvmorg-13.0.1-rc1 |
|
#
14086849 |
| 11-Nov-2021 |
Pavel Labath <pavel@labath.sk> |
[lldb] Introduce PlatformQemuUser
This adds a new platform class, whose job is to enable running (debugging) executables under qemu.
(For general information about qemu, I recommend reading the RFC
[lldb] Introduce PlatformQemuUser
This adds a new platform class, whose job is to enable running (debugging) executables under qemu.
(For general information about qemu, I recommend reading the RFC thread on lldb-dev <https://lists.llvm.org/pipermail/lldb-dev/2021-October/017106.html>.)
This initial patch implements the necessary boilerplate as well as the minimal amount of functionality needed to actually be able to do something useful (which, in this case means debugging a fully statically linked executable).
The knobs necessary to emulate dynamically linked programs, as well as to control other aspects of qemu operation (the emulated cpu, for instance) will be added in subsequent patches. Same goes for the ability to automatically bind to the executables of the emulated architecture.
Currently only two settings are available: - architecture: the architecture that we should emulate - emulator-path: the path to the emulator
Even though this patch is relatively small, it doesn't lack subtleties that are worth calling out explicitly: - named sockets: qemu supports tcp and unix socket connections, both of them in the "forward connect" mode (qemu listening, lldb connecting). Forward TCP connections are impossible to realise in a race-free way. This is the reason why I chose unix sockets as they have larger, more structured names, which can guarantee that there are no collisions between concurrent connection attempts. - the above means that this code will not work on windows. I don't think that's an issue since user mode qemu does not support windows anyway. - Right now, I am leaving the code enabled for windows, but maybe it would be better to disable it (otoh, disabling it means windows developers can't check they don't break it) - qemu-user also does not support macOS, so one could contemplate disabling it there too. However, macOS does support named sockets, so one can even run the (mock) qemu tests there, and I think it'd be a shame to lose that.
Differential Revision: https://reviews.llvm.org/D114509
show more ...
|