All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marcel Kilgus <qemu@mail.kilgus.net>
To: qemu-devel@nongnu.org
Subject: [Qemu-devel] Re: Debugging with paging enabled
Date: Fri, 10 Nov 2006 15:31:51 +0100	[thread overview]
Message-ID: <1315607799.20061110153151@kilgus.net> (raw)
In-Reply-To: <fb249edb0611100514k30f6dcebs802f57c33a96fbd3@mail.gmail.com>

andrzej zaborowski wrote:
>> Well, that explains it then, I guess. In that case I don't really see
>> a clean solution for it.
> If I understand the problem, the clean solution is having the
> debugging symbols at the right addresses: in code that runs with
> paging enabled symbols should be at their virtual addresses and the
> other symbols at physical addresses. Since the period from start to
> enabling paging is usually short, I think most kernels generate only
> virtual addresses for the symbols. I don't remember the ld option to
> move text-base to the right address but see Linux. GDB works perfectly
> for it. It doesn't need to know about segmentation if your symbols are
> correct.

No, as I see it, that doesn't solve the problem (and I did try to do
that by simply using objcopy and telling it to rebase all symbols).

OK, I dug a bit deeper and now I probably know far more about the
internals of qemu and the GDB serial debugging protocol than I ever
wanted. ;-)

Let's say the symbols are at the right location, then this happens
(all based on viewing the qemu code, I haven't actually debugged it):

GDB = ->, QEMU-GDB-STUB = <-

-> Z1,0xC0123456        Set hardware breakpoint at address 0xC0123456
<- OK                   Breakpoint set
-> c                    Continue to run virtual machine
<- S05                  qemu comes to the bp and returns with SIGTRAP.

At this point GDB knows that something has triggered the TRAP
exception, but from the answer alone it cannot know what. It will
certainly continue by requesting all registers of the virtual machine
and then look at the EIP value. But EIP, as CS is based at 0xC0000000,
will be 0x00123456 (note the lacking C at the most significant
nibble). It has no clue what to do with that one and simply passes the
exception on to the user (as seen in my mail that started the
thread).

Assuming that breakpoint locations are indeed meant to be virtual
addresses, GDB would have to evaluate the CS descriptor, add the CS
base to the EIP address and THEN check whether it knows the address.
But as it seems to be segment-agnostic it doesn't do that and things
break as a result.

Anybody seeing anything wrong with my reasoning?

All the best, Marcel

  reply	other threads:[~2006-11-10 14:31 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-08  2:30 [Qemu-devel] Debugging with paging enabled Marcel Kilgus
2006-11-08 21:13 ` [Qemu-devel] " Marcel Kilgus
2006-11-08 22:15   ` Fabrice Bellard
2006-11-08 23:33     ` Marcel Kilgus
2006-11-08 23:42       ` Daniel Jacobowitz
2006-11-08 23:57         ` Marcel Kilgus
2006-11-09  2:24           ` Daniel Jacobowitz
2006-11-10 13:14           ` andrzej zaborowski
2006-11-10 14:31             ` Marcel Kilgus [this message]
2006-11-10 15:56               ` Paul Brook
2006-11-10 16:14                 ` Marcel Kilgus
2006-11-10 17:10                 ` Daniel Jacobowitz
2006-11-10 19:01                   ` Marcel Kilgus
2006-11-10 19:07                     ` Daniel Jacobowitz

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=1315607799.20061110153151@kilgus.net \
    --to=qemu@mail.kilgus.net \
    --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.