[MI/testsuite] mi_gdb_test: expected result priority?

[MI/testsuite] mi_gdb_test: expected result priority?

[Keith Seitz]

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

Re: [MI/testsuite] mi_gdb_test: expected result priority?

[Elena Zannoni]

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

Torubles with remote stub for m68k

[Peter Barada]

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)

Re: Torubles with remote stub for m68k

[Daniel Jacobowitz]

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

Re: Torubles with remote stub for m68k

[Peter Barada]

>
>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)

Re: Torubles with remote stub for m68k

[Peter Barada]

>>> 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)

Re: Torubles with remote stub for m68k

[Daniel Jacobowitz]

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

Re: Torubles with remote stub for m68k

[Andrew Cagney]

> 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

Re: Torubles with remote stub for m68k

[Quality Quorum]

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

Re: Torubles with remote stub for m68k

[Peter Barada]

>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)

Re: Torubles with remote stub for m68k

[Peter Barada]

>> 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)

Re: Torubles with remote stub for m68k

[Daniel Jacobowitz]

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

Re: Torubles with remote stub for m68k

[Peter Barada]

>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)

Re: Torubles with remote stub for m68k

[Daniel Jacobowitz]

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

Re: Torubles with remote stub for m68k

[Peter Barada]

>> 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)

Re: Torubles with remote stub for m68k

[Daniel Jacobowitz]

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

Re: Torubles with remote stub for m68k

[Andrew Cagney]

> 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

Re: Torubles with remote stub for m68k

[Andrew Cagney]

>>> 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

Re: Torubles with remote stub for m68k

[Andrew Cagney]

> (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