51ddd16172
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>
This is the gem5 simulator. The main website can be found at http://www.gem5.org A good starting point is http://www.gem5.org/about, and for more information about building the simulator and getting started please see http://www.gem5.org/documentation and http://www.gem5.org/documentation/learning_gem5/introduction. To build gem5, you will need the following software: g++ or clang, Python (gem5 links in the Python interpreter), SCons, SWIG, zlib, m4, and lastly protobuf if you want trace capture and playback support. Please see http://www.gem5.org/documentation/general_docs/building for more details concerning the minimum versions of the aforementioned tools. Once you have all dependencies resolved, type 'scons build/<ARCH>/gem5.opt' where ARCH is one of ARM, NULL, MIPS, POWER, SPARC, or X86. This will build an optimized version of the gem5 binary (gem5.opt) for the the specified architecture. See http://www.gem5.org/documentation/general_docs/building for more details and options. The basic source release includes these subdirectories: - configs: example simulation configuration scripts - ext: less-common external packages needed to build gem5 - src: source code of the gem5 simulator - system: source for some optional system software for simulated systems - tests: regression tests - util: useful utility programs and files To run full-system simulations, you will need compiled system firmware (console and PALcode for Alpha), kernel binaries and one or more disk images. If you have questions, please send mail to gem5-users@gem5.org Enjoy using gem5 and please share your modifications and extensions.