From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27779 invoked by alias); 11 Aug 2009 21:00:10 -0000 Received: (qmail 27752 invoked by uid 22791); 11 Aug 2009 21:00:09 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx2.redhat.com (HELO mx2.redhat.com) (66.187.237.31) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 11 Aug 2009 21:00:01 +0000 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n7BKxxBZ022230; Tue, 11 Aug 2009 16:59:59 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n7BKxvnA005474; Tue, 11 Aug 2009 16:59:58 -0400 Received: from opsy.redhat.com (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n7BKxurO002515; Tue, 11 Aug 2009 16:59:56 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id F3A363782B4; Tue, 11 Aug 2009 14:59:55 -0600 (MDT) To: marcov@stack.nl (Marco van de Voort) Cc: gdb@sourceware.org Subject: Re: errors in GDB reading symbols References: <20090807204753.8BC8C33CA1@turtle.stack.nl> From: Tom Tromey Reply-To: Tom Tromey Date: Tue, 11 Aug 2009 21:00:00 -0000 In-Reply-To: <20090807204753.8BC8C33CA1@turtle.stack.nl> (Marco van de Voort's message of "Fri\, 7 Aug 2009 22\:47\:53 +0200 \(CEST\)") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2009-08/txt/msg00076.txt.bz2 Marco> Partially the earlier own debugger discussion is fueled by one of Marco> the improvements of FPC's internal linker relative to LD, the Marco> experience that makes the call for an own debugger so vocal. It Marco> knocks off tens of seconds in the compile-start-with-debug cycle, Marco> and makes GDB the next bottleneck (this is for Lazarus, not the Marco> textmode IDE) FWIW, I'm definitely interested in speed problems in GDB. If you find them, and can characterize them nicely, please file bug reports. Marco> Forcing the MI interface would effectively kill the textmode IDE, it is Marco> effectively in maintenance for years. If there is something to be done on Marco> the GDB side, I'd prefer investing time in libgdb. What are the problems Marco> with it? Does something need updating, etc? I think that historically libgdb is just an idea that never really got beyond the "put a lot of .o files into libgdb.a" stage. When I look at GDB, I think there are a few things that make it a less than great library: * No use of namespaces for functions and globals * ABI changes every release * Unfriendly "embedding" behavior: takes over signals, requires application discipline about calling wait(), etc. I guess those are the big ones. If they don't bother you, cool. Marco> I don't see the point of the MI interface at all btw. What is the idea Marco> behind it? And why does it need to be one size fits all to desperately? I'm not really aware of the full history of MI, but one big advantage is that lots of people use it and it is supported. I suppose the basic idea is that a text-based protocol is more future-proof than a binary ABI. (Of course this is not intrinsically true, but it is made true because I don't think that restricting GDB to be ABI-compatible is reasonable.) I have two reasons I would want to remove libgdb. First, I think that supporting gdb-as-a-library is too much work for not enough payoff. (Though this reason is somewhat deflated if you don't mind the "anything goes" approach.) Second, libgdb.a slows down the build, which is pointless for something we don't support. Tom