* [Qemu-devel] setting MIPS gdb breakpoints have wrong offsets
@ 2006-06-11 13:58 Dirk Behme
2006-06-11 20:56 ` Stefan Weil
0 siblings, 1 reply; 3+ messages in thread
From: Dirk Behme @ 2006-06-11 13:58 UTC (permalink / raw)
To: qemu-devel
Hi,
I just tried to debug some simple MIPS code using
qemu-system-mipsel by setting some breakpoints. If I use
gdb's break command with symbol names the breakpoints are
set at offsets and therefore they are never hit.
Please find an example below. I'd like to stop the program
if I get an interrupt, everything looks okay. But break
command sets breakpoint at 0xbfc00384 instead of 0xbfc00380.
Is this a bug or feature? I use qemu-system-mipsel with some
of the pending MIPS patches applied locally. If this is a
bug, can anybody else reproduce this? Any idea?
Best regards
Dirk
(gdb) info address exception
Symbol "exception" is at 0xbfc00380.
(gdb) list exception
158 .end cache_miss
159
160 .org 0x380
161 .ent exception
162 exception:
163 j exception_handler
164 nop
165 .end exception
166
167 /****************************************************
(gdb) x/2i 0xbfc00380
0xbfc00380 <exception>: b 0xbfc0046c <exception_handler>
0xbfc00384 <exception+4>: nop
(gdb) break exception
Breakpoint 1 at 0xbfc00384: file crt0.S, line 163.
(gdb)
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Qemu-devel] setting MIPS gdb breakpoints have wrong offsets
2006-06-11 13:58 [Qemu-devel] setting MIPS gdb breakpoints have wrong offsets Dirk Behme
@ 2006-06-11 20:56 ` Stefan Weil
2006-06-12 0:43 ` Daniel Jacobowitz
0 siblings, 1 reply; 3+ messages in thread
From: Stefan Weil @ 2006-06-11 20:56 UTC (permalink / raw)
To: qemu-devel
Hi Dirk,
when I set a breakpoint to address 0x80000180 ("b *0x80000180"), this
works as expected. So do breakpoints to symbolic addresses in the
Linux kernel.
"info breakpoints" shows address 0xffffffff80000180 for the first example.
Maybe "b *0xbfc00380" works for your case. If it does, your mips-gdb
is somehow strange.
Regards
Stefan
Dirk Behme schrieb:
> Hi,
>
> I just tried to debug some simple MIPS code using qemu-system-mipsel
> by setting some breakpoints. If I use gdb's break command with symbol
> names the breakpoints are set at offsets and therefore they are never
> hit.
>
> Please find an example below. I'd like to stop the program if I get an
> interrupt, everything looks okay. But break command sets breakpoint at
> 0xbfc00384 instead of 0xbfc00380. Is this a bug or feature? I use
> qemu-system-mipsel with some of the pending MIPS patches applied
> locally. If this is a bug, can anybody else reproduce this? Any idea?
>
> Best regards
>
> Dirk
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Qemu-devel] setting MIPS gdb breakpoints have wrong offsets
2006-06-11 20:56 ` Stefan Weil
@ 2006-06-12 0:43 ` Daniel Jacobowitz
0 siblings, 0 replies; 3+ messages in thread
From: Daniel Jacobowitz @ 2006-06-12 0:43 UTC (permalink / raw)
To: qemu-devel
On Sun, Jun 11, 2006 at 10:56:51PM +0200, Stefan Weil wrote:
> Hi Dirk,
>
> when I set a breakpoint to address 0x80000180 ("b *0x80000180"), this
> works as expected. So do breakpoints to symbolic addresses in the
> Linux kernel.
>
> "info breakpoints" shows address 0xffffffff80000180 for the first example.
>
> Maybe "b *0xbfc00380" works for your case. If it does, your mips-gdb
> is somehow strange.
This means that GDB has (mistakenly) decided that the first assembly
instruction in the function is part of a standard function prologue;
feel free to report a GDB bug.
--
Daniel Jacobowitz
CodeSourcery
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2006-06-12 0:43 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-06-11 13:58 [Qemu-devel] setting MIPS gdb breakpoints have wrong offsets Dirk Behme
2006-06-11 20:56 ` Stefan Weil
2006-06-12 0:43 ` Daniel Jacobowitz
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).