Display PC instead of <unknown> for stack trace in vscode

[zhyty]

Summary

It isn't useful for users to see "<unknown>" as a stack trace when lldb fails to symbolicate a stack frame. I've replaced "<unknown>" with the value of the program counter instead.

Test Plan:

To test this, I opened a target that lldb fails to symbolicate in
VSCode, and observed in the CALL STACK section that instead of being
shown as "<unknown>", those stack frames are represented by their
program counters.

I also ran lldb-dotest -p TestVSCode and saw that the tests passed.

[yinghuitan]

Can you add a testcase for this?

lldb/tools/lldb-vscode/JSONUtils.cpp

707

I do not think this is needed?

710

I do not think os.flush() is needed. llvm::raw_string_ostream should auto flush while running out of scope.

[clayborg]

Adding a test case for this is a good idea. In order to get the PC somewhere bad, you can probably make a function pointer that points to data, then try to branch there. The PC will end up somewhere with no function name and should allow us to reproduce this.

Here is a small program that will reproduce this:

int main() {
  typedef void (*FooCallback)();
  FooCallback foo_callback = (FooCallback)0;
  foo_callback(); // Crash at zero!
  return 0;
}

This will crash at 0x00000000 as we tried to call a function there. It makes the "<unknown>" show up in the VS code GUI

lldb/tools/lldb-vscode/JSONUtils.cpp

707

remove this, the "frame_name" is already empty from the initializer on line 761

[clayborg]

You can copy this folder to a new test folder and adjust the test to verify:

lldb/test/API/tools/lldb-vscode/stackTrace

[zhyty]

• added a test case
• rebased this commit on top of D156970, which fixes a crash preventing me from testing this feature
• addressed other comments

[zhyty]

remove a.out

[clayborg]

Looks good!

lldb/test/API/tools/lldb-vscode/stackTraceMissingFunctionName/Makefile

+CXX_SOURCES := main.cpp
+include Makefile.rules

lldb/test/API/tools/lldb-vscode/stackTraceMissingFunctionName/TestVSCode_stackTraceMissingFunctionName.py

+"""
+Test lldb-vscode stack trace response
+"""
+
+
+import vscode
+from lldbsuite.test.decorators import *
+import os
+
+import lldbvscode_testcase
+from lldbsuite.test import lldbtest, lldbutil
+
+
+class TestVSCode_stackTraceMissingFunctionName(lldbvscode_testcase.VSCodeTestCaseBase):
+    @skipIfWindows
+    @skipIfRemote
+    def test_missingFunctionName(self):
+        """
+        Test that the stack frame without a function name is given its pc in the response.
+        """
+        program = self.getBuildArtifact("a.out")
+        self.build_and_launch(program)
+
+        self.continue_to_next_stop()
+        frame_without_function_name = self.get_stackFrames()[0]
+        self.assertEquals(frame_without_function_name["name"], "0x0000000000000000")

lldb/test/API/tools/lldb-vscode/stackTraceMissingFunctionName/main.cpp

+int main() {
+  typedef void (*FooCallback)();
+  FooCallback foo_callback = (FooCallback)0;
+  foo_callback(); // Crash at zero!
+  return 0;
+}

lldb/tools/lldb-vscode/JSONUtils.cpp

llvm::json::Value CreateStackFrame(lldb::SBFrame &frame) {
   int64_t frame_id = MakeVSCodeFrameID(frame);
   object.try_emplace("id", frame_id);
 
   // `function_name` can be a nullptr, which throws an error when assigned to an
   // `std::string`.
   const char *function_name = frame.GetDisplayFunctionName();
   std::string frame_name =
       function_name == nullptr ? std::string() : function_name;
-  if (frame_name.empty())
-    frame_name = "<unknown>";
+  if (frame_name.empty()) {
+    // If the function name is unavailable, display the pc address as a 16-digit
+    // hex string, e.g. "0x0000000000012345"
+    llvm::raw_string_ostream os(frame_name);
+    os << llvm::format_hex(frame.GetPC(), 18);
+  }
   bool is_optimized = frame.GetFunction().GetIsOptimized();
   if (is_optimized)
     frame_name += " [opt]";
   EmplaceSafeString(object, "name", frame_name);
 
   auto source = CreateSource(frame);
 
   if (source) {
     object.try_emplace("source", *source);