remote debugging with m68k-stub

remote debugging with m68k-stub

[Squal]

Hello!

I have done all the remote target gdb instructions:
  - define all the low level routines
  - insert set_debug_traps(); and breakpoints(); at
    the beginning of the program
  - compiling stub and program together

After that, I downloaded my program and the m68k-stub in the target. 
My problem is when I start the program in the remote target, the program
stop and never restart (the halt indicator is set).
Normally, the program will stop at the breakpoint (TRAP #1) and will
continue after gdb be connected to the stub but the program seems to 
be stopped.

Somebody can help me ?

Thanks

Pascal

Re: remote debugging with m68k-stub

[Quality Quorum]

On Wed, 7 Aug 2002, Squal wrote:

> Hello!
>
> I have done all the remote target gdb instructions:
>   - define all the low level routines
>   - insert set_debug_traps(); and breakpoints(); at
>     the beginning of the program
>   - compiling stub and program together
>
> After that, I downloaded my program and the m68k-stub in the target.
> My problem is when I start the program in the remote target, the program
> stop and never restart (the halt indicator is set).
> Normally, the program will stop at the breakpoint (TRAP #1) and will
> continue after gdb be connected to the stub but the program seems to
> be stopped.

If you this is not the first time you are running gdb in this environment
check changes you made. If it is the first time it is quite possible that
you have conflict between you ROM monitor (I suspect this is what you call
target) initialization and gdb initialization.
>
> Somebody can help me ?

1. Use ICE if it is available

or


2. Trace the thing with characters sent to serial port.


>
> Thanks
>
> Pascal
>

There are simply no smart ways to debug initialization, also do not forget
to read you target doc, it is quite possible that they have some
debugging help.

Thanks,

Aleksey

Re: remote debugging with m68k-stub

[William A. Gatliff]

Pascal:


Here's a short list of things I usually screw up:

* Is someone setting up the bus state controller and other critical
peripherals properly before you download your program?

* Does the stub put the stack pointer in a useful place for the
application?  Does the application need to move its stack pointer to a
larger memory space durining initialization?

* Is application code accidentally getting placed on the stub or
application stack space?

* Are you downloading the program properly?  If you disassemble memory
after typing 'load' at the gdb prompt, you should see your code.

Immediate halts, in my case, usually signal a problem in the handoff
between the stub and the application during the 'step' and 'continue'
commands.  Focus on those parts of your implementation.

You don't need an "application" to test your stub.  Just use a memory
write command to write the opcode for TRAP #1 (or whatever your stub
will use for the breakpoint opcode) to a known memory location, read
it back to verify that it's there, set the PC to that address, and do
a continue.  You should get an immediate breakpoint exception.

Throw in a few NOP opcodes, and you can test 'stepi' as well.  Once
'continue' and 'stepi' are working, you're usually in pretty good
shape.

If you'd like a second stub implementation to use as a guide, see the
gdbstubs project at http://sourceforge.net/projects/gdbstubs .  It
supports CPU32.


HTH,


b.g.

On Wed, Aug 07, 2002 at 02:54:45PM +0200, Squal wrote:
> Hello!
> 
> I have done all the remote target gdb instructions:
>   - define all the low level routines
>   - insert set_debug_traps(); and breakpoints(); at
>     the beginning of the program
>   - compiling stub and program together
> 
> After that, I downloaded my program and the m68k-stub in the target. 
> My problem is when I start the program in the remote target, the program
> stop and never restart (the halt indicator is set).
> Normally, the program will stop at the breakpoint (TRAP #1) and will
> continue after gdb be connected to the stub but the program seems to 
> be stopped.
> 
> Somebody can help me ?
> 
> Thanks
> 
> Pascal

-- 
Bill Gatliff
bgat@billgatliff.com

remote debugging with m68k-stub

[Squal]

I'm trying to debug some program with the help of 
the m68k stub file. 
When I start the program in the remote target 
(motorola 68000) the connexion with gdb 
(in the host machine Sparc Sun Solaris) seems 
to be a succes:
	
	(gdb) target remote mark:5000
	Remote debugging using mark:5000
	0x00840007 in ?? ()
	(gdb) bt
	#0  0x00381118 in ?? ()
	#1  0x00010156 in ?? ()
	(gdb)

PS: 0x00840007 and 0x00381118 not corresponding
    to a correct memory acces.
A lot of data packet is send throw the serial link.


After that, I try to continue the program execution
with the continue gdb command: 	

	(gdb) c
	Continuing.
	Can't send signals to this remote system.  
	SIGEMT not sent.
	Program received signal SIGEMT, Emulation trap.
	0x00381118 in ?? ()

In the main function beginning I call the set_debug_traps
function to initialise exceptions address. After, I call
the Breakpoint function (TRAP #1) to connect with gdb.
During the execution the program never return of the
TRAP #1 exception (it stay in the handle_exception function).

I thing the problem can be a bad address reference.

What can I do to resume the program execution ??
If somebody has any idea, thanks to thing to me :-) 

Thanks

Pascal