From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18295 invoked by alias); 12 Nov 2004 15:30:51 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 18072 invoked from network); 12 Nov 2004 15:30:42 -0000 Received: from unknown (HELO smtp812.mail.ukl.yahoo.com) (217.12.12.202) by sourceware.org with SMTP; 12 Nov 2004 15:30:42 -0000 Received: from unknown (HELO shuttle) (gdb@sources.redhat.com@81.155.128.77 with poptime) by smtp812.mail.ukl.yahoo.com with SMTP; 12 Nov 2004 15:30:40 -0000 Date: Fri, 12 Nov 2004 16:25:00 -0000 From: Dave Cleal Reply-To: Dave Cleal Message-ID: <192758551.20041112153129@cleal.com> To: "Alain Magloire" CC: gdb@sources.redhat.com Subject: Re[4]: Can't talk to Angel debug monitor from arm-elf-gdb In-Reply-To: <200411120401.XAA23780@smtp.ott.qnx.com> References: <85244836.20041111225858@cleal.com> from "Dave Cleal" at Nov 11, 2004 10:58:58 PM <200411120401.XAA23780@smtp.ott.qnx.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2004-11/txt/msg00119.txt.bz2 Alain, sounds correct: and my copy of Eclipse (v3.0.1) has code to do exactly what you say in the GDBServer case. However, I'm working with GDB talking to the Redboot debug monitor down a serial port, so actually, GDBServer is not involved. I've written a patch which essentially treats this case like the GDBServer case, which I'll submit to the CDT project in due course. -- Dave >> >> Last time I'm going to do this. Just in case anyone else ever needs >> to know, this now all works. The trick is to patch CDT (the Eclipse >> plugin for C/C++ development) to recognise when you're connected via a >> serial port, and to have it start the program with a "continue" >> command not a "run" command. Everything thereafter works. >> > There was indeed a bug when using gdbserver, the state of the frontend > was incorrect, it should have consider the inferior "suspended" so to use > "continue" instead "run" since the inferior was already `loaded'. > Maybe MI commands like, > -target-select > -target-attach > should return an extra exec-async: > *stopped > Even if, like the case of -target-select there is no frame yet. > It would notify to the frontends that the inferior was loaded.