This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

gdb stubs problem


I'm having an issue with gdb/redboot/eCos when my application hits a breakpoint.

I'm using an ecos-3.0 [+] port from a vendor (rather not say who at
the moment, but the cpu is a mips32 24kec).
I added a network driver to Redboot, and am running gdb stubs there.
For a small test eCos application, everything works great. I can load,
run, interrupt system, break-point, continue, etc. No problems.

When I try debugging a larger eCos application (30Mbyte elf image, ~70
threads), gdb works okay until the app starts spawning lots of threads
( which are a mixture of eCos threads and pthreads). After that point,
I can start/pause the application repeatedly without issue, but if I
try to look at another thread's stack, or hit a breakpoint in one of
the new threads, things go badly.

By badly I mean something in eCos seems to get into a tight loop and
the application console becomes very laggy. gdb starts printing
'ignoring protocol error' repeatedly. From wireshark, it appears that
gdb and stubs are exchanging only ack and nack messages (+ and -).
Not sure why the target is sending multiple T05thread messages, or why
the acks seem to get out of order with the requests. I can still ping
the Redboot IP, but if I try to ping the eCos IP it is very laggy.

Wireshark analysis of tcp stream from when breakpoint is hit:
$T05thread:0000000a;25:1c870e80;1d:b02a5781;#37+
$g#67
$T05thread:0000000a;25:1c870e80;1d:b02a5781;#37+
$T05thread:0000000a;25:1c870e80;1d:b02a5781;#37+
$T05thread:0000000a;25:1c870e80;1d:b02a5781;#37+
$g#67
$g#67
$g#67
---+---+--  [this sequence repeats forever]

A similar trace from my test application when successfully hitting a breakpoint:

$T02thread:00000005;25:48260480;1d:a82f1280;#aa+
$g#67+
$00000000feffffff0100000000001380000000000200000000000380000003800104001000000380140b
0000c8c82780000000000d0005050e0005050f00050510000505110005051200050513000505140005051
50005051600050517000505180005051900050588301280a8b01180901d1280a82f1280a82f1280482604
8003040010c3c300000068000000000000248000504826048000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000#a4+
$X800401d8,4:ïïï}#a6+
$OK#9a+
$X8004f5ac,4:s=^L#da+
$OK#9a+
$X8004f9d8,4:
$OK#9a+
$T5#89+
$OK#9a+
$T4#88+
$OK#9a+
..., everything works fine here.

My current hypothesis is that I'm hitting some kind of limit in
gdb/stubs/ecos related to using lots of threads (or a mixture of posix
and eCos threads), but not sure where to start looking. I'm hoping
somebody has seen something like this before or has some ideas for
debugging this problem.

Regards,
Bob Cagle
bobcagle@gmail.com

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]