[lldb] Move host platform implementations into the base classAbout half of our host platform code was implemented in the Platformclass, while the rest was it RemoteAwarePlatform. Most of the time,
[lldb] Move host platform implementations into the base classAbout half of our host platform code was implemented in the Platformclass, while the rest was it RemoteAwarePlatform. Most of the time, thisdid not matter, as nearly all our platforms are alsoRemoteAwarePlatforms. It makes a difference for PlatformQemu, whichdescends directly from the base class (as it is local-only).This patch moves all host code paths into the base class, and marksPlatformQemu as a "host" platform so it can make use of them (it soundsslightly strange, but that is consistent with what the apple simulatorplatforms are doing). Not all of the host implementations make sense forthis platform, but it can always override those that don't.I add some basic tests using the platform file apis to exercise thisfunctionality.Differential Revision: https://reviews.llvm.org/D122898
show more ...
[lldb] Plumb process host architecture through platform selectionTo allow us to select a different platform based on where the process isrunning, plumb the process host architecture through platfo
[lldb] Plumb process host architecture through platform selectionTo allow us to select a different platform based on where the process isrunning, plumb the process host architecture through platform selection.This patch is in preparation for D121444 which needs this functionalityto tell apart iOS binaries running on Apple Silicon vs on a remote iOSdevice.Differential revision: https://reviews.llvm.org/D121484
[lldb/host] Remove monitor_signals argument from process monitoring functionsAll current callers set the argument to false. monitor_signals=true usedto be used in the Process plugins (which needed
[lldb/host] Remove monitor_signals argument from process monitoring functionsAll current callers set the argument to false. monitor_signals=true usedto be used in the Process plugins (which needed to know when thedebugged process gets a signal), but this implementation has severalserious issues, which means that individual process plugins noworchestrate the monitoring of debugged processes themselves.This allows us to simplify the implementation (no need to play withprocess groups), and the interface (we only catch fatal events, so thecallback is always called just once).Differential Revision: https://reviews.llvm.org/D120425
[lldb] Fix race condition between lldb-vscode and stop hooks executorThe race is between these two pieces of code that are executed in two separatelldb-vscode threads (the first is in the main thr
[lldb] Fix race condition between lldb-vscode and stop hooks executorThe race is between these two pieces of code that are executed in two separatelldb-vscode threads (the first is in the main thread and another is in theevent-handling thread):```// lldb-vscode.cppg_vsc.debugger.SetAsync(false);g_vsc.target.Launch(launch_info, error);g_vsc.debugger.SetAsync(true);``````// Target.cppbool old_async = debugger.GetAsyncExecution();debugger.SetAsyncExecution(true);debugger.GetCommandInterpreter().HandleCommands(GetCommands(), exc_ctx, options, result);debugger.SetAsyncExecution(old_async);```The sequence that leads to the bug is this one:1. Main thread enables synchronous mode and launches the process.2. When the process is launched, it generates the first stop event.3. This stop event is catched by the event-handling thread and DoOnRemoval is invoked.4. Inside DoOnRemoval, this thread runs stop hooks. And before running stop hooks, the current synchronization mode is stored into old_async (and right now it is equal to "false").5. The main thread finishes the launch and returns to lldb-vscode, the synchronization mode is restored to asynchronous by lldb-vscode.6. Event-handling thread finishes stop hooks processing and restores the synchronization mode according to old_async (i.e. makes the mode synchronous)7. And now the mode is synchronous while lldb-vscode expects it to be asynchronous. Synchronous mode forbids the process to broadcast public stop events, so, VS Code just hangs because lldb-vscode doesn't notify it about stops.So, this diff makes the target intercept the first stop event if the process islaunched in the synchronous mode, thus preventing stop hooks execution.The bug is only present on Windows because other platforms alreadyintercept this event using their own hijacking listeners.So, this diff also fixes some problems with lldb-vscode tests on Windows to makeit possible to run the related test. Other tests still can't be enabled becausethe debugged program prints something into stdout and LLDB can't intercept thisoutput and redirect it to lldb-vscode properly.Reviewed By: jinghamDifferential Revision: https://reviews.llvm.org/D119548
[lldb] Rename Logging.h to LLDBLog.h and clean up includesMost of our code was including Log.h even though that is not where the"lldb" log channel is defined (Log.h defines the generic logginginf
[lldb] Rename Logging.h to LLDBLog.h and clean up includesMost of our code was including Log.h even though that is not where the"lldb" log channel is defined (Log.h defines the generic logginginfrastructure). This worked because Log.h included Logging.h, eventhough it should.After the recent refactor, it became impossible the two files includeeach other in this direction (the opposite inclusion is needed), so thispatch removes the workaround that was put in place and cleans up allfiles to include the right thing. It also renames the file to LLDBLog tobetter reflect its purpose.
[lldb] Convert "LLDB" log channel to the new API
[lldb/qemu] Implement GetMmapArgumentListBy forwarding it to the host platform.
[lldb/qemu] Set qemu's "ld prefix" based on the platform sysrootBoth serve the same purpose (finding shared libraries) and allow one tolaunch a dynamically linked executable by just specifying the
[lldb/qemu] Set qemu's "ld prefix" based on the platform sysrootBoth serve the same purpose (finding shared libraries) and allow one tolaunch a dynamically linked executable by just specifying the platformsysroot.
[lldb/qemu] Support setting arg0 of the debugged programJust what it says on the box.
[lldb/qemu] More flexible emulator specificationThis small patch adds two useful improvements:- allows one to specify the emulator path as a bare filename, and have it be looked up in the PATH-
[lldb/qemu] More flexible emulator specificationThis small patch adds two useful improvements:- allows one to specify the emulator path as a bare filename, and have it be looked up in the PATH- allows one to leave the path empty and have the filename be derived from the architecture.
[lldb/qemu] Add emulator-env-vars settingThis setting is for variables we want to pass to the emulator only --then will be automatically removed from the target environment by ourenvironment diff
[lldb/qemu] Add emulator-env-vars settingThis setting is for variables we want to pass to the emulator only --then will be automatically removed from the target environment by ourenvironment diffing code. This variable can be used to pass variousQEMU_*** variables (although most of these can be passed throughemulator-args as well), as well as any other variables that can affectthe operation of the emulator (e.g. LD_LIBRARY_PATH).
[lldb/qemu] Sort entries in QEMU_(UN)SET_ENVThe test for this functionality was failing on the darwin bot, becausethe entries came out in opposite order. While this does not impactfunctionality,
[lldb/qemu] Sort entries in QEMU_(UN)SET_ENVThe test for this functionality was failing on the darwin bot, becausethe entries came out in opposite order. While this does not impactfunctionality, and the algorithm that produces it is technicallydeterministic (the nondeterminism comes from the contents of the hostenvironment), it seems like it would be more user-friendly if theentries came out in a more predictible order.Therefore I am adding the sort call to the actual code instead ofrelaxing test expectations.
[lldb/qemu] Separate host and target environmentsQemu normally forwards its (host) environment variables to the emulatedprocess. While this works fine for most variables, there are some (few, but
[lldb/qemu] Separate host and target environmentsQemu normally forwards its (host) environment variables to the emulatedprocess. While this works fine for most variables, there are some (few, butfairly important) variables where this is not possible. LD_LIBRARY_PATHis the probably the most important of those -- we don't want the librarysearch path for the emulated libraries to interfere with the librariesthat 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. Thispatch makes use of that functionality to pass any user-providedvariables to the emulated process. Since we're piggy-backing on thenormal lldb environment-handling mechanism, all the usual mechanism toprovide environment (target.env-vars setting, SBLaunchInfo, etc.) workout-of-the-box, and the only thing we need to do is to properlyconstruct the qemu environment variables.This patch also adds a new setting -- target-env-vars, which representsenvironment variables which are added (on top of the host environment)to the default launch environments of all (qemu) targets. The reason forits existence is to enable the configuration (e.g., from a startupscript) of the default launch environment, before any target is created.The idea is that this would contain the variables (like theaforementioned LD_LIBRARY_PATH) common to all targets being debugged onthe given system. The user is, of course, free to customize theenvironment for a particular target in the usual manner.The reason I do not want to use/recommend the "global" version of thetarget.env-vars setting for this purpose is that the setting would applyto all targets, whereas the settings (their values) I have mentionedwould be specific to the given platform.Differential Revision: https://reviews.llvm.org/D115246
[lldb/qemu] Add emulator-args settingThis setting allows the user to pass additional arguments to the qemu instance.While we may want to introduce dedicated settings for the most common qemuargum
[lldb/qemu] Add emulator-args settingThis setting allows the user to pass additional arguments to the qemu instance.While we may want to introduce dedicated settings for the most common qemuarguments (-cpu, for one), having this setting allows us to avoid creating asetting for every possible argument.Differential Revision: https://reviews.llvm.org/D115151
[lldb/qemu] Add support for pty redirectionLldb uses a pty to read/write to the standard input and output of thedebugged process. For host processes this would be automatically set upby Target::F
[lldb/qemu] Add support for pty redirectionLldb uses a pty to read/write to the standard input and output of thedebugged process. For host processes this would be automatically set upby Target::FinalizeFileActions. The Qemu platform is in a uniqueposition of not really being a host platform, but not being remoteeither. It reports IsHost() = false, but it is sufficiently host-likethat we can use the usual pty mechanism.This patch adds the necessary glue code to enable pty redirection. Itincludes a small refactor of Target::FinalizeFileActions andProcessLaunchInfo::SetUpPtyRedirection to reduce the amount ofboilerplate that would need to be copied.I will note that qemu is not able to separate output from the emulatedprogram from the output of the emulator itself, so the two will arriveintertwined. Normally this should not be a problem since qemu should notproduce any output during regular operation, but some output can slipthrough in case of errors. This situation should be pretty obvious (to ahuman), and it is the best we can do anyway.For testing purposes, and inspired by lldb-server tests, I have extendedthe mock emulator with the ability "program" the behavior of the"emulated" program via command-line arguments.Differential Revision: https://reviews.llvm.org/D114796
[lldb] Introduce PlatformQemuUserThis 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 PlatformQemuUserThis 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 threadon lldb-dev<https://lists.llvm.org/pipermail/lldb-dev/2021-October/017106.html>.)This initial patch implements the necessary boilerplate as well as theminimal amount of functionality needed to actually be able to dosomething useful (which, in this case means debugging a fully staticallylinked executable).The knobs necessary to emulate dynamically linked programs, as well asto control other aspects of qemu operation (the emulated cpu, forinstance) will be added in subsequent patches. Same goes for the abilityto 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 emulatorEven though this patch is relatively small, it doesn't lack subtletiesthat 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