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

[Jan Kiszka <jan.kiszka@web.de>]

[-- Attachment #1: Type: text/plain, Size: 2358 bytes --]

Am 25.09.2010 10:35, Eddie Kohler wrote:
> Thanks for the response.  I agree the patch is a workaround, but it is a
> useful workaround, and I'd still argue for including it.

Nope, sorry, I have to vote against this.

> 
> The patch doesn't *require* that CS.base == DS.base.  Breakpoints

It does. There are several parts in QEMU that use cpu_memory_rw_debug
for reading or writing code segment: the disassembler, KVM when
manipulating soft breakpoints, and also the TB flushing on breakpoint
changes relies on cpu_get_phys_page_debug and would break when using DS
as base.

> correctly and exclusively use CS.base.  However, any memory examination
> uses DS.base, and you're right that the user might "want" to examine
> some other segment.  A GDB fix would involve changing the gdb remote
> protocol as well as GDB itself and the GDB user interface.  Google says
> you've been thinking about that for a while now -- is it going well?

It's on a long list of things that would be nice to work on...

> 
>> 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.
> 
> I don't mind the double-breakpoint as much, but memory examination would
> still be broken, yes?

Issue "monitor info registers", extract the segment base, add it to the
variable address you are interested in, and issue a print request. It is
definitely not impossible, just "a bit" unhandy.

> 
> I don't understand the comment about "prevents setting breakpoints on
> inactive segments."  The code for setting breakpoints has not changed.

It has because you unconditionally subtract the CS base from the passed
address. If you want to set a breakpoint on some other CS, you would
have to account for their base offsets and pass a weirdly "corrected"
address from gdb. That's really no sane interface, specifically long-term.

> 
> Do you think the patch would actually make debugging WORSE on any OS? Or
> have any other undesirable effects, or make it harder to DTRT when GDB
> is ready?  It seems safe & useful to me; & it's 2 LOC!

The pathes change the interface to gdb by re-defining the semantics of
the passed addresses in way that is not future-proof, and they are buggy.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]