From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17002 invoked by alias); 6 May 2004 16:35:29 -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 16995 invoked from network); 6 May 2004 16:35:28 -0000 Received: from unknown (HELO omr4.netsolmail.com) (216.168.230.140) by sources.redhat.com with SMTP; 6 May 2004 16:35:28 -0000 Received: from ms5.netsolmail.com (IDENT:mirapoint@[216.168.230.178]) by omr4.netsolmail.com (8.12.10/8.12.10) with ESMTP id i46GdUhX016432 for ; Thu, 6 May 2004 12:39:35 -0400 (EDT) Received: from rivatek.dnsalias.net (rrcs-west-67-52-40-137.biz.rr.com [67.52.40.137]) by ms5.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id BGX71289; Thu, 6 May 2004 12:35:22 -0400 (EDT) Received: by rivatek.dnsalias.net (Postfix, from userid 500) id 004A1A9D9F; Thu, 6 May 2004 11:35:21 -0500 (CDT) Date: Thu, 06 May 2004 16:35:00 -0000 From: Grant Edwards To: gdb@sources.redhat.com Subject: Re: How to tell gdb to exit? Message-ID: <20040506163520.GA12806@grante.dsl.visi.com> References: <20040506155013.GB12206@grante.dsl.visi.com> <20040506160943.GA12676@grante.dsl.visi.com> <20040506161646.GA12706@grante.dsl.visi.com> <20040506161858.GA28172@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040506161858.GA28172@nevyn.them.org> User-Agent: Mutt/1.4.1i X-SW-Source: 2004-05/txt/msg00051.txt.bz2 On Thu, May 06, 2004 at 12:18:58PM -0400, Daniel Jacobowitz wrote: > > My bad. It looks like -target-disconnect works afer all. [of > > course I swear I tried it before and it didn't.] -gdb-exit > > still refuses to exit, but it will exit on EOF. > > > > So, this seems to work: > > > > #!/bin/bash > > h8300-elf-gdb -interpreter=mi < > 10-target-select async /dev/ttyS0 > > 20-target-download test.elf > > 30-exec-continue > > 40-target-disconnect > > EOF > > > > I messed around with this on and off for days, and couldn't > > find the answer, but as soon as I put my foot in my mouth > > publically, the answer appears. Odd, that. > > This will leave your target stopped, presumably. Perhaps it tries to stop the target, but it can't. Once the program starts, the gdb stub is "gone". My app has taken over the UART for use as console I/O, and it's no longer possible to communicate with the gdb stub[1]. It would be nice to have another UART so one could be used for console I/O and the other for GDB, but such is life. > The "disconnect" commandd for the CLI will do the same thing. > Is that what you want? With the CLI, you can only send the disconnect command after you've stopped the target. In my script above, I'm sending the disconnect command while the target is still running. I guess since it's no longer possible to stop the applicaion from gdb, it keeps running. Does that mean there's actually no way to tell gdb to "just exit"? By "just exit" I mean don't try to muck with the target: Just call exit(). [1] I do have gdb-mangling that I can enable in my console output routine so that I can have console output while continuing to use gdb+gdb-stub. But, there's no way to handle console input via gdb, so if I want to use console input, I have to cut gdb out of the loop rather unceremoniously. -- Grant Edwards grante@visi.com