================
@@ -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
_______________________________________________
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
