On 08.03.2017 04:09, Richard Henderson wrote: > On 03/08/2017 11:16 AM, Julian Kirsch wrote: >> For instance, many modern x86-64 operating systems maintain access to >> internal >> data structures via the MSR_GSBASE/MSR_KERNELGSBASE MSRs. Giving >> introspection utilities (such as a remotely attached gdb) a way of >> accessing these registers improves analysis results drastically. > > If this is just for gdb, then we should provide access via the normal gdbstub, > plus appropriate xml files. There are plenty of examples of this for other > cpus. > > > r~ >
Hi Richard, I considered adding this functionality to the gdbstub. However, my understanding of this approach is that it would make the patch dependent on a particular (newly added) xml file being present at the gdb client side. The current solution avoids this by letting gdb clients simply use the newly introduced commands by means of the "monitor" command already built into gdb. While I appreciate that this is a bit hacky, I, on the other hand, cannot come up with any good setting in which a normal user space gdb client might need access to the MSRs except for the qemu one, such that adding a new xml file to gdb just for this special use case might be difficult to communicate on the gdb-devel list. Another question arising in this context would also consider what and how many MSRs the xml file(s) should contain, including the logic to provide distinct architectural MSRs for 32 and 64 bit targets. I hope you can see this approach incurring non-negligible planning overhead with the end result providing same or even less functionality. Nevertheless, I'd move the functionality over to the gdbstub and bug on gdb-devel to include a new (minimal) xml file, if it was the only way to get an according patch upstream in qemu. Best, Julian
