All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@web.de>
To: Eddie Kohler <kohler@cs.ucla.edu>
Cc: qemu-devel@nongnu.org
Subject: [Qemu-devel] Re: [PATCH] i386 debugging stubs: Consider segment bases
Date: Sat, 25 Sep 2010 09:22:44 +0200	[thread overview]
Message-ID: <4C9DA344.5010702@web.de> (raw)
In-Reply-To: <4C9D415F.6090909@cs.ucla.edu>

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

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


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

  reply	other threads:[~2010-09-25  7:23 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-25  0:25 [Qemu-devel] [PATCH] i386 debugging stubs: Consider segment bases Eddie Kohler
2010-09-25  7:22 ` Jan Kiszka [this message]
2010-09-25  8:35   ` [Qemu-devel] " Eddie Kohler
2010-09-26  6:44     ` Jan Kiszka
2010-09-26 17:19       ` Eddie Kohler
2010-09-27  6:29         ` Jan Kiszka

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4C9DA344.5010702@web.de \
    --to=jan.kiszka@web.de \
    --cc=kohler@cs.ucla.edu \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.