From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22223 invoked by alias); 12 Mar 2005 11:29:06 -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 22013 invoked from network); 12 Mar 2005 11:28:49 -0000 Received: from unknown (HELO galaxy.systems.pipex.net) (62.241.162.31) by sourceware.org with SMTP; 12 Mar 2005 11:28:49 -0000 Received: from dsl.pipex.com (81-86-67-130.dsl.pipex.com [81.86.67.130]) by galaxy.systems.pipex.net (Postfix) with ESMTP id 4E564E0001E6; Sat, 12 Mar 2005 11:28:49 +0000 (GMT) Message-ID: <4232D267.10303@dsl.pipex.com> Date: Sat, 12 Mar 2005 11:29:00 -0000 From: RT User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 MIME-Version: 1.0 To: tromey@redhat.com Cc: 'Atul Talesara' , 'Hareesh Nagarajan' , 'GDB' Subject: Re: Is it possible to save breakpoints to a file? References: <423070F6.40500@dsl.pipex.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2005-03/txt/msg00136.txt.bz2 Tom Tromey wrote: >>>>>>"RT" == RT writes: > > >>>If you are using the insight GUI for gdb, that will save your breakpoints >>>for you as part of the project preferences. It writes them into .gdbinit >>>automatically and reloads them next time you're debugging the same >>>executable. > > > RT> Which makes life rather difficult if you have a break set in a shared > RT> library. If you reply 'yes' by mistake when Insight asks if you want > RT> to make the break pending on the library load, then gdb will rapidly > RT> crash. > > I don't know if this is in the gdb bug database; it should be. I haven't looked at this in detail. I suspect the problem is that Insight is no longer actively maintained, and so it's difficult to get a version of insight that uses the current gdb. There's no point filing bugs that are Insight-specific; there's no one to work on them. A trivial licensing problem has lead to gdb having no usable GUI (that I know of, anyway; and I've used both ddd and insight). If anyone at the FSF knows of a way to debug multi-threaded shared-library apps without a GUI, then I'd be really pleased to hear from them. And, if I don't hear from them, I guess that they'll agree that gdb is an 80's dinosaur, and it's time to put it to bed. - Richard