* gdbserver breakpoint problem with PowerPC
@ 2004-04-01 20:46 Andre Ancelin
2004-04-01 20:52 ` Daniel Jacobowitz
0 siblings, 1 reply; 6+ messages in thread
From: Andre Ancelin @ 2004-04-01 20:46 UTC (permalink / raw)
To: gdb; +Cc: cagney
Hi everyone!
I'm having a problem with gdbserver 6.0. Setup:
HOST- x86 (P4), SuSE 8.0 distro, gdb 6.0
TARGET- PowerPC405GP (custom board), 2.4.21 PPC kernel (custom), gdbserver
6.0 w/ libthread_db.so.1 dependency.
TOOLCHAIN- binutil 2.11.2, gcc 2.95.3, glibc(-linuxthreads) 2.2.2
The problem: the target does not reliably set breakpoints. Single step works
once, then the next step takes off and continues. Set two consecutive
breakpoints and target may or may not stop at first, but never stops at
second. Apparently, gdbserver is not always setting up the trap. I have
captured the remote protocol and see that the single step command is both
sent and acknowledged ($s#73...Ack) for both the case where a single step
works and doesn't.
I searched the list and was unable to find resolution. If such exists -OR- I
am just doing (or not doing) something silly, please point me to the wind
and I will happily fly away. If not, then perhaps someone can tell me where
to start looking and I will dig in and try to fix myself. Thanks!
Andre G Ancelin
VP/CTO
Adtec Digital
A Digital Video Technology Company
http://www.adtecinc.com
mailto:andrea@adtecinc.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: gdbserver breakpoint problem with PowerPC
2004-04-01 20:46 gdbserver breakpoint problem with PowerPC Andre Ancelin
@ 2004-04-01 20:52 ` Daniel Jacobowitz
2004-04-02 0:33 ` Andre Ancelin
0 siblings, 1 reply; 6+ messages in thread
From: Daniel Jacobowitz @ 2004-04-01 20:52 UTC (permalink / raw)
To: Andre Ancelin; +Cc: gdb, cagney
On Thu, Apr 01, 2004 at 02:51:07PM -0500, Andre Ancelin wrote:
> Hi everyone!
>
> I'm having a problem with gdbserver 6.0. Setup:
>
> HOST- x86 (P4), SuSE 8.0 distro, gdb 6.0
> TARGET- PowerPC405GP (custom board), 2.4.21 PPC kernel (custom), gdbserver
> 6.0 w/ libthread_db.so.1 dependency.
> TOOLCHAIN- binutil 2.11.2, gcc 2.95.3, glibc(-linuxthreads) 2.2.2
>
> The problem: the target does not reliably set breakpoints. Single step works
> once, then the next step takes off and continues. Set two consecutive
> breakpoints and target may or may not stop at first, but never stops at
> second. Apparently, gdbserver is not always setting up the trap. I have
> captured the remote protocol and see that the single step command is both
> sent and acknowledged ($s#73...Ack) for both the case where a single step
> works and doesn't.
If GDB sends an 's' packet, gdbserver will issue a PTRACE_SINGLESTEP
request. If that loses control, then your kernel has failed to
implement PTRACE_SINGLESTEP correctly; take it up with your kernel.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: gdbserver breakpoint problem with PowerPC
2004-04-01 20:52 ` Daniel Jacobowitz
@ 2004-04-02 0:33 ` Andre Ancelin
2004-04-02 1:17 ` Daniel Jacobowitz
0 siblings, 1 reply; 6+ messages in thread
From: Andre Ancelin @ 2004-04-02 0:33 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: gdb, cagney
Daniel Jacobowitz wrote:
>On Thu, Apr 01, 2004 at 02:51:07PM -0500, Andre Ancelin wrote:
>> Hi everyone!
>>
>> I'm having a problem with gdbserver 6.0. Setup:
>>
>> HOST- x86 (P4), SuSE 8.0 distro, gdb 6.0
>> TARGET- PowerPC405GP (custom board), 2.4.21 PPC kernel (custom),
gdbserver
>> 6.0 w/ libthread_db.so.1 dependency.
>> TOOLCHAIN- binutil 2.11.2, gcc 2.95.3, glibc(-linuxthreads) 2.2.2
>>
>> The problem: the target does not reliably set breakpoints. Single step
works
>> once, then the next step takes off and continues. Set two consecutive
>> breakpoints and target may or may not stop at first, but never stops at
>> second. Apparently, gdbserver is not always setting up the trap. I have
>> captured the remote protocol and see that the single step command is both
>> sent and acknowledged ($s#73...Ack) for both the case where a single step
>> works and doesn't.
>
>If GDB sends an 's' packet, gdbserver will issue a PTRACE_SINGLESTEP
>request. If that loses control, then your kernel has failed to
>implement PTRACE_SINGLESTEP correctly; take it up with your kernel.
>
>--
>Daniel Jacobowitz
>MontaVista Software Debian GNU/Linux Developer
Thanks for the prompt reply!
I discussed it with my Kernel (2.4.21) and it insisted it was not the
problem. Kidding aside, here is more pathology:
My test program is barebones- just a main that loops endlessly incrementing
a static int. On startup, I launch with 'c' and let it loose. I then Ctrl-C
to interrupt, which works fine. I set a breakpoint on the auto incrementing
var line and unleash it again with 'c'. It now breaks as expected. I unleash
it again with 'c' and it does not break- and no, the break is not temporary
(though acting like it). Here is the flow of the debug remote:
------- CLIP -------
anrea@linux:~/sandbox/edje3000/gnu-test-gdbserver>
/opt/crosstool/powerpc-405-linux-gnu/gcc-2.95.3-glibc-2.2.2/bin/powerpc-405-
linux-gnu-gdb -x gdbinit
GNU gdb 6.0
Copyright 2003 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as
"--host=i686-host_pc-linux-gnu --target=powerpc-405-linux-gnu".
0x30013ae8 in ?? ()
(gdb) set debug remote 1
(gdb) c
Continuing.
Sending packet: $Z0,3000f928,4#e2...Ack
Packet received:
Packet Z0 (software-breakpoint) is NOT supported
Sending packet: $m3000f928,4#99...Ack
Packet received: 4082000c
Sending packet: $X3000f928,0:#ba...Ack
Packet received:
binary downloading NOT suppported by target
Sending packet: $M3000f928,4:7d821008#81...Ack
Packet received: OK
Sending packet: $Hc0#db...Ack
Packet received: OK
Sending packet: $c#63...Ack
Packet received: T0501:7ffff5f8;40:3000f928;
Sending packet: $m3000f928,4#99...Ack
Packet received: 7d821008
Sending packet: $M3000f928,4:4082000c#74...Ack
Packet received: OK
Sending packet: $m10010490,a0#b9...Ack
Packet received:
00000001000000100000000c1000023c0000000d100004300000000410000150000000051000
01b400000006100001740000000a0000003b0000000b00000010000000150000000000000003
10010538000000020000000c0000001400000007000000171000023000000007100002240000
000800000018000000090000000c6ffffffe100002046fffffff000000016ffffff0100001fa
0000000000000000
Sending packet: $Hc0#db...Ack
Packet received: OK
Sending packet: $s#73...Ack
=========================
<<<< Running until >>>>
<<<< AGA CTRL-C here >>>>
=========================
remote_interrupt called
remote_stop called
Packet received: T0201:7ffffd80;40:100003a0;
Program received signal SIGINT, Interrupt.
Sending packet: $g#67...Ack
Packet received:
13c2b7307ffffd8000000000000000017ffffde47ffffdec7ffffe2c3000e784100004501001
000013c2b72f1001000042000842100185300000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000100004503002a9d80ffe9f980000
00017ffffde40ffe7b8c7ffffd80000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
00000000100003a00000d230220008420fed5dbc0fed5c4c0000000000000000
Sending packet: $mfed5db8,c#5e...Ack
Packet received: 4e800021481155459421ffe0
0x100003a0 in main () at test.c:10
10 j++;
(gdb) l
5 main ()
6 {
7 for(;;)
8 {
9 i++;
10 j++;
11 }
12 return 0;
13 }
(gdb) break 10
Breakpoint 1 at 0x10000390: file test.c, line 10.
(gdb) c
Continuing.
Sending packet: $m3000f928,4#99...Ack
Packet received: 4082000c
Sending packet: $M3000f928,4:7d821008#81...Ack
Packet received: OK
Sending packet: $m10000390,4#5a...Ack
Packet received: 3d601001
Sending packet: $M10000390,4:7d821008#42...Ack
Packet received: OK
Sending packet: $Hc0#db...Ack
Packet received: OK
Sending packet: $c#63...Ack
Packet received: T0501:7ffffd80;40:10000390;
Sending packet: $g#67...Ack
Packet received:
13c2b7317ffffd8000000000000000017ffffde47ffffdec7ffffe2c3000e784100004501001
000013c2b7301001000042000842100185300000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000100004503002a9d80ffe9f980000
00017ffffde40ffe7b8c7ffffd80000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
00000000100003900000d230220008420fed5dbc0fed5c4c0000000000000000
Sending packet: $mfed5db8,c#5e...Ack
Packet received: 4e800021481155459421ffe0
Sending packet: $m3000f928,4#99...Ack
Packet received: 7d821008
Sending packet: $M3000f928,4:4082000c#74...Ack
Packet received: OK
Sending packet: $m10000390,4#5a...Ack
Packet received: 7d821008
Sending packet: $M10000390,4:3d601001#33...Ack
Packet received: OK
Breakpoint 1, main () at test.c:10 (AGA <<<< BREAKS AS EXPECTED)
10 j++;
(gdb) c
Continuing.
Sending packet: $Hc0#db...Ack
Packet received: OK
Sending packet: $s#73...Ack
remote_interrupt called
remote_stop called
Packet received: T0201:7ffffd80;40:100003a0; (AGA ???? DOES NOT BREAK- BUT
NOTICE IT DID NOT SET SOFT BREAKPOINT)
=========================
<<<< Running until >>>>
<<<< AGA CTRL-C here >>>>
=========================
Program received signal SIGINT, Interrupt.
Sending packet: $g#67...Ack
Packet received:
1526d63b7ffffd8000000000000000017ffffde47ffffdec7ffffe2c3000e784100004501001
00001526d63a1001000042000842100185300000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000100004503002a9d80ffe9f980000
00017ffffde40ffe7b8c7ffffd80000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
00000000100003a00000d230220008420fed5dbc0fed5c4c0000000000000000
Sending packet: $mfed5db8,c#5e...Ack
Packet received: 4e800021481155459421ffe0
0x100003a0 in main () at test.c:10
10 j++;
------- CLIP -------
I'm beginning to think gdbserver is just fine & gdb is the culprit. Looks to
me like gdb is forgetting to restore the breakpoint. Have I missed a
configuration setting during the build or while running gdb??? Sure hope I'm
just overlooking something silly (like maybe the impact of the initial Z0
refusal hosing something internal, though I don't think that is it???).
Andre G Ancelin
VP/CTO
Adtec Digital, Inc.
A Digital Video Technology Company
http://www.adtecinc.com
mailto:andrea@adtecinc.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: gdbserver breakpoint problem with PowerPC
2004-04-02 0:33 ` Andre Ancelin
@ 2004-04-02 1:17 ` Daniel Jacobowitz
2004-04-02 18:13 ` Andre Ancelin
0 siblings, 1 reply; 6+ messages in thread
From: Daniel Jacobowitz @ 2004-04-02 1:17 UTC (permalink / raw)
To: Andre Ancelin; +Cc: gdb
On Thu, Apr 01, 2004 at 07:31:35PM -0500, Andre Ancelin wrote:
> Sending packet: $s#73...Ack
>
> =========================
> <<<< Running until >>>>
> <<<< AGA CTRL-C here >>>>
> =========================
> I'm beginning to think gdbserver is just fine & gdb is the culprit. Looks to
> me like gdb is forgetting to restore the breakpoint. Have I missed a
> configuration setting during the build or while running gdb??? Sure hope I'm
> just overlooking something silly (like maybe the impact of the initial Z0
> refusal hosing something internal, though I don't think that is it???).
No, really, after a single step the server should respond with a trap
event. Your kernel still appears to be at fault, or else something is
extremely wrong with gdbserver (unlikely, given the symptoms).
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: gdbserver breakpoint problem with PowerPC
2004-04-02 1:17 ` Daniel Jacobowitz
@ 2004-04-02 18:13 ` Andre Ancelin
2004-04-02 18:48 ` Mark Salter
0 siblings, 1 reply; 6+ messages in thread
From: Andre Ancelin @ 2004-04-02 18:13 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: gdb
Daniel Jacobowitz wrote:
>On Thu, Apr 01, 2004 at 07:31:35PM -0500, Andre Ancelin wrote:
>> Sending packet: $s#73...Ack
>>
>> =========================
>> <<<< Running until >>>>
>> <<<< AGA CTRL-C here >>>>
>> =========================
>
>> I'm beginning to think gdbserver is just fine & gdb is the culprit. Looks
to
>> me like gdb is forgetting to restore the breakpoint. Have I missed a
>> configuration setting during the build or while running gdb??? Sure hope
I'm
>> just overlooking something silly (like maybe the impact of the initial Z0
>> refusal hosing something internal, though I don't think that is it???).
>
>No, really, after a single step the server should respond with a trap
>event. Your kernel still appears to be at fault, or else something is
>extremely wrong with gdbserver (unlikely, given the symptoms).
>
>--
>Daniel Jacobowitz
>MontaVista Software Debian GNU/Linux Developer
I'm still not convinced. For one thing, gdb is issuing a single step when I
requested a continue- what gives?
A few other observations from the following abbreviated session (full
session attached below)-
----- ABBREVIATED SESSION -----
...
(gdb) <CTRL-C issued to interrupt running program>
...
(gdb) break 10
(gdb) c
Continuing.
Sending packet: $m3000f928,4#99...Ack
Packet received: 4082000c
Sending packet: $M3000f928,4:7d821008#81...Ack
Packet received: OK
Sending packet: $m10000390,4#5a...Ack
Packet received: 3d601001
Sending packet: $M10000390,4:7d821008#42...Ack
Packet received: OK
Sending packet: $Hc0#db...Ack
Packet received: OK
Sending packet: $c#63...Ack...
...
Breakpoint 1, main () at test.c:10 (AGA <<<< BREAKS AS EXPECTED)
10 j++;
(gdb) c
Continuing.
Sending packet: $Hc0#db...Ack
Packet received: OK
Sending packet: $s#73...Ack
remote_interrupt called
remote_stop called
Packet received: T0201:7ffffd80;40:100003a0; (AGA ???? DOES NOT BREAK)
----- /ABBREVIATED SESSION -----
What I find interesting is that the two 'c' commands, both before and after
hitting the breakpoint, behave differently. The first one sets 2 software
breakpoints (@ 0x3000f928 & 0x10000390), sets up thread 0, then continues-
looks good. The second one sets up thread 0 and then tries to single step-
huh? Maybe this is by design, but it leaves me perplexed. For one thing, how
is gdserver supposed to know where to set the trap to match the next source
line? For another thing, why would gdb use a soft breakpoint correctly once
with 'c', and then suddenly decide to use a 's'- presumably leaving it to
gdbserver to discern soft or hard and where to place- the next time? Based
on my observations, I am hard pressed to see how the issue could even exist
in gdbserver, let alone the kernel. If any of my analysis is flawed, by all
means please correct me and shed some light into these dark corners (at
least dark to me).
I thinks' something still isn't quite right in gdb 6.0 when connecting to a
remote PPC target...???...
Andre G Ancelin
VP/CTO
Adtec Digital, Inc.
A Digital Video Technology Company
http://www.adtecinc.com
mailto:andrea@adtecinc.com
PS- The debug remote capability of displaying the remote protocol messages
is absolutely WONDERFUL! Another fine example of well thought out UNIX
design employing simple text messaging- KUDOS to the gdb team.
------- CLIP -------
anrea@linux:~/sandbox/edje3000/gnu-test-gdbserver>
/opt/crosstool/powerpc-405-linux-gnu/gcc-2.95.3-glibc-2.2.2/bin/powerpc-405-
linux-gnu-gdb -x gdbinit
GNU gdb 6.0
Copyright 2003 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as
"--host=i686-host_pc-linux-gnu --target=powerpc-405-linux-gnu".
0x30013ae8 in ?? ()
(gdb) set debug remote 1
(gdb) c
Continuing.
Sending packet: $Z0,3000f928,4#e2...Ack
Packet received:
Packet Z0 (software-breakpoint) is NOT supported
Sending packet: $m3000f928,4#99...Ack
Packet received: 4082000c
Sending packet: $X3000f928,0:#ba...Ack
Packet received:
binary downloading NOT suppported by target
Sending packet: $M3000f928,4:7d821008#81...Ack
Packet received: OK
Sending packet: $Hc0#db...Ack
Packet received: OK
Sending packet: $c#63...Ack
Packet received: T0501:7ffff5f8;40:3000f928;
Sending packet: $m3000f928,4#99...Ack
Packet received: 7d821008
Sending packet: $M3000f928,4:4082000c#74...Ack
Packet received: OK
Sending packet: $m10010490,a0#b9...Ack
Packet received:
00000001000000100000000c1000023c0000000d100004300000000410000150000000051000
01b400000006100001740000000a0000003b0000000b00000010000000150000000000000003
10010538000000020000000c0000001400000007000000171000023000000007100002240000
000800000018000000090000000c6ffffffe100002046fffffff000000016ffffff0100001fa
0000000000000000
Sending packet: $Hc0#db...Ack
Packet received: OK
Sending packet: $s#73...Ack
=========================
<<<< Running until >>>>
<<<< AGA CTRL-C here >>>>
=========================
remote_interrupt called
remote_stop called
Packet received: T0201:7ffffd80;40:100003a0;
Program received signal SIGINT, Interrupt.
Sending packet: $g#67...Ack
Packet received:
13c2b7307ffffd8000000000000000017ffffde47ffffdec7ffffe2c3000e784100004501001
000013c2b72f1001000042000842100185300000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000100004503002a9d80ffe9f980000
00017ffffde40ffe7b8c7ffffd80000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
00000000100003a00000d230220008420fed5dbc0fed5c4c0000000000000000
Sending packet: $mfed5db8,c#5e...Ack
Packet received: 4e800021481155459421ffe0
0x100003a0 in main () at test.c:10
10 j++;
(gdb) l
5 main ()
6 {
7 for(;;)
8 {
9 i++;
10 j++;
11 }
12 return 0;
13 }
(gdb) break 10
Breakpoint 1 at 0x10000390: file test.c, line 10.
(gdb) c
Continuing.
Sending packet: $m3000f928,4#99...Ack
Packet received: 4082000c
Sending packet: $M3000f928,4:7d821008#81...Ack
Packet received: OK
Sending packet: $m10000390,4#5a...Ack
Packet received: 3d601001
Sending packet: $M10000390,4:7d821008#42...Ack
Packet received: OK
Sending packet: $Hc0#db...Ack
Packet received: OK
Sending packet: $c#63...Ack
Packet received: T0501:7ffffd80;40:10000390;
Sending packet: $g#67...Ack
Packet received:
13c2b7317ffffd8000000000000000017ffffde47ffffdec7ffffe2c3000e784100004501001
000013c2b7301001000042000842100185300000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000100004503002a9d80ffe9f980000
00017ffffde40ffe7b8c7ffffd80000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
00000000100003900000d230220008420fed5dbc0fed5c4c0000000000000000
Sending packet: $mfed5db8,c#5e...Ack
Packet received: 4e800021481155459421ffe0
Sending packet: $m3000f928,4#99...Ack
Packet received: 7d821008
Sending packet: $M3000f928,4:4082000c#74...Ack
Packet received: OK
Sending packet: $m10000390,4#5a...Ack
Packet received: 7d821008
Sending packet: $M10000390,4:3d601001#33...Ack
Packet received: OK
Breakpoint 1, main () at test.c:10 (AGA <<<< BREAKS AS EXPECTED)
10 j++;
(gdb) c
Continuing.
Sending packet: $Hc0#db...Ack
Packet received: OK
Sending packet: $s#73...Ack
remote_interrupt called
remote_stop called
Packet received: T0201:7ffffd80;40:100003a0; (AGA ???? DOES NOT BREAK- BUT
NOTICE IT DID NOT SET SOFT BREAKPOINT)
=========================
<<<< Running until >>>>
<<<< AGA CTRL-C here >>>>
=========================
Program received signal SIGINT, Interrupt.
Sending packet: $g#67...Ack
Packet received:
1526d63b7ffffd8000000000000000017ffffde47ffffdec7ffffe2c3000e784100004501001
00001526d63a1001000042000842100185300000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000100004503002a9d80ffe9f980000
00017ffffde40ffe7b8c7ffffd80000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
00000000100003a00000d230220008420fed5dbc0fed5c4c0000000000000000
Sending packet: $mfed5db8,c#5e...Ack
Packet received: 4e800021481155459421ffe0
0x100003a0 in main () at test.c:10
10 j++;
------- CLIP ---
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: gdbserver breakpoint problem with PowerPC
2004-04-02 18:13 ` Andre Ancelin
@ 2004-04-02 18:48 ` Mark Salter
0 siblings, 0 replies; 6+ messages in thread
From: Mark Salter @ 2004-04-02 18:48 UTC (permalink / raw)
To: andrea; +Cc: drow, gdb
>>>>> Andre Ancelin writes:
> I'm still not convinced. For one thing, gdb is issuing a single step when I
> requested a continue- what gives?
That is expected if you stopped at a breakpoint. GDB has to singlestep past
the instruction where the breakpoint was placed. After the singlestep, gdb
will put the breakpoint back and then continue.
--Mark
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2004-04-02 18:48 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-04-01 20:46 gdbserver breakpoint problem with PowerPC Andre Ancelin
2004-04-01 20:52 ` Daniel Jacobowitz
2004-04-02 0:33 ` Andre Ancelin
2004-04-02 1:17 ` Daniel Jacobowitz
2004-04-02 18:13 ` Andre Ancelin
2004-04-02 18:48 ` Mark Salter
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox