* [Qemu-devel] [PATCH] Fix to gdb - wrong translation block invalidated when setting gdb breakpoints
@ 2005-12-23 19:57 Andre Pech
2005-12-28 8:22 ` Mulyadi Santosa
0 siblings, 1 reply; 5+ messages in thread
From: Andre Pech @ 2005-12-23 19:57 UTC (permalink / raw)
To: qemu-devel
[-- Attachment #1: Type: text/plain, Size: 2146 bytes --]
Hi all,
I had been running into problems using gdb to debug the virtual machine
kernel. The problem I was experiencing is that I would set a breakpoint, but
that gdb would only sometimes get notified that the breakpoint was hit.
I finally tracked down the problem to exec.c:breakpoint_invalidate. The
problem is that breakpoint_invalidate, which is supposed to invalidate the
translation block for the address you want to break at, was actualling
invalidating the translation block for the base address of the page that
contained your breakpoint address. The fix is actually very simple and is
attached below.
Thanks
Andre Pech
diff -dc exec.c{.old,}
*** exec.c.old 2005-12-23 11:40:47.000000000 -0800
--- exec.c 2005-12-23 11:41:13.000000000 -0800
***************
*** 996,1001 ****
--- 996,1002 ----
target_ulong phys_addr;
phys_addr = cpu_get_phys_page_debug(env, pc);
+ phys_addr += pc & (~TARGET_PAGE_MASK);
tb_invalidate_phys_page_range(phys_addr, phys_addr + 1, 0);
}
#endif
On 12/21/05, Mulyadi Santosa <a_mulyadi@softhome.net> wrote:
>
> Hello Andre...
>
> > I'm running into problems using qemu to debug a kernel module. My
> > host and virtual machine are both x86 running Fedora Core 4. After
> > insmoding the module in the virtual machine, starting gdbserver,
> > running gdb on the host with the module sections loaded at the right
> > place, and setting a breakpoint in the module code, gdb does not
> > always get notified when the code is exectuted. After adding
>
> I'm not doing module debugging, only core kernel code debugging, but
> more or less I run into same situation (last time confirmed with Qemu
> 0.7.1)
>
> For additional info, sometimes I also suffered the other condition.
> Breakpoint is hit, but even if I delete it, the emulation still stops
> whenever the code at related physical address is hit. I tried to
> printf() every gdb command received by Qemu's gdbstub and it confirmed
> that breakpoint deletion command is actually received, but I can't
> confirm what is the real bug there.
>
> regards
>
> Mulyadi
>
>
[-- Attachment #2: Type: text/html, Size: 2755 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Qemu-devel] [PATCH] Fix to gdb - wrong translation block invalidated when setting gdb breakpoints
2005-12-23 19:57 [Qemu-devel] [PATCH] Fix to gdb - wrong translation block invalidated when setting gdb breakpoints Andre Pech
@ 2005-12-28 8:22 ` Mulyadi Santosa
[not found] ` <16af12af0512301218k48fecbdcr6ec41640b303689@mail.gmail.com>
0 siblings, 1 reply; 5+ messages in thread
From: Mulyadi Santosa @ 2005-12-28 8:22 UTC (permalink / raw)
To: qemu-devel, Andre Pech
Hello Andre....
> breakpoint was hit. I finally tracked down the problem to
> exec.c:breakpoint_invalidate. The problem is that
> breakpoint_invalidate, which is supposed to invalidate the
> translation block for the address you want to break at, was
> actualling invalidating the translation block for the base address of
> the page that contained your breakpoint address. The fix is actually
> very simple and is attached below.
Thanks for the patch :) I will test the patch ASAP. Anyway, while the
fix seems "simple", I am sure it wasn't easy to track down the real
problem. Checking briefly (by eye, not via debugger or tons of printf()
), one will skip those lines because he/she will think the function is
invalidating the correct physical address (returned
cpu_get_phys_page_debug() ). Great work!
NB: Althought it is a bit late, but it's never too late...Merry
Christmast!
regards
Mulyadi
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Re: [Qemu-devel] [PATCH] Fix to gdb - wrong translation block invalidated when setting gdb breakpoints
[not found] ` <16af12af0512301218k48fecbdcr6ec41640b303689@mail.gmail.com>
@ 2006-01-01 8:10 ` Mulyadi Santosa
2006-01-03 20:12 ` Andre Pech
0 siblings, 1 reply; 5+ messages in thread
From: Mulyadi Santosa @ 2006-01-01 8:10 UTC (permalink / raw)
To: Andre Pech; +Cc: qemu-devel
Hello Andre...
> Not a problem. I only started using qemu a month ago, so it took me a
> while to get oriented in the code and understand what was going on. I
> must say that I've been really impressed with qemu so far.
There was an interesting case I had found recently. In Linux kernel for
i386 arch, you will see that sys_uname is placed to return kernel
version/name. Funny thing is, even if I use your patch (against qemu
0.7.1) and I put a breakpoint at sys_uname and issue "uname" at bash
prompt, the Qemu VM doesn't stop. Can you kindly check it?
NB: Please see target-i386/translate.c, there you will see lines like
these (around line 6306):
if (env->nb_breakpoints > 0) {
for(j = 0; j < env->nb_breakpoints; j++) {
if (env->breakpoints[j] == pc_ptr) {
gen_debug(dc, pc_ptr - dc->cs_base);
break;
}
}
}
What I understand from this code is, VM is stop if breakpoint address
matches with pc_ptr, which tb->pc and AFAIK that is the start address
of the translation block. So in other word, in some cases Qemu might
still miss the breakpoint (does it explain the sys_uname case?) Please
CMIIW
regards
Mulyadi
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Re: [Qemu-devel] [PATCH] Fix to gdb - wrong translation block invalidated when setting gdb breakpoints
2006-01-01 8:10 ` Mulyadi Santosa
@ 2006-01-03 20:12 ` Andre Pech
2006-01-04 10:29 ` Mulyadi Santosa
0 siblings, 1 reply; 5+ messages in thread
From: Andre Pech @ 2006-01-03 20:12 UTC (permalink / raw)
To: a_mulyadi; +Cc: qemu-devel
[-- Attachment #1: Type: text/plain, Size: 2082 bytes --]
Hi Mulyadi,
The problem that you are running into here is that sys_uname has been
replaced by sys_newuname in kernel/sys.c. When I put a breakpoint in this
function, everything works correctly when I run uname in the virtual
machine.
I'm not sure I exactly understand your concern that breakpoints could be
missed. When you set the breakpoint, tb_invalidate_phys_page_range is
called, invalidating the translation block block for the address where you
are placing the breakpoint. At this point, the next time that the address is
hit, translate.c:gen_intermediate_code will have to be called, and the
breakpoint will be hit. Let me know if I've missed something here.
Thanks,
Andre
On 1/1/06, Mulyadi Santosa <a_mulyadi@softhome.net> wrote:
>
> Hello Andre...
>
> > Not a problem. I only started using qemu a month ago, so it took me a
> > while to get oriented in the code and understand what was going on. I
> > must say that I've been really impressed with qemu so far.
>
> There was an interesting case I had found recently. In Linux kernel for
> i386 arch, you will see that sys_uname is placed to return kernel
> version/name. Funny thing is, even if I use your patch (against qemu
> 0.7.1) and I put a breakpoint at sys_uname and issue "uname" at bash
> prompt, the Qemu VM doesn't stop. Can you kindly check it?
>
> NB: Please see target-i386/translate.c, there you will see lines like
> these (around line 6306):
> if (env->nb_breakpoints > 0) {
> for(j = 0; j < env->nb_breakpoints; j++) {
> if (env->breakpoints[j] == pc_ptr) {
> gen_debug(dc, pc_ptr - dc->cs_base);
> break;
> }
> }
> }
> What I understand from this code is, VM is stop if breakpoint address
> matches with pc_ptr, which tb->pc and AFAIK that is the start address
> of the translation block. So in other word, in some cases Qemu might
> still miss the breakpoint (does it explain the sys_uname case?) Please
> CMIIW
>
> regards
>
> Mulyadi
>
>
[-- Attachment #2: Type: text/html, Size: 2959 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Re: Re: [Qemu-devel] [PATCH] Fix to gdb - wrong translation block invalidated when setting gdb breakpoints
2006-01-03 20:12 ` Andre Pech
@ 2006-01-04 10:29 ` Mulyadi Santosa
0 siblings, 0 replies; 5+ messages in thread
From: Mulyadi Santosa @ 2006-01-04 10:29 UTC (permalink / raw)
To: Andre Pech; +Cc: qemu-devel
Hi Andre...
> The problem that you are running into here is that sys_uname has been
> replaced by sys_newuname in kernel/sys.c. When I put a breakpoint in
> this function, everything works correctly when I run uname in the
> virtual machine.
yes, you're right. sys_newuname is the system call handler that handles
"uname" in kernel space, as it is confirmed with eax=122 when we reach
system_call entry in arch/i386/kernel/entry.S. Thanks for pointing me
into the correct handler.
> I'm not sure I exactly understand your concern that breakpoints could
> be missed. When you set the breakpoint, tb_invalidate_phys_page_range
> is called, invalidating the translation block block for the address
> where you are placing the breakpoint. At this point, the next time
> that the address is hit, translate.c:gen_intermediate_code will have
> to be called, and the breakpoint will be hit. Let me know if I've
> missed something here.
I'm not 100% sure too, but maybe I need to confirm what I understand
about "translation block" in Qemu. Suppose we have following asm
snippet:
<....>
mov eax,8
mov ebx,10
move ecx,16
ret
<....>
When qemu check the above codes, I learn that it is converted into a
single translation block ("ret" is the end mark of the translation
block). Do I get something wrong here? Please CMIIW.
regards
Mulyadi
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2006-01-04 10:47 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-12-23 19:57 [Qemu-devel] [PATCH] Fix to gdb - wrong translation block invalidated when setting gdb breakpoints Andre Pech
2005-12-28 8:22 ` Mulyadi Santosa
[not found] ` <16af12af0512301218k48fecbdcr6ec41640b303689@mail.gmail.com>
2006-01-01 8:10 ` Mulyadi Santosa
2006-01-03 20:12 ` Andre Pech
2006-01-04 10:29 ` Mulyadi Santosa
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).