From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=47064 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OzkyW-0006Qp-FR for qemu-devel@nongnu.org; Sun, 26 Sep 2010 02:44:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OzkyV-00044j-9u for qemu-devel@nongnu.org; Sun, 26 Sep 2010 02:44:40 -0400 Received: from fmmailgate02.web.de ([217.72.192.227]:50338) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OzkyU-00044H-Tf for qemu-devel@nongnu.org; Sun, 26 Sep 2010 02:44:39 -0400 Message-ID: <4C9EEBCF.5080904@web.de> Date: Sun, 26 Sep 2010 08:44:31 +0200 From: Jan Kiszka MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH] i386 debugging stubs: Consider segment bases References: <4C9D415F.6090909@cs.ucla.edu> <4C9DA344.5010702@web.de> <4C9DB45B.7080609@cs.ucla.edu> In-Reply-To: <4C9DB45B.7080609@cs.ucla.edu> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA08A9657A2FFB94019034FB3" Sender: jan.kiszka@web.de List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eddie Kohler Cc: qemu-devel@nongnu.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA08A9657A2FFB94019034FB3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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. >=20 > The patch doesn't *require* that CS.base =3D=3D 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... >=20 >> For the time being, you should be able to workaround the gdb limitatio= n >> by setting two breakpoints: one on the linear address and another one = on >> the CS offset. Not nice, but used to work for us. >=20 > I don't mind the double-breakpoint as much, but memory examination woul= d > 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. >=20 > 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= =2E >=20 > Do you think the patch would actually make debugging WORSE on any OS? O= r > 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 --------------enigA08A9657A2FFB94019034FB3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkye69QACgkQitSsb3rl5xTYagCgum2AKSuCBIWVkoRmgmxSSH7d qLAAn04/zjlrr1pPhdg/cRhAKpa2UcYb =EowK -----END PGP SIGNATURE----- --------------enigA08A9657A2FFB94019034FB3--