[all-commits] [llvm/llvm-project] 611fdd: [lldb/qemu] Add emulator-args setting

[Pavel Labath via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 611fdde4c765d1ed213744263cb2bbc04bd5060c
      https://github.com/llvm/llvm-project/commit/611fdde4c765d1ed213744263cb2bbc04bd5060c
  Author: Pavel Labath <pavel at labath.sk>
  Date:   2021-12-07 (Tue, 07 Dec 2021)

  Changed paths:
    M lldb/source/Plugins/Platform/QemuUser/PlatformQemuUser.cpp
    M lldb/source/Plugins/Platform/QemuUser/PlatformQemuUserProperties.td
    M lldb/test/API/qemu/TestQemuLaunch.py
    M lldb/test/API/qemu/qemu.py

  Log Message:
  -----------
  [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


  Commit: d4083a296ac828440604574e7a9fac70ede96d66
      https://github.com/llvm/llvm-project/commit/d4083a296ac828440604574e7a9fac70ede96d66
  Author: Pavel Labath <pavel at labath.sk>
  Date:   2021-12-07 (Tue, 07 Dec 2021)

  Changed paths:
    M lldb/test/API/qemu/qemu.py

  Log Message:
  -----------
  [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.


Compare: https://github.com/llvm/llvm-project/compare/61ba9f9110e2...d4083a296ac8