[Qemu-devel] Re: [PATCH] i386 debugging stubs: Consider segment bases

[Jan Kiszka]

Am 25.09.2010 02:25, Eddie Kohler wrote:
> Hi,
> 
> QEMU has a bug that complicates GDB debugging of i386 targets when the
> current code or data segment has a nonzero base.  A fix is attached.
> 
> If the current code segment has a nonzero base, breakpoints don't work
> as expected, because the breakpoint detector does not consider segment
> bases.
> 
> If the current data segment has a nonzero base, memory inspection doesn't
> work, because cpu_get_phys_page_debug does not consider segment bases.
> 
> A tiny 'operating system' demonstrating the problem is here:
> 
> http://read.cs.ucla.edu/~kohler/qemu-gdbseg-demo.tgz
> 
> The README enclosed in that tarball gives steps on how to replicate the
> breakpoint problem.  The 'kernel' runs with segment base 0x10000000, so
> that linear address 0xF0001000 is translated into physical address
> 0x00001000.  But breakpoints (which should use virtual addresses) at
> a linear address (e.g. 0xF0100000) are ignored.  You can stop execution
> using a physical address, but all the addresses reported
> back to GDB are linear addresses, so this isn't consistent.
> 
> This is a real problem that prevents us from using unpatched QEMU in
> classwork.  Any comments on the fix??  (A version was initially posted
> several years ago.)

This is just a workaround for the core issue: lacking segment support in
gdb and its remote protocol. Assuming that an address passed via the
current protocol refers to CS and DS is broken. Your patch e.g. requires
that CS.base == DS.base, which is not always the case with truly
segmented OSes. And it prevents setting breakpoints in inactive segments.

We really need to fix gdb instead, i.e. transfer the segment states so
that the frontend can linearize as required. And gdb needs to be
extended to support segment:offset addressing syntax.

For the time being, you should be able to workaround the gdb limitation
by setting two breakpoints: one on the linear address and another one on
the CS offset. Not nice, but used to work for us.

Jan

signature.asc
Description: OpenPGP digital signature