arch-x86: If possible, use the workload to pick GDB arch.

When using remote GDB to debug an x86 simulated system within gem5, the
stub within gem5 needs to decide what arch the GDB instance expects.
That determines what format the blob of data with register values should
be.

Previously, gem5 would make that decision based on the current mode of
the target thread context. If the target was currently executing in 64
bit mode, that would imply that GDB was expecting 64 bit registers. If
not, then it was probably trying to debug a 32 bit program and would
expect 32 bit registers.

That works in many circumstances, but won't work if, for instance, a CPU
has not yet been initialized and is not running in its final, typical
mode, or if it's dipped into another mode to, for instance, run a user
mode program which is 32 bit under a 64 bit kernel.

This change modifies the GDB stub to first try to use the workload
object to determine what arch the GDB instance is most likely to assume.
This is a reasonably accurate representation for the arch GDB expects,
even though there isn't a direct, enforced link. It would be best if GDB
could just tell us what it expected, but I wasn't able to find any way
to get it to do that.

In most (all?) cases where someone would be using GDB to debug the guest
there will be a workload, and that workload will have a well defined
architecture. Since that isn't technically required though, this change
will still fall back to the old detection mechanism if it can't tell
from the workload, or if there is no workload in the first place.

Later revisions of the GDB interface may tie the remote GDB stub to the
workload object itself, in which case it *will* be possible to assume
that a workload object exists, and the workload object will be able to
explicitly select what GDB stub to use based on what it's running. In
the mean time, this seems like a fairly robust approximation of that.

Change-Id: I5059d48c28380e2fee5629d832acf95063a1a27a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/44614
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>

src/arch/x86/remote_gdb.cc

@@ -49,6 +49,8 @@
 #include "arch/x86/process.hh"
 #include "arch/x86/regs/int.hh"
 #include "arch/x86/regs/misc.hh"
+#include "base/loader/object_file.hh"
+#include "base/logging.hh"
 #include "base/remote_gdb.hh"
 #include "base/socket.hh"
 #include "base/trace.hh"
@@ -57,6 +59,7 @@
 #include "debug/GDBAcc.hh"
 #include "mem/page_table.hh"
 #include "sim/full_system.hh"
+#include "sim/workload.hh"
 
 using namespace X86ISA;
 
@@ -91,6 +94,21 @@ RemoteGDB::acc(Addr va, size_t len)
 BaseGdbRegCache*
 RemoteGDB::gdbRegs()
 {
+    // First, try to figure out which type of register cache to return based
+    // on the architecture reported by the workload.
+    if (system()->workload) {
+        auto arch = system()->workload->getArch();
+        if (arch == Loader::X86_64) {
+            return &regCache64;
+        } else if (arch == Loader::I386) {
+            return &regCache32;
+        } else if (arch != Loader::UnknownArch) {
+            panic("Unrecognized workload arch %s.",
+                    Loader::archToString(arch));
+        }
+    }
+
+    // If that didn't work, decide based on the current mode of the context.
     HandyM5Reg m5reg = context()->readMiscRegNoEffect(MISCREG_M5_REG);
     if (m5reg.submode == SixtyFourBitMode)
         return &regCache64;