[all-commits] [llvm/llvm-project] 9e1409: [lldb] [Process/FreeBSDRemote] Handle exec() from ...

[Michał Górny via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: 9e1409aa1e0bb1963757941cf4db539147614fbf
      https://github.com/llvm/llvm-project/commit/9e1409aa1e0bb1963757941cf4db539147614fbf
  Author: Michał Górny <mgorny at moritz.systems>
  Date:   2020-11-09 (Mon, 09 Nov 2020)

  Changed paths:
    M lldb/source/Plugins/Process/FreeBSDRemote/NativeProcessFreeBSD.cpp
    M lldb/test/API/functionalities/exec/TestExec.py

  Log Message:
  -----------
  [lldb] [Process/FreeBSDRemote] Handle exec() from inferior

Differential Revision: https://reviews.llvm.org/D90938


  Commit: 7e2ef84fe7232368f92ec0835c3eda869c85a445
      https://github.com/llvm/llvm-project/commit/7e2ef84fe7232368f92ec0835c3eda869c85a445
  Author: Michał Górny <mgorny at moritz.systems>
  Date:   2020-11-09 (Mon, 09 Nov 2020)

  Changed paths:
    M lldb/test/API/commands/watchpoints/multiple_threads/TestWatchpointMultipleThreads.py
    M lldb/test/API/commands/watchpoints/multiple_threads/main.cpp

  Log Message:
  -----------
  [lldb] [test] Extend watchpoint test to wait for thread to start

TestWatchpointMultipleThreads currently accounts for two scenarios:
setting the watchpoint before a new thread starts (presumably, verifying
that it will be propagated to the new thread) and setting it after
the thread starts (presumably, verifying that a new watchpoint is set
on all threads).  However, the latter test currently assumes that
the thread will be reported to the debugger before the breakpoint is
hit.  This is not the case on FreeBSD and NetBSD.

On NetBSD, new threads do not inherit debug registers from their parent
threads.  Instead, LLDB copies them manually after the new thread is
reported.  Since the thread is actually reported after the second
breakpoint location, both tests effectively check the same behavior
(i.e. watchpoint being set before the new thread is reported).

On FreeBSD, new threads inherit debug registers and we seem to hit
an interesting race condition.  While the thread is reported after
the breakpoint is hit, the kernel seems to construct it and copy
the debug register before that happens.  As a result, setting
the watchpoint at the second breakpoint location modifies the debug
registers of the first thread after they have been copied to the second
thread but before the debugger is aware of it.  Therefore,
the watchpoint is not propagated to the second thread and the test
fails.

Extend the test to cover all three possible scenarios: setting
watchpoint before the thread is lanched, after it is launched but before
it is guaranteed to have started and after it has actually started.  Add
a second barrier to account for the last case.  This should ensure that
the second assumption (i.e. that the watchpoint is set on all currently
known threads) is actually tested on FreeBSD and NetBSD.

Differential Revision: https://reviews.llvm.org/D91030


  Commit: fce8e758892f0b650762513680adc06cea53d6e3
      https://github.com/llvm/llvm-project/commit/fce8e758892f0b650762513680adc06cea53d6e3
  Author: Michał Górny <mgorny at moritz.systems>
  Date:   2020-11-09 (Mon, 09 Nov 2020)

  Changed paths:
    M lldb/source/Host/freebsd/Host.cpp
    M lldb/test/API/commands/platform/process/list/TestProcessList.py

  Log Message:
  -----------
  [lldb] [Host/freebsd] Set Arg0 for 'platform process list -v'

Same fix as in NetBSD (a6712889f5f1702dfa535718abe400d1a83174c5).

Differential Revision: https://reviews.llvm.org/D91012


  Commit: afcdd43bf71d9503dbd2b700710818daafa0cb00
      https://github.com/llvm/llvm-project/commit/afcdd43bf71d9503dbd2b700710818daafa0cb00
  Author: Michał Górny <mgorny at moritz.systems>
  Date:   2020-11-09 (Mon, 09 Nov 2020)

  Changed paths:
    M lldb/test/API/commands/log/basic/TestLogging.py
    M llvm/lib/Support/Unix/Path.inc

  Log Message:
  -----------
  [llvm] [Support] Fix segv if argv0 is null in getMainExecutable()

When LLDB Python bindings are used and stack backtraces are enabled
for logging, getMainExecutable() is called with argv0 being null.
This caused the fallback function getprogpath() (used on FreeBSD, NetBSD
and Linux) to segfault.  Make it handle null executable name gracefully.

Differential Revision: https://reviews.llvm.org/D91012


Compare: https://github.com/llvm/llvm-project/compare/a7a447be0fa9...afcdd43bf71d