[all-commits] [llvm/llvm-project] 8f6ee1: [lldb] Warn when we fail to find dwo/dwp files

[Pavel Labath via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 8f6ee17f22a7575671ad1581231f29947a6a280a
      https://github.com/llvm/llvm-project/commit/8f6ee17f22a7575671ad1581231f29947a6a280a
  Author: Pavel Labath <pavel at labath.sk>
  Date:   2022-03-09 (Wed, 09 Mar 2022)

  Changed paths:
    M lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
    M lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h
    A lldb/test/Shell/SymbolFile/DWARF/x86/dwo-not-found-warning.cpp

  Log Message:
  -----------
  [lldb] Warn when we fail to find dwo/dwp files

This ensures that the user is aware that many commands will not work
correctly.

We print the warning only once (per module) to avoid spamming the user
with potentially thousands of error messages.

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


  Commit: 4bcadd66864bf4af929ac8753a51d7ad408cdef0
      https://github.com/llvm/llvm-project/commit/4bcadd66864bf4af929ac8753a51d7ad408cdef0
  Author: Pavel Labath <pavel at labath.sk>
  Date:   2022-03-09 (Wed, 09 Mar 2022)

  Changed paths:
    M lldb/packages/Python/lldbsuite/test/lldbpexpect.py
    A lldb/test/API/driver/job_control/TestJobControl.py
    A lldb/test/API/driver/job_control/shell.py
    M lldb/tools/driver/Driver.cpp

  Log Message:
  -----------
  [lldb/driver] Fix SIGTSTP handling

Our SIGTSTP handler was working, but that was mostly accidental.

The reason it worked is because lldb is multithreaded for most of its
lifetime and the OS is reasonably fast at responding to signals. So,
what happened was that the kill(SIGTSTP) which we sent from inside the
handler was delivered to another thread while the handler was still set
to SIG_DFL (which then correctly put the entire process to sleep).

Sometimes it happened that the other thread got the second signal after
the first thread had already restored the handler, in which case the
signal handler would run again, and it would again attempt to send the
SIGTSTP signal back to itself.

Normally it didn't take many iterations for the signal to be delivered
quickly enough. However, if you were unlucky (or were playing around
with pexpect) you could get SIGTSTP while lldb was single-threaded, and
in that case, lldb would go into an endless loop because the second
SIGTSTP could only be handled on the main thread, and only after the
handler for the first signal returned (and re-installed itself). In that
situation the handler would keep re-sending the signal to itself.

This patch fixes the issue by implementing the handler the way it
supposed to be done:
- before sending the second SIGTSTP, we unblock the signal (it gets
  automatically blocked upon entering the handler)
- we use raise to send the signal, which makes sure it gets delivered to
  the thread which is running the handler

This also means we don't need the SIGCONT handler, as our TSTP handler
resumes right after the entire process is continued, and we can do the
required work there.

I also include a test case for the SIGTSTP flow. It uses pexpect, but it
includes a couple of extra twists. Specifically, I needed to create an
extra process on top of lldb, which will run lldb in a separate process
group and simulate the role of the shell. This is needed because SIGTSTP
is not effective on a session leader (the signal gets delivered, but it
does not cause a stop) -- normally there isn't anyone to notice the
stop.

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


  Commit: acf77bd2fd90d3b1347e50219c556057ef882d55
      https://github.com/llvm/llvm-project/commit/acf77bd2fd90d3b1347e50219c556057ef882d55
  Author: Pavel Labath <pavel at labath.sk>
  Date:   2022-03-09 (Wed, 09 Mar 2022)

  Changed paths:
    M lldb/source/Core/ValueObject.cpp
    M lldb/test/API/functionalities/data-formatter/builtin-formats/TestBuiltinFormats.py
    M lldb/test/API/functionalities/data-formatter/stringprinter/main.cpp
    M lldb/test/Shell/SymbolFile/DWARF/x86/DW_AT_const_value.s

  Log Message:
  -----------
  [lldb] Don't print *trailing* nuls in char arrays

Embedded nul characters are still printed, and they don't terminate the
string. See also D111634.

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


Compare: https://github.com/llvm/llvm-project/compare/2c7afadb4789...acf77bd2fd90