qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Jan Kiszka
Subject: Re: [Qemu-devel] Re: [PATCH] i386 debugging stubs: Consider segment bases
Date: Sun, 26 Sep 2010 08:44:31 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666

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: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]