[cdt-debug-dev] What does CDT expect from gdb ?

[Kim Lux <lux@xxxxxxxxxxxxxxxxxxx>]

We've decided that we'll use multiple instances of gdb in multiple debug
perspectives to debug our dual processor device. 

I am setting up gdb for the first processor and running into a few
issues.

I have the Eclipse debug object set up as follows:

Project: S12dbugTest
C/C++ Application: test.elf
Arguments: <empty>
Use default working directory: checked
Environment Variables <empty>
Debugger: GDB Debugger
Stop at main on startup: checked
Automatically track the values of Variables: check. Registers: check.
Protocol: mi
GDB debugger: /usr/bin/m6811-elf-gdb
GDB command file: ~/.../dbug12.init
Source Lookup Path: default.  Points right to test.c
Common: Save as: Local file, Launch in background

When I run this debug target I get the following error:

Failed to set program arguments, environment or working directory.
	Unable to set working directory: Target is not responding (timed out).

In Windows-> Preferences->C/C++=>Debug, I have the following set up:

Show full paths: checked
Default {variable, expression, register} format: Natural
Disassembly options: Max number of displayed Instructions: 100
Common source lookup path: <empty>
GDB MI: Debugger timeout: 10,000.  Launch timeout: 30,000
Automatically refresh modules: checked

I checked out this:
https://www.redhat.com/docs/manuals/enterprise/RHEL-3-Manual/gdb/gdb-mi-command-syntax.html

but without knowing what Eclipse is sending, I'm kind of lost.

Questions:

a) Is there a manual or help somewhere that explains how to set up the
debugger for non standard targets. (Thus far all my "on PC" targets have
worked perfectly.

b) is there a way to echo the comm between Eclipse and gdb so that I can
see the commands that are being issued, etc. 

c) these gdb back ends have a limited number of breakpoints available.
Does Eclipse use a "debug settings" file to set a "max" for the target ?

d) What is Eclipse expecting such that I get this error ?  Do I have to
strip out all the non essential reply from our version of gdb ?

Here is an example session that I ran manually on the same target/code.
No command in the manual session takes more than a second or two.
dbug12.init follows as well. 

Thanks in advance.  Eclipse ROCKS ! 

==================================================================
$ m6811-elf-gdb -x dbug12.init test.elf
GNU gdb 6.2-m68hc1x-2004-08-01
Copyright 2004 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=m6811-elf"...
The target architecture is assumed to be m68hc12
entering dbugS12_wait()
Wait:
S>
leaving dbugS12_wait()
[Switching to process -1]
main () at test.c:34
34              PORTM = 0x03;

Target CPU Has Been Reset
S>

Target CPU Has Been Reset
S>

All Breakpoints Removed
S>
Breakpoint 1 at 0xc03b: file test.c, line 24.
---Type <return> to continue, or q <return> to quit---
Setting breakpoint: addr=C03B
entering dbugS12_wait()
Wait:

User Bkpt Encountered

PP  PC    SP    X     Y    D = A:B   CCR = SXHI NZVC
00 C03B  3FF7  1002  1000     00:00        1101 0000
xx:C03B  180B030252    MOVB  #$03,$0252

S>
leaving dbugS12_wait()

Breakpoint 1, main () at test.c:24
24      PORTM_DDR = 0x03 ; //Let all pins 0 and 1 be output ports on
PORTM
(gdb) nexti
entering dbugS12_wait()
Wait:

PP  PC    SP    X     Y    D = A:B   CCR = SXHI NZVC
00 C040  3FF7  1002  1000     00:00        1101 0000
xx:C040  180B030250    MOVB  #$03,$0250

S>
leaving dbugS12_wait()
m68hc11_unwind_pc(): returning 00C040
m68hc11_unwind_pc(): returning 00C040
34              PORTM = 0x03;
(gdb) nexti
Setting breakpoint: addr=C03B
entering dbugS12_wait()
Wait:

PP  PC    SP    X     Y    D = A:B   CCR = SXHI NZVC
00 C045  3FF7  1002  1000     00:00        1101 0000
xx:C045  FE1000        LDX   $1000

S>
leaving dbugS12_wait()
m68hc11_unwind_pc(): returning 00C045
m68hc11_unwind_pc(): returning 00C045
37              for (lCount = 0; lCount < WAITCOUNT; lCount++);
(gdb) nexti
Setting breakpoint: addr=C03B
entering dbugS12_wait()
Wait:

PP  PC    SP    X     Y    D = A:B   CCR = SXHI NZVC
00 C048  3FF7  3FF7  1000     00:00        1101 0000
xx:C048  6902          CLR   2,X

S>
leaving dbugS12_wait()
m68hc11_unwind_pc(): returning 00C048
m68hc11_unwind_pc(): returning 00C048
0x0000c048      37              for (lCount = 0; lCount < WAITCOUNT;
lCount++);
(gdb) nexti
Setting breakpoint: addr=C03B
entering dbugS12_wait()
Wait:

PP  PC    SP    X     Y    D = A:B   CCR = SXHI NZVC
00 C04A  3FF7  3FF7  1000     00:00        1101 0100
xx:C04A  6903          CLR   3,X

S>
leaving dbugS12_wait()
m68hc11_unwind_pc(): returning 00C04A
m68hc11_unwind_pc(): returning 00C04A
0x0000c04a      37              for (lCount = 0; lCount < WAITCOUNT;
lCount++);
(gdb) quit
The program is running.  Exit anyway? (y or n) y
==================================================================

dbug12.init:

set architecture m68hc12
set remotebaud 19200
target dbugS12 /dev/ttyUSB0
pod reset
pod reset
pod nobr
delete
break main











-- 
Kim Lux,  Diesel Research Inc.