================
@@ -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:
> https://github.com/llvm/llvm-project/pull/178027 is an example for results of
> hardcoding kernel structures
I think you linked the wrong PR here.
I don't mind going with debug-info *and* offsets. I was just trying to gauge
the typical workflow (whether debug-info is or isn't available in the general
case...but yea possibly hard to answer that without having supported the
FreeBSD community's debugging needs for a long enough time), because that would
give us an idea of whether one or the other of these has the potential to
bitrot (especially since there's no tests here).
Relying on debug-info has the at least the same potential of breaking when the
structure changes (even more so because renaming fields/wrapping fields in
anonymous structures/etc. will break for this approach, whereas offsets are
resilient to it). The only advantage I see of using debug-info (and you point
this out above) is that it gives us an easy "version-check". But your current
changes don't make use of this.
So if you do want to use debug-info to deduce offsets, you should bail out if
the field names are not the ones you expect.
https://github.com/llvm/llvm-project/pull/178027
_______________________________________________
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
