* [MI/testsuite] mi_gdb_test: expected result priority? @ 2002-06-24 12:46 Keith Seitz 2002-06-24 13:20 ` Elena Zannoni 2002-06-24 14:04 ` Torubles with remote stub for m68k Peter Barada 0 siblings, 2 replies; 19+ messages in thread From: Keith Seitz @ 2002-06-24 12:46 UTC (permalink / raw) To: gdb Hi, I've been writing some MI tests for all the stuff that I've been adding, and I ran across an anomaly... When mi_gdb_test actually calls expect, it does: gdb_expect $tmt { -re "\\*\\*\\* DOSEXIT code.*" { if { $message != "" } { fail "$message"; } gdb_suppress_entire_file "GDB died"; return -1; } -re "Ending remote debugging.*$mi_gdb_prompt\[ \]*$" { if ![isnative] then { warning "Can`t communicate to remote target." } gdb_exit gdb_start set result -1 } -re "(${question_string})$" { send_gdb "$response_string\n"; exp_continue; } -re "Undefined.* command:.*$mi_gdb_prompt\[ \]*$" { perror "Undefined command \"$command\"." fail "$message" set result 1 } -re "Ambiguous command.*$mi_gdb_prompt\[ \]*$" { perror "\"$command\" is not a unique command name." fail "$message" set result 1 } -re "\[\r\n\]*($pattern)\[\r\n\]+$mi_gdb_prompt\[ \]*$" { if ![string match "" $message] then { pass "$message" } set result 0 } The astute reader will notice that the _real_ expected pattern by the caller is pre-empted by several other patterns. Therefore if one wanted to write a test to check for the string "Ambiguous command", well, you'd automatically get a fail. Likewise, if you wanted to write a test that checked for the string "Undefined command: \"bogus\". Try \"help\"." (which I am trying to do), one is screwed. Is there any particular reason to not move the real expected result pattern higher in the list (like to/near the top or something)?? Keith ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [MI/testsuite] mi_gdb_test: expected result priority? 2002-06-24 12:46 [MI/testsuite] mi_gdb_test: expected result priority? Keith Seitz @ 2002-06-24 13:20 ` Elena Zannoni 2002-06-24 14:04 ` Torubles with remote stub for m68k Peter Barada 1 sibling, 0 replies; 19+ messages in thread From: Elena Zannoni @ 2002-06-24 13:20 UTC (permalink / raw) To: Keith Seitz; +Cc: gdb Keith Seitz writes: > Hi, > > I've been writing some MI tests for all the stuff that I've been adding, > and I ran across an anomaly... > > When mi_gdb_test actually calls expect, it does: > > gdb_expect $tmt { > -re "\\*\\*\\* DOSEXIT code.*" { > if { $message != "" } { > fail "$message"; > } > gdb_suppress_entire_file "GDB died"; > return -1; > } > -re "Ending remote debugging.*$mi_gdb_prompt\[ \]*$" { > if ![isnative] then { > warning "Can`t communicate to remote target." > } > gdb_exit > gdb_start > set result -1 > } > -re "(${question_string})$" { > send_gdb "$response_string\n"; > exp_continue; > } > -re "Undefined.* command:.*$mi_gdb_prompt\[ \]*$" { > perror "Undefined command \"$command\"." > fail "$message" > set result 1 > } > -re "Ambiguous command.*$mi_gdb_prompt\[ \]*$" { > perror "\"$command\" is not a unique command name." > fail "$message" > set result 1 > } > -re "\[\r\n\]*($pattern)\[\r\n\]+$mi_gdb_prompt\[ \]*$" { > if ![string match "" $message] then { > pass "$message" > } > set result 0 > } > > > The astute reader will notice that the _real_ expected pattern by the > caller is pre-empted by several other patterns. Therefore if one wanted to > write a test to check for the string "Ambiguous command", well, you'd > automatically get a fail. Likewise, if you wanted to write a test that > checked for the string "Undefined command: \"bogus\". Try \"help\"." > (which I am trying to do), one is screwed. > > Is there any particular reason to not move the real expected result > pattern higher in the list (like to/near the top or something)?? > > Keith Hmm, nothing has changed in that procedure since day one. It is kind of a copy of the gdb_test one in gdb.exp. Maybe you can rearrange the patterns to be like gdb_test? The 'pass' occurs earlier in there. Elena ^ permalink raw reply [flat|nested] 19+ messages in thread
* Torubles with remote stub for m68k 2002-06-24 12:46 [MI/testsuite] mi_gdb_test: expected result priority? Keith Seitz 2002-06-24 13:20 ` Elena Zannoni @ 2002-06-24 14:04 ` Peter Barada 2002-06-24 14:13 ` Daniel Jacobowitz 2002-06-25 13:43 ` Andrew Cagney 1 sibling, 2 replies; 19+ messages in thread From: Peter Barada @ 2002-06-24 14:04 UTC (permalink / raw) To: gdb I'm in the midst of bringing up a remote stub for coldfire using gdb-5.1.1, and I'm having troubles getting it to step. My stub does not suppor the 'Z0' or 'e' packets so gdb has to fall back to the insertion of a 0x4e41 (trap #1) instruction into the stream as a breakpoint. when it hits the breakpoint, a 'si' command is expected to: 1) Restore the memory overwritten by the 0x4e41 (trap #1) instruction 2) Step the processor by setting the T bit in the SR register and return from gdb 3) Reinsert the previously removed breakpoint. (and seen in version 4.16) When I execute that with gdb-5.1.1, it attempts to step the processor without removing the trap instruction so the target processor never steps past the trap instruction. Here's a cut back version of the remote protocol exchange(via set debug remote 1) to show what's happening: (gdb) set debug remote 1 (gdb) b FRSfindfont Sending packet: $m3af58,2#32...Ack Packet received: 4e56 Sending packet: $m3af5c,2#5d...Ack Packet received: 48d7 Breakpoint 1 at 0x3af78: file ../pdi/fntsockt.c, line 604. (gdb) c Continuing. Sending packet: $Z0,3af78,2#7d...Ack Packet received: Packet Z0 (software-breakpoint) is NOT supported Sending packet: $m3af78,2#34...Ack Packet received: 4ab9 Sending packet: $X3af78,0:#57...Ack Packet received: OK binary downloading suppported by target Sending packet: $X3af78,2:NA#e8...Ack Packet received: OK Sending packet: $Hc0#db...Ack Packet received: ENN Sending packet: $c#63...Ack Packet received: T05thread:9; [New Thread 9] Sending packet: $g#67...Ack Packet received: 00000000000000000000006300000000004b47b8000000000000000000000000000000000000000000012ca000012c240000000000000000005c34d4005c34c8000000000014a898000000000000000000000000000000007fffffffffffffff7fffffffffffffff7fffffffffffffff7fffffffffffffff7fffffffffffffff7fffffffffffffff7fffffffffffffff7fffffffffffffff7fffffffffffffff7fffffffffffffff7fffffffffffffff0000000000000000000000000000000000000000 Program received signal SIGTRAP, Trace/breakpoint trap. (gdb) thr 1 Sending packet: $T00000009#dd...Ack Packet received: OK Sending packet: $m1fd6ae8,4#fc...Ack Packet received: 01fd6b70 Sending packet: $m1fd6b70,8#cb...Ack Packet received: 416c626572747573 Sending packet: $m1fd6b78,8#d3...Ack Packet received: 4d5400700061926c [Switching to thread 1 (Thread 9)]#0 FRSfindfont ( Sending packet: $m1fd6aec,4#27...Ack Packet received: 01fd6b4c Sending packet: $m1fd6af0,4#f5...Ack Packet received: 01fd6b50 Sending packet: $m1fd6af4,4#f9...Ack Packet received: 01fd6b54 name=0x1fd6b70 "AlbertusMT", idptr=0x1fd6b4c, ftype=0x1fd6b50, Sending packet: $m1fd6af8,4#fd...Ack Packet received: 004c590c Sending packet: $m1fd6afc,4#28...Ack Packet received: 01fd6b58 Sending packet: $m1fd6b00,4#c0...Ack Packet received: 01fd6b5c fclass=0x1fd6b54, font_mat=0x4c590c, painttype=0x1fd6b58, fontname=0x1fd6b5c) at ../pdi/fntsockt.c:604 (gdb) si Sending packet: $Hc9#e4...Ack Packet received: OK Sending packet: $s#73...Ack Packet received: T05thread:9; Sending packet: $g#67...Ack Packet received: 0000000a00000000001fca200000000501fd6b5c01fd6b58004c590c01fd6b54002161d6002161e1005e87b001fd6b5001fd6b70005ca53c01fd6ae001fd6aac4084a0000003af784046800000000000404ca5dc000000007fffffffffffffff7fffffffffffffff7fffffffffffffff7fffffffffffffff7fffffffffffffff7fffffffffffffff000000000000008800000000 (gdb) p/x $pc <------------- Note $pc value $2 = 0x3af78 (gdb) si Sending packet: $s#73...Ack Packet received: T05thread:9; Sending packet: $g#67...Ack Packet received: 0000000a00000000001fca200000000501fd6b5c01fd6b58004c590c01fd6b54002161d6002161e1005e87b001fd6b5001fd6b70005ca53c01fd6ae001fd6aa84084a0000003af784046800000000000404ca5dc000000007fffffffffffffff7fffffffffffffff7fffffffffffffff7fffffffffffffff7fffffffffffffff7fffffffffffffff000000000000008800000000 (gdb) p/x $pc <------------- Note $pc value $3 = 0x3af78 (gdb) Any ideas how to best fix this? -- Peter Barada Peter.Barada@motorola.com Wizard 781-852-2768 (direct) WaveMark Solutions(wholly owned by Motorola) 781-270-0193 (fax) ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Torubles with remote stub for m68k 2002-06-24 14:04 ` Torubles with remote stub for m68k Peter Barada @ 2002-06-24 14:13 ` Daniel Jacobowitz 2002-06-24 14:40 ` Peter Barada 2002-06-25 13:43 ` Andrew Cagney 1 sibling, 1 reply; 19+ messages in thread From: Daniel Jacobowitz @ 2002-06-24 14:13 UTC (permalink / raw) To: Peter Barada; +Cc: gdb On Mon, Jun 24, 2002 at 05:04:51PM -0400, Peter Barada wrote: > > I'm in the midst of bringing up a remote stub for coldfire using > gdb-5.1.1, and I'm having troubles getting it to step. My stub does > not suppor the 'Z0' or 'e' packets so gdb has to fall back to the > insertion of a 0x4e41 (trap #1) instruction into the stream as a breakpoint. > > when it hits the breakpoint, a 'si' command is expected to: > > 1) Restore the memory overwritten by the 0x4e41 (trap #1) instruction > 2) Step the processor by setting the T bit in the SR register and > return from gdb > 3) Reinsert the previously removed breakpoint. > > (and seen in version 4.16) > > When I execute that with gdb-5.1.1, it attempts to step the processor > without removing the trap instruction so the target processor never > steps past the trap instruction. > > Here's a cut back version of the remote protocol exchange(via set > debug remote 1) to show what's happening: You might want to try disabling binary download in your stub just to make sure... normally, the client will remove breakpoints itself. This definitely still works in 5.2. You also should try with 5.2 or CVS rather than 5.1.1, probably... -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Torubles with remote stub for m68k 2002-06-24 14:13 ` Daniel Jacobowitz @ 2002-06-24 14:40 ` Peter Barada 2002-06-24 14:56 ` Peter Barada 0 siblings, 1 reply; 19+ messages in thread From: Peter Barada @ 2002-06-24 14:40 UTC (permalink / raw) To: drow; +Cc: Peter.Barada, gdb > >You might want to try disabling binary download in your stub just to >make sure... normally, the client will remove breakpoints itself. This >definitely still works in 5.2. What's 'binary download'? Is that the 'X' command in the remote protocol? As an experiment, I disabled it, and the results are still the same... >You also should try with 5.2 or CVS rather than 5.1.1, probably... I'm grabbing and building it now. I'll post an update tomorrow. -- Peter Barada Peter.Barada@motorola.com Wizard 781-852-2768 (direct) WaveMark Solutions(wholly owned by Motorola) 781-270-0193 (fax) ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Torubles with remote stub for m68k 2002-06-24 14:40 ` Peter Barada @ 2002-06-24 14:56 ` Peter Barada 2002-06-24 15:07 ` Daniel Jacobowitz 0 siblings, 1 reply; 19+ messages in thread From: Peter Barada @ 2002-06-24 14:56 UTC (permalink / raw) To: Peter.Barada; +Cc: drow, Peter.Barada, gdb >>> When I execute that with gdb-5.1.1, it attempts to step the processor >>> without removing the trap instruction so the target processor never >>> steps past the trap instruction. >> >>You also should try with 5.2 or CVS rather than 5.1.1, probably... > >I'm grabbing and building it now. I'll post an update tomorrow. > I got to it quicker than I thought. Nope, same problem as with gdb-5.1.1: [Switching to thread 1 (Thread 9)]#0 FRSfindfont ( name=0x1fd6b70 "AlbertusMT", idptr=0x1fd6b4c, ftype=0x1fd6b50, fclass=0x1fd6b54, font_mat=0x4c589c, painttype=0x1fd6b58, fontname=0x1fd6b5c) at ../pdi/fntsockt.c:604 604 if (fs_first_unused == (FRS_ID *) NULL) (gdb) show version GNU gdb 5.2 Copyright 2002 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-pc-linux-gnu --target=m68k-elf". (gdb) set debug remote 1 (gdb) si Sending packet: $Hc9#e4...Ack Packet received: OK Sending packet: $s#73...Ack Packet received: T05thread:9; Sending packet: $g#67...Ack Packet received: 0000000a00000000001fc9ac0000000501fd6b5c01fd6b58004c589c01fd6b54002161620021616d005e874001fd6b5001fd6b70005ca4cc01fd6ae001fd6ab04084a0000003af3c4046800000000000404ca5dc000000007fffffffffffffff7fffffffffffffff7fffffffffffffff7fffffffffffffff7fffffffffffffff7fffffffffffffff000000000000008800000000 604 if (fs_first_unused == (FRS_ID *) NULL) (gdb) p/x $pc $1 = 0x3af3c (gdb) si Sending packet: $s#73...Ack Packet received: T05thread:9; Sending packet: $g#67...Ack Packet received: 0000000a00000000001fc9ac0000000501fd6b5c01fd6b58004c589c01fd6b54002161620021616d005e874001fd6b5001fd6b70005ca4cc01fd6ae001fd6aac4084a0000003af3c4046800000000000404ca5dc000000007fffffffffffffff7fffffffffffffff7fffffffffffffff7fffffffffffffff7fffffffffffffff7fffffffffffffff000000000000008800000000 604 if (fs_first_unused == (FRS_ID *) NULL) (gdb) p/x $pc $2 = 0x3af3c (gdb) With gdb-5, if the stub doesn't use breakpoint registers, is it gdb's responsibility to save/restore the brekpoint across a 's' packet, or is that the stub's responsibility? Any help is appreciated! -- Peter Barada Peter.Barada@motorola.com Wizard 781-852-2768 (direct) WaveMark Solutions(wholly owned by Motorola) 781-270-0193 (fax) ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Torubles with remote stub for m68k 2002-06-24 14:56 ` Peter Barada @ 2002-06-24 15:07 ` Daniel Jacobowitz 2002-06-24 15:30 ` Andrew Cagney 2002-06-25 8:13 ` Peter Barada 0 siblings, 2 replies; 19+ messages in thread From: Daniel Jacobowitz @ 2002-06-24 15:07 UTC (permalink / raw) To: Peter Barada; +Cc: Peter.Barada, gdb On Mon, Jun 24, 2002 at 05:56:48PM -0400, Peter Barada wrote: > > >>> When I execute that with gdb-5.1.1, it attempts to step the processor > >>> without removing the trap instruction so the target processor never > >>> steps past the trap instruction. > >> > >>You also should try with 5.2 or CVS rather than 5.1.1, probably... > > > >I'm grabbing and building it now. I'll post an update tomorrow. > > > > I got to it quicker than I thought. Nope, same problem as with gdb-5.1.1: > > [Switching to thread 1 (Thread 9)]#0 FRSfindfont ( > name=0x1fd6b70 "AlbertusMT", idptr=0x1fd6b4c, ftype=0x1fd6b50, > fclass=0x1fd6b54, font_mat=0x4c589c, painttype=0x1fd6b58, > fontname=0x1fd6b5c) at ../pdi/fntsockt.c:604 > 604 if (fs_first_unused == (FRS_ID *) NULL) > (gdb) show version > GNU gdb 5.2 > Copyright 2002 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-pc-linux-gnu --target=m68k-elf". > (gdb) set debug remote 1 > (gdb) si > Sending packet: $Hc9#e4...Ack > Packet received: OK > Sending packet: $s#73...Ack > Packet received: T05thread:9; > Sending packet: $g#67...Ack > Packet received: 0000000a00000000001fc9ac0000000501fd6b5c01fd6b58004c589c01fd6b54002161620021616d005e874001fd6b5001fd6b70005ca4cc01fd6ae001fd6ab04084a0000003af3c4046800000000000404ca5dc000000007fffffffffffffff7fffffffffffffff7fffffffffffffff7fffffffffffffff7fffffffffffffff7fffffffffffffff000000000000008800000000 > 604 if (fs_first_unused == (FRS_ID *) NULL) > (gdb) p/x $pc > $1 = 0x3af3c > (gdb) si > Sending packet: $s#73...Ack > Packet received: T05thread:9; > Sending packet: $g#67...Ack > Packet received: 0000000a00000000001fc9ac0000000501fd6b5c01fd6b58004c589c01fd6b54002161620021616d005e874001fd6b5001fd6b70005ca4cc01fd6ae001fd6aac4084a0000003af3c4046800000000000404ca5dc000000007fffffffffffffff7fffffffffffffff7fffffffffffffff7fffffffffffffff7fffffffffffffff7fffffffffffffff000000000000008800000000 > 604 if (fs_first_unused == (FRS_ID *) NULL) > (gdb) p/x $pc > $2 = 0x3af3c > (gdb) > > With gdb-5, if the stub doesn't use breakpoint registers, is it gdb's > responsibility to save/restore the brekpoint across a 's' packet, or > is that the stub's responsibility? > > Any help is appreciated! If GDB sets the breakpoint using 'M' (or presumably 'X') commands, then it is the client's responsibility to clear it. It would be nice to know why that isn't happening. To observe it in action you can use gdbserver on a GNU/Linux system... -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Torubles with remote stub for m68k 2002-06-24 15:07 ` Daniel Jacobowitz @ 2002-06-24 15:30 ` Andrew Cagney 2002-06-24 15:35 ` Quality Quorum 2002-06-25 7:53 ` Peter Barada 2002-06-25 8:13 ` Peter Barada 1 sibling, 2 replies; 19+ messages in thread From: Andrew Cagney @ 2002-06-24 15:30 UTC (permalink / raw) To: Daniel Jacobowitz, Peter Barada; +Cc: Peter.Barada, gdb > With gdb-5, if the stub doesn't use breakpoint registers, is it gdb's >> responsibility to save/restore the brekpoint across a 's' packet, or >> is that the stub's responsibility? >> >> Any help is appreciated! > > > If GDB sets the breakpoint using 'M' (or presumably 'X') commands, then > it is the client's responsibility to clear it. It would be nice to > know why that isn't happening. To observe it in action you can use > gdbserver on a GNU/Linux system... Try a: (gdb) maint print architecture OUTPUTFILE and check what the value of the single step macros are. Your specific m68k target (configured as?) may have software single step settings that contradict what the target supports. cf gdb/274. http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gdb&pr=274 Andrew ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Torubles with remote stub for m68k 2002-06-24 15:30 ` Andrew Cagney @ 2002-06-24 15:35 ` Quality Quorum 2002-06-25 7:53 ` Peter Barada 1 sibling, 0 replies; 19+ messages in thread From: Quality Quorum @ 2002-06-24 15:35 UTC (permalink / raw) To: Andrew Cagney; +Cc: Daniel Jacobowitz, Peter Barada, Peter.Barada, gdb On Mon, 24 Jun 2002, Andrew Cagney wrote: > > With gdb-5, if the stub doesn't use breakpoint registers, is it gdb's > >> responsibility to save/restore the brekpoint across a 's' packet, or > >> is that the stub's responsibility? > >> > >> Any help is appreciated! > > > > > > If GDB sets the breakpoint using 'M' (or presumably 'X') commands, then > > it is the client's responsibility to clear it. It would be nice to > > know why that isn't happening. To observe it in action you can use > > gdbserver on a GNU/Linux system... > > Try a: > > (gdb) maint print architecture OUTPUTFILE > > and check what the value of the single step macros are. Your specific > m68k target (configured as?) may have software single step settings that > contradict what the target supports. BTW, it will be nice to have this feature dynamically configurable. > > cf gdb/274. > http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gdb&pr=274 > > Andrew > > Thanks, Aleksey ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Torubles with remote stub for m68k 2002-06-24 15:30 ` Andrew Cagney 2002-06-24 15:35 ` Quality Quorum @ 2002-06-25 7:53 ` Peter Barada 2002-06-25 10:44 ` Andrew Cagney 1 sibling, 1 reply; 19+ messages in thread From: Peter Barada @ 2002-06-25 7:53 UTC (permalink / raw) To: ac131313; +Cc: drow, Peter.Barada, Peter.Barada, gdb >Try a: > >(gdb) maint print architecture OUTPUTFILE > >and check what the value of the single step macros are. Your specific >m68k target (configured as?) may have software single step settings that >contradict what the target supports. Ok, and what do I look for in the dump? I see: gdbarch_dump: MEMORY_INSERT_BREAKPOINT(addr, contents_cache) # (default_memory_insert_breakpoint (addr, contents_cache)) gdbarch_dump: MEMORY_REMOVE_BREAKPOINT(addr, contents_cache) # (default_memory_remove_breakpoint (addr, contents_cache)) But what else should I look for? I don't see anything that has 'step' in the name. -- Peter Barada Peter.Barada@motorola.com Wizard 781-852-2768 (direct) WaveMark Solutions(wholly owned by Motorola) 781-270-0193 (fax) ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Torubles with remote stub for m68k 2002-06-25 7:53 ` Peter Barada @ 2002-06-25 10:44 ` Andrew Cagney 2002-06-25 9:38 ` Peter Barada 2002-06-25 10:02 ` Daniel Jacobowitz 0 siblings, 2 replies; 19+ messages in thread From: Andrew Cagney @ 2002-06-25 10:44 UTC (permalink / raw) To: Peter Barada; +Cc: drow, Peter.Barada, gdb > Try a: >> >>(gdb) maint print architecture OUTPUTFILE >> >>and check what the value of the single step macros are. > Your specific >>m68k target (configured as?) may have software single step settings that >>contradict what the target supports. How did you configure your m68k target? > Ok, and what do I look for in the dump? I see: > > gdbarch_dump: MEMORY_INSERT_BREAKPOINT(addr, contents_cache) # (default_memory_insert_breakpoint (addr, contents_cache)) > gdbarch_dump: MEMORY_REMOVE_BREAKPOINT(addr, contents_cache) # (default_memory_remove_breakpoint (addr, contents_cache)) > > But what else should I look for? I don't see anything that has 'step' in the name. SOFTWARE_SINGLE_STEP_P and SOFTWARE_SINGLE_STEP. Neither appear to be defined by the m68k targets. This indicates that the m68k [in current gdb] does not support software single step. Andrew ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Torubles with remote stub for m68k 2002-06-25 10:44 ` Andrew Cagney @ 2002-06-25 9:38 ` Peter Barada 2002-06-25 13:28 ` Andrew Cagney 2002-06-25 10:02 ` Daniel Jacobowitz 1 sibling, 1 reply; 19+ messages in thread From: Peter Barada @ 2002-06-25 9:38 UTC (permalink / raw) To: ac131313; +Cc: Peter.Barada, drow, Peter.Barada, gdb >> Try a: >>> >>>(gdb) maint print architecture OUTPUTFILE >>> >>>and check what the value of the single step macros are. > >> Your specific >>>m68k target (configured as?) may have software single step settings that >>>contradict what the target supports. > >How did you configure your m68k target? /home/pbarada/work/cvs-wavemark/cross-linux-tools/gdb-5.2/configure --host=i686-pc-linux-gnu --target=m68k-elf --prefix=/usr/local/wave/cross-test-304+12 --norecursion >> Ok, and what do I look for in the dump? I see: >> >> gdbarch_dump: MEMORY_INSERT_BREAKPOINT(addr, contents_cache) # (default_memory_insert_breakpoint (addr, contents_cache)) >> gdbarch_dump: MEMORY_REMOVE_BREAKPOINT(addr, contents_cache) # (default_memory_remove_breakpoint (addr, contents_cache)) >> >> But what else should I look for? I don't see anything that has 'step' in the name. > >SOFTWARE_SINGLE_STEP_P and SOFTWARE_SINGLE_STEP. > >Neither appear to be defined by the m68k targets. This indicates that >the m68k [in current gdb] does not support software single step. > What does that mean(the stub doesn't support single step?)? -- Peter Barada Peter.Barada@motorola.com Wizard 781-852-2768 (direct) WaveMark Solutions(wholly owned by Motorola) 781-270-0193 (fax) ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Torubles with remote stub for m68k 2002-06-25 9:38 ` Peter Barada @ 2002-06-25 13:28 ` Andrew Cagney 0 siblings, 0 replies; 19+ messages in thread From: Andrew Cagney @ 2002-06-25 13:28 UTC (permalink / raw) To: Peter Barada; +Cc: Peter.Barada, drow, gdb >>> Ok, and what do I look for in the dump? I see: >>> >>> gdbarch_dump: MEMORY_INSERT_BREAKPOINT(addr, contents_cache) # (default_memory_insert_breakpoint (addr, contents_cache)) >>> gdbarch_dump: MEMORY_REMOVE_BREAKPOINT(addr, contents_cache) # (default_memory_remove_breakpoint (addr, contents_cache)) >>> >>> But what else should I look for? I don't see anything that has 'step' in the name. > >> >>SOFTWARE_SINGLE_STEP_P and SOFTWARE_SINGLE_STEP. >> >>Neither appear to be defined by the m68k targets. This indicates that >>the m68k [in current gdb] does not support software single step. >> > > > What does that mean(the stub doesn't support single step?)? The target doesn't support single step using software. However, I think I've been barking up the wrong tree :-( Andrew ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Torubles with remote stub for m68k 2002-06-25 10:44 ` Andrew Cagney 2002-06-25 9:38 ` Peter Barada @ 2002-06-25 10:02 ` Daniel Jacobowitz 1 sibling, 0 replies; 19+ messages in thread From: Daniel Jacobowitz @ 2002-06-25 10:02 UTC (permalink / raw) To: Andrew Cagney; +Cc: Peter Barada, Peter.Barada, gdb On Tue, Jun 25, 2002 at 12:25:54PM -0400, Andrew Cagney wrote: > >Try a: > >> > >>(gdb) maint print architecture OUTPUTFILE > >> > >>and check what the value of the single step macros are. > > > Your specific > >>m68k target (configured as?) may have software single step settings that > >>contradict what the target supports. > > How did you configure your m68k target? > > >Ok, and what do I look for in the dump? I see: > > > >gdbarch_dump: MEMORY_INSERT_BREAKPOINT(addr, contents_cache) # > >(default_memory_insert_breakpoint (addr, contents_cache)) > >gdbarch_dump: MEMORY_REMOVE_BREAKPOINT(addr, contents_cache) # > >(default_memory_remove_breakpoint (addr, contents_cache)) > > > >But what else should I look for? I don't see anything that has 'step' in > >the name. > > SOFTWARE_SINGLE_STEP_P and SOFTWARE_SINGLE_STEP. > > Neither appear to be defined by the m68k targets. This indicates that > the m68k [in current gdb] does not support software single step. Peter was originally talking about memory (software) breakpoints, not software single step; are these important in that case? -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Torubles with remote stub for m68k 2002-06-24 15:07 ` Daniel Jacobowitz 2002-06-24 15:30 ` Andrew Cagney @ 2002-06-25 8:13 ` Peter Barada 2002-06-25 8:17 ` Daniel Jacobowitz 1 sibling, 1 reply; 19+ messages in thread From: Peter Barada @ 2002-06-25 8:13 UTC (permalink / raw) To: drow; +Cc: Peter.Barada, Peter.Barada, gdb >> Any help is appreciated! > >If GDB sets the breakpoint using 'M' (or presumably 'X') commands, then >it is the client's responsibility to clear it. It would be nice to >know why that isn't happening. To observe it in action you can use >gdbserver on a GNU/Linux system... Huh? That doesn't make sense(at least to me)... Why would gdb go to all the trouble of writing the breakpoint and the force the stub to remove it? Does the stub have to remove the breakpoint when gdb is reading memory(say for x/10i $pc)? How can the stub manage an unbounded number of breakpoints this way(wouldn't the stub be required to allocate memory)? Where in the documentation is this 'symbiosis' mentioned where gdb sets breakpoints and the stub is responsible for removing them while stepping? Besides, this stub works fine with gdb-4.16 and gdb-4.18, so what's changed? I can see that if the 'Z' commands are used to set breakpoints then the stub is responsible for managing them, but not the 'M' command... Again, any help is appreciated! -- Peter Barada Peter.Barada@motorola.com Wizard 781-852-2768 (direct) WaveMark Solutions(wholly owned by Motorola) 781-270-0193 (fax) ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Torubles with remote stub for m68k 2002-06-25 8:13 ` Peter Barada @ 2002-06-25 8:17 ` Daniel Jacobowitz 2002-06-25 8:32 ` Peter Barada 0 siblings, 1 reply; 19+ messages in thread From: Daniel Jacobowitz @ 2002-06-25 8:17 UTC (permalink / raw) To: Peter Barada; +Cc: Peter.Barada, gdb On Tue, Jun 25, 2002 at 11:12:59AM -0400, Peter Barada wrote: > > >> Any help is appreciated! > > > >If GDB sets the breakpoint using 'M' (or presumably 'X') commands, then > >it is the client's responsibility to clear it. It would be nice to > >know why that isn't happening. To observe it in action you can use > >gdbserver on a GNU/Linux system... > > Huh? That doesn't make sense(at least to me)... > Why would gdb go to all the trouble of writing the breakpoint and the > force the stub to remove it? Does the stub have to remove the > breakpoint when gdb is reading memory(say for x/10i $pc)? How can the > stub manage an unbounded number of breakpoints this way(wouldn't the > stub be required to allocate memory)? Where in the documentation is > this 'symbiosis' mentioned where gdb sets breakpoints and the stub is > responsible for removing them while stepping? > > Besides, this stub works fine with gdb-4.16 and gdb-4.18, so what's changed? > > I can see that if the 'Z' commands are used to set breakpoints then > the stub is responsible for managing them, but not the 'M' command... > > Again, any help is appreciated! Terminology skew. "the client" is GDB, not the stub; the stub is essentially a server, like gdbserver is. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Torubles with remote stub for m68k 2002-06-25 8:17 ` Daniel Jacobowitz @ 2002-06-25 8:32 ` Peter Barada 2002-06-25 8:40 ` Daniel Jacobowitz 0 siblings, 1 reply; 19+ messages in thread From: Peter Barada @ 2002-06-25 8:32 UTC (permalink / raw) To: drow; +Cc: Peter.Barada, Peter.Barada, gdb >Terminology skew. "the client" is GDB, not the stub; the stub is >essentially a server, like gdbserver is. Ahh, that makes a bit more sense. Where in the 'client' does it actually remove the breakpoint? I'll start debugging gdb to see why that isn't happening... -- Peter Barada Peter.Barada@motorola.com Wizard 781-852-2768 (direct) WaveMark Solutions(wholly owned by Motorola) 781-270-0193 (fax) ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Torubles with remote stub for m68k 2002-06-25 8:32 ` Peter Barada @ 2002-06-25 8:40 ` Daniel Jacobowitz 0 siblings, 0 replies; 19+ messages in thread From: Daniel Jacobowitz @ 2002-06-25 8:40 UTC (permalink / raw) To: Peter Barada; +Cc: Peter.Barada, gdb On Tue, Jun 25, 2002 at 11:32:36AM -0400, Peter Barada wrote: > > >Terminology skew. "the client" is GDB, not the stub; the stub is > >essentially a server, like gdbserver is. > > Ahh, that makes a bit more sense. > Where in the 'client' does it actually remove the breakpoint? I'll > start debugging gdb to see why that isn't happening... Something like memory_remove_breakpoints, I believe... dig, dig.... via remove_breakpoints (). I believe via the call in infrun.c:normal_stop, but it's been some time. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Torubles with remote stub for m68k 2002-06-24 14:04 ` Torubles with remote stub for m68k Peter Barada 2002-06-24 14:13 ` Daniel Jacobowitz @ 2002-06-25 13:43 ` Andrew Cagney 1 sibling, 0 replies; 19+ messages in thread From: Andrew Cagney @ 2002-06-25 13:43 UTC (permalink / raw) To: Peter Barada; +Cc: gdb > (gdb) c > Continuing. > Sending packet: $Z0,3af78,2#7d...Ack > Packet received: > Packet Z0 (software-breakpoint) is NOT supported > Sending packet: $m3af78,2#34...Ack > Packet received: 4ab9 > Sending packet: $X3af78,0:#57...Ack > Packet received: OK > binary downloading suppported by target > Sending packet: $X3af78,2:NA#e8...Ack Set breakpoint at address 3af78. > Packet received: OK > Sending packet: $Hc0#db...Ack > Packet received: ENN > Sending packet: $c#63...Ack > Packet received: T05thread:9; > [New Thread 9] > Sending packet: $g#67...Ack > Packet received: 00000000000000000000006300000000004b47b8000000000000000000000000000000000000000000012ca000012c240000000000000000005c34d4005c34c8000000000014a898000000000000000000000000000000007fffffffffffffff7fffffffffffffff7fffffffffffffff7fffffffffffffff7fffffffffffffff7fffffffffffffff7fffffffffffffff7fffffffffffffff7fffffffffffffff7fffffffffffffff7fffffffffffffff0000000000000000000000000000000000000000 For some reason here, GDB didn't pull all breakpoints. GDB normally pulls all breakpoints as part of a stop. I suspect this is why the breakpoint is still in memory when you go to SI - GDB doesn't think it needs to pull any breakpoints. > Program received signal SIGTRAP, Trace/breakpoint trap. Is the target sitting on a breakpoint? If it is GDB should report that breakpoint but it hasn't. What is the raw value of the PC as found in the G packet (rather than what $pc displays at this point?). The m68k is one of the decr pc after break targets [true] so likely it is getting that wrong. Andrew ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2002-06-25 20:43 UTC | newest] Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2002-06-24 12:46 [MI/testsuite] mi_gdb_test: expected result priority? Keith Seitz 2002-06-24 13:20 ` Elena Zannoni 2002-06-24 14:04 ` Torubles with remote stub for m68k Peter Barada 2002-06-24 14:13 ` Daniel Jacobowitz 2002-06-24 14:40 ` Peter Barada 2002-06-24 14:56 ` Peter Barada 2002-06-24 15:07 ` Daniel Jacobowitz 2002-06-24 15:30 ` Andrew Cagney 2002-06-24 15:35 ` Quality Quorum 2002-06-25 7:53 ` Peter Barada 2002-06-25 10:44 ` Andrew Cagney 2002-06-25 9:38 ` Peter Barada 2002-06-25 13:28 ` Andrew Cagney 2002-06-25 10:02 ` Daniel Jacobowitz 2002-06-25 8:13 ` Peter Barada 2002-06-25 8:17 ` Daniel Jacobowitz 2002-06-25 8:32 ` Peter Barada 2002-06-25 8:40 ` Daniel Jacobowitz 2002-06-25 13:43 ` Andrew Cagney
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 read-only IMAP folder(s) and NNTP newsgroup(s).