This is an archive of the discontinued LLVM Phabricator instance.

[lldb-vscode] Fix two issues with runInTerminal test.
ClosedPublic

Authored by jgorbe on Apr 7 2023, 12:48 PM.

Details

Summary

With ptrace_scope = 1 the kernel only allows tracing descendants of a process.
When using runInTerminal, the target process is not launched by the debugger,
so we need to modify LaunchRunInTerminal to explicitly allow tracing.
This should fix a problem reported in https://reviews.llvm.org/D84974#3903716

Also, remove a special case from the launch method in the lldbvscode_testcase
test harness. The existing test was using stopOnEntry, so the first stop didn't
happen at the expected breakpoint unless the harness did configurationDone
first.

Diff Detail

Event Timeline

jgorbe created this revision.Apr 7 2023, 12:48 PM
Herald added a project: Restricted Project. · View Herald TranscriptApr 7 2023, 12:48 PM
jgorbe requested review of this revision.Apr 7 2023, 12:48 PM
rupprecht added inline comments.
lldb/tools/lldb-vscode/lldb-vscode.cpp
3163

https://manpages.debian.org/bullseye/manpages-dev/prctl.2.en.html#PR_SET_PTRACER

It would be nice if we could avoid PR_SET_PTRACER_ANY and set the pid directly. (Maybe you will need an additional flag, along with --comm-file and --launch-target?). Using PR_SET_PTRACER_ANY effectively circumvents the system's ptrace policy, IIUC.

wow, nice improvement. I don't have anything else to add besides what @rupprecht said

jgorbe updated this revision to Diff 511818.Apr 7 2023, 4:16 PM

Added a --debugger-pid flag that needs to be passed with --launch-target so
that we can restrict PR_SET_PTRACER to the main lldb-vscode instance instead of
using PR_SET_PTRACER_ANY.

The pid plumbing looks fine for the happy case, but I think we could be more lenient if (for whatever reason) the pid flag isn't being set on non-Linux systems that won't actually be using it. Even on a Linux system, this is only needed if ptrace_scope != 0, so if the pid isn't being provided there, we could just skip the prctl call and hope the user's system has a value of 0 for that.

(Also, 0 is a weird value, we should probably just reject that)

lldb/tools/lldb-vscode/JSONUtils.cpp
1119

Only pass this if != 0

(or get fancy and use a std::optional or whatever)

lldb/tools/lldb-vscode/lldb-vscode.cpp
1569

unsigned long -> lldb::pid_t

3163

Only invoke this if debugger_pid != 0

3262

StringRef is usually used for parsing strings as numbers, something like:

unsigned long pid = 0;
  llvm::StringRef debugger_pid_value = debugger_pid->getValue())
  if (debugger_pid_value.getAsInteger(10, pid)) {
    llvm::errs() << ...
  }
}
jgorbe updated this revision to Diff 512272.Apr 10 2023, 3:09 PM
jgorbe marked 3 inline comments as done.

Addressed review comments.

  • Use lldb::pid_t instead of unsigned long, and LLDB_INVALID_PROCESS_ID instead of 0 in the cases where the PID is missing.
  • Only pass the --debugger-pid flag if we're on Linux and we have a debugger PID. I don't think we need to be particularly lenient with flag parsing, because IIUC the command lines for the launcher should only ever be built by lldb-vscode itself and not by hand, but it can be confusing for users in other platforms to see --debugger-pid 0 in the command line on the terminal.
  • Changed parsing of the --debugger-pid numeric value to use llvm::StringRef.
lldb/tools/lldb-vscode/JSONUtils.cpp
1119

Done. Given that I've changed the debugger_pid argument to an lldb::pid_t I'm using LLDB_INVALID_PROCESS_ID as a sentinel value.

lldb/tools/lldb-vscode/lldb-vscode.cpp
3163

Done.

3262

Thanks! Once this patch lands we should consider changing how the port flag is parsed (just a few lines after this block) to match this style.

rupprecht accepted this revision.Apr 10 2023, 3:50 PM

Thanks!

This revision is now accepted and ready to land.Apr 10 2023, 3:50 PM
This revision was automatically updated to reflect the committed changes.