From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32081 invoked by alias); 1 Feb 2013 02:00:11 -0000 Received: (qmail 32060 invoked by uid 22791); 1 Feb 2013 02:00:10 -0000 X-SWARE-Spam-Status: No, hits=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,KHOP_RCVD_TRUST,LOTS_OF_MONEY,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from mail-oa0-f54.google.com (HELO mail-oa0-f54.google.com) (209.85.219.54) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 01 Feb 2013 02:00:05 +0000 Received: by mail-oa0-f54.google.com with SMTP id n12so864896oag.13 for ; Thu, 31 Jan 2013 18:00:04 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.60.172.178 with SMTP id bd18mr8434363oec.133.1359684004533; Thu, 31 Jan 2013 18:00:04 -0800 (PST) Received: by 10.76.13.137 with HTTP; Thu, 31 Jan 2013 18:00:04 -0800 (PST) Date: Fri, 01 Feb 2013 02:00:00 -0000 Message-ID: From: Bob Cagle To: ecos-discuss@ecos.sourceware.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Subject: [ECOS] gdb stubs problem X-SW-Source: 2013-02/txt/msg00000.txt.bz2 I'm having an issue with gdb/redboot/eCos when my application hits a breakp= oint. 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 breakp= oint: $T02thread:00000005;25:48260480;1d:a82f1280;#aa+ $g#67+ $00000000feffffff0100000000001380000000000200000000000380000003800104001000= 000380140b 0000c8c82780000000000d0005050e0005050f0005051000050511000505120005051300050= 5140005051 50005051600050517000505180005051900050588301280a8b01180901d1280a82f1280a82f= 1280482604 8003040010c3c30000006800000000000024800050482604800000000000000000000000000= 0000000000 000000000000000000000000000000000000000000000000000000000000000000000000000= 0000000000 000000000000000000000000000000000000000000000000000000000000000000000000000= 0000000000 000000000000000000000000000000000000000000000000000000000000000000000000000= 0000000000 000000000000000000000000000000000000000000000000000000000000000000000000000= 0000000000 00000000000000000000000000000000000000000#a4+ $X800401d8,4:=EF=BF=BD=EF=BF=BD=EF=BF=BD}#a6+ $OK#9a+ $X8004f5ac,4:s=3D^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