[lldb-vscode] Add an option for loading core files

[wallace]

Summary

Currently loading core files on lldb-vscode is broken because there's a check in the attach workflow that asserts that the PID is valid, which of course fails for this case.
Hence, I'm adding a "coreFile" argument for the attach request, which does the work correctly.

I have yet to make a test. So I'm asking for initial feedback in the meantime. I'll get some inspiration by the coredump tests in LLDB core.

This is a test debug config:

{
        "name": "Attach to coredump",
        "type": "fb-lldb",
        "request": "attach",
        "program": "/Users/wallace/Source/coredumptest/a.out",
        "coreFile": "/cores/core.33448",
}

And it worked on VSCode

[clayborg]

You might look around for a core file in another test location and be able to use that. Functionality looks good to me. This could have been done with attachCommands before, but it is nice to have a built in and supported way to do this.

[labath]

In D78839#2004278, @clayborg wrote:

You might look around for a core file in another test location and be able to use that.

Yep, there's plenty to choose from in test/API/functionalities/postmortem/elf-core/.

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

533

I can't tell what does this return from this snippet. I don't think this is a good use of auto.

577

Judging by this, it probably returns a StringRef. Is it always guaranteed to be null-terminated?

lldb/tools/lldb-vscode/package.json

226

Is the second part really true? lldb is able to open a core file without specifying the main executable (and in some cases it will even automatically find the matching executable).

[wallace]

Added a test, which was easier than I thought!
I tested it on mac as well, so I hope it'll work well on the buildbots.

I also removed that bad use of auto. It seems that all StringRefs gotten from the JSON object are null-terminated.

[labath]

Looks good. It may be interesting to tack a couple of resume/step-over/etc commands at the end of the test to make just the whole thing doesn't go berserk when those operations fail.

In D78839#2006698, @wallace wrote:

I also removed that bad use of auto. It seems that all StringRefs gotten from the JSON object are null-terminated.

Ok, json::parse is documented to return "self-contained" json object which owns its strings. It's not a big stretch to assume that those owned strings will also be null terminated, though it still seems moderately dangerous...

[wallace]

added the test suggested by @labath

lldb/tools/lldb-vscode/README.md

 ```
 
 This will work as long as the architecture, vendor and OS supports waiting
 for processes. Currently MacOS is the only platform that supports this.
 
 
 ### Loading a Core File
 
-Loading a core file can use the `"attach"` request along with the
-`"attachCommands"` to implement a custom attach:
+This loads the coredump file `/cores/123.core` associated with the program
+`/tmp/a.out`:
 
 ```javascript
 {
-  "name": "Attach to Name (wait)",
+  "name": "Load coredump",
   "type": "lldb-vscode",
   "request": "attach",
-  "attachCommands": ["target create -c /path/to/123.core /path/to/executable"],
-  "stopOnEntry": false
+  "coreFile": "/cores/123.core",
+  "program": "/tmp/a.out"
 }
 ```

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

if (pid != LLDB_INVALID_PROCESS_ID)
     attach_info.SetProcessID(pid);
   const auto wait_for = GetBoolean(arguments, "waitFor", false);
   attach_info.SetWaitForLaunch(wait_for, false /*async*/);
   g_vsc.init_commands = GetStrings(arguments, "initCommands");
   g_vsc.pre_run_commands = GetStrings(arguments, "preRunCommands");
   g_vsc.stop_commands = GetStrings(arguments, "stopCommands");
   g_vsc.exit_commands = GetStrings(arguments, "exitCommands");
   auto attachCommands = GetStrings(arguments, "attachCommands");
-  g_vsc.stop_at_entry = GetBoolean(arguments, "stopOnEntry", false);
+  auto core_file = GetString(arguments, "coreFile");
+  g_vsc.stop_at_entry =
+      core_file.empty() ? GetBoolean(arguments, "stopOnEntry", false) : true;
   const auto debuggerRoot = GetString(arguments, "debuggerRoot");
 
   // This is a hack for loading DWARF in .o files on Mac where the .o files
   // in the debug map of the main executable have relative paths which require
   // the lldb-vscode binary to have its working directory set to that relative
   // root for the .o files in order to be able to load debug info.
   if (!debuggerRoot.empty()) {
     llvm::sys::fs::set_current_path(debuggerRoot.data());
if (pid == LLDB_INVALID_PROCESS_ID && wait_for) {
     g_vsc.SendOutput(OutputType::Console,
                      llvm::StringRef(attach_msg, attach_msg_len));
   }
   if (attachCommands.empty()) {
     // No "attachCommands", just attach normally.
     // Disable async events so the attach will be successful when we return from
     // the launch call and the launch will happen synchronously
     g_vsc.debugger.SetAsync(false);
+    if (core_file.empty())
       g_vsc.target.Attach(attach_info, error);
+    else
+      g_vsc.target.LoadCore(core_file.data(), error);
     // Reenable async events
     g_vsc.debugger.SetAsync(true);
   } else {
     // We have "attachCommands" that are a set of commands that are expected
     // to execute the commands after which a process should be created. If there
     // is no valid process after running these commands, we have failed.
     g_vsc.RunLLDBCommands("Running attachCommands:", attachCommands);
     // The custom commands might have created a new target so we should use the
     // selected target after these commands are run.
     g_vsc.target = g_vsc.debugger.GetSelectedTarget();
   }
 
   SetSourceMapFromArguments(*arguments);
 
-  if (error.Success()) {
+  if (error.Success() && core_file.empty()) {
     auto attached_pid = g_vsc.target.GetProcess().GetProcessID();
     if (attached_pid == LLDB_INVALID_PROCESS_ID) {
       if (attachCommands.empty())
         error.SetErrorString("failed to attach to a process");
       else
         error.SetErrorString("attachCommands failed to attach to a process");
     }
   }

lldb/tools/lldb-vscode/package.json

"debuggers": [
               },
               "stopCommands": {
                 "type": "array",
                 "description": "Commands executed each time the program stops.",
                 "default": []
               },
               "exitCommands": {
                 "type": "array",
-                  "description": "Commands executed at the end of debugging session.",
-                  "default": []
+              },
+              "coreFile": {
+                "type": "string",
+                "description": "Path to the core file to debug. It's necessary to specify the \"program\" argument as well."
               }
             }
           }
         },
         "initialConfigurations": [
           {
             "type": "lldb-vscode",
             "request": "launch",