[Lldb-commits] [lldb] [lldb] [Process/FreeBSDKernel] Show crash info on start (PR #178027)

[Michael Buch via lldb-commits]

================
@@ -277,6 +286,143 @@ lldb::addr_t ProcessFreeBSDKernel::FindSymbol(const char *name) {
   return sym ? sym->GetLoadAddress(&GetTarget()) : LLDB_INVALID_ADDRESS;
 }
 
+void ProcessFreeBSDKernel::ShowCrashInfo() {
+  Target &target = GetTarget();
+  Debugger &debugger = target.GetDebugger();
+
+  if (!debugger.GetCommandInterpreter().IsInteractive())
+    return;
+
+  Status error;
+
+  // Find msgbufp symbol (pointer to message buffer)
+  lldb::addr_t msgbufp_addr = FindSymbol("msgbufp");
+  if (msgbufp_addr == LLDB_INVALID_ADDRESS)
+    return;
+
+  // Read the pointer value
+  lldb::addr_t msgbufp = ReadPointerFromMemory(msgbufp_addr, error);
+  if (!error.Success() || msgbufp == LLDB_INVALID_ADDRESS)
+    return;
+
+  // Get the type information for struct msgbuf from DWARF
+  TypeQuery query("msgbuf");
----------------
Michael137 wrote:

How common is it to have debug-info for msgbuf available in a typical workflow that uses this? And on the flipside, is it important to support the no-debuginfo case? The answer to these will inform us about the usefulness of both these codepaths.

`msgbuf` a pretty generic name and is not namespaced, so looking it up globally and then relying on it seems like it would subtly go wrong once in a while. If we do want to stick to DWARF then we should bail out if the field names dont match, instead of going ahead with the memory reads.

But I'd be curious to see if we can get away with just relying on hardcoded offsets.

BTW the common practice is for reviewers to resolve comment threads to ensure the comment has been satisfactorily addressed.

https://github.com/llvm/llvm-project/pull/178027