From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=55303 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Q8vpS-0004es-OS
	for qemu-devel@nongnu.org; Sun, 10 Apr 2011 10:41:31 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <avi@redhat.com>) id 1Q8vpR-0003Cm-UL
	for qemu-devel@nongnu.org; Sun, 10 Apr 2011 10:41:30 -0400
Received: from mx1.redhat.com ([209.132.183.28]:8589)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <avi@redhat.com>) id 1Q8vpR-0003Ca-Ku
	for qemu-devel@nongnu.org; Sun, 10 Apr 2011 10:41:29 -0400
Message-ID: <4DA1C194.2000005@redhat.com>
Date: Sun, 10 Apr 2011 17:41:24 +0300
From: Avi Kivity <avi@redhat.com>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] Re: software breakpoints disappearing/reappearing
	in	KVM/qemu
References: <BANLkTimB7YhJ2UPtH3c2XjAx1kvHmGWNAw@mail.gmail.com>
	<4D9F7597.7020604@web.de> <4DA1B81C.8000506@redhat.com>
	<4DA1BD64.6000108@web.de>
In-Reply-To: <4DA1BD64.6000108@web.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Jan Kiszka <jan.kiszka@web.de>
Cc: qemu-devel@nongnu.org, Craig Brozefsky <craig@red-bean.com>

On 04/10/2011 05:23 PM, Jan Kiszka wrote:
> On 2011-04-10 16:01, Avi Kivity wrote:
> >  On 04/08/2011 11:52 PM, Jan Kiszka wrote:
> >>  QEMU's gdbstub in KVM mode is simply not designed to account for guests
> >>  swapping out code pages that contain breakpoints. Due to the fact that
> >>  the Linux kernel does not do these weird things to its own code,
> >
> >  It actually happily patches its own code at certain circumstances.  If
> >  you debug early boot or suspend/resume or cpu hotplug you're likely to
> >  encounter them.
>
> Yes, it patches (alternates, jump_labels, mcount etc.), but it doesn't
> swap or move code pages. At least so far.
>

Try using modules (though that's different - the virtual addresses will 
change too).  Or debugging a mixed kernel/user workload.

> If you need to break at such locations, there are still hardware
> breakpoints, though only 4.

Right.

-- 
error compiling committee.c: too many arguments to function