From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22191 invoked by alias); 21 Dec 2011 14:01:53 -0000 Received: (qmail 22146 invoked by uid 22791); 21 Dec 2011 14:01:51 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 21 Dec 2011 14:01:36 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 5239F2BB308; Wed, 21 Dec 2011 09:01:35 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id LaPfKWh6HQTf; Wed, 21 Dec 2011 09:01:35 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id C11692BB2AF; Wed, 21 Dec 2011 09:01:34 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id 4B15A145615; Wed, 21 Dec 2011 06:01:28 -0800 (PST) Date: Wed, 21 Dec 2011 14:08:00 -0000 From: Joel Brobecker To: Tom Tromey Cc: gdb-patches@sourceware.org Subject: Re: [RFC] allow unqualified function names in linespecs Message-ID: <20111221140128.GK23376@adacore.com> References: <1323872680-12843-1-git-send-email-brobecker@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2011-12/txt/msg00725.txt.bz2 > I don't think it is the very best thing for us to have Ada be so very > different from the rest of GDB in so many ways -- special debuginfo > encoded in symbol names, special rules for linespecs, special rules for > iterating symbol tables. I am sure it is better for Ada users, but the > problem is that if we want to make changes to core things in GDB, > eventually it requires you to step in and do a piece of the work. E.g., > we just punted on .gdb_index support for Ada. Yeah, I agree. It's a combination of things. I do recognize that part of the problem comes from us, having developed an Ada mode that was never designed to extend the overall design to satisfy Ada's needs. I wasn't there, but I think we were rushed, trying to transform a C debugger, with instructions on how to decode everything manually, to something that handled as much of Ada as possible. Part of the problem also comes from the fact that C++ and Ada are so different, and thus are also often used in very different projects. Trying to unify support for both without some kind of abstraction layer is very hard. In fact, coming up with that abstraction layer is also very hard, as we're finding out. My goal in the past 10 years, has always been to clean the Ada mode up, and all the messes we created. But at the same time, I dont' want that work to create more work for me during the periodic merges I make from the FSF tree to ours. So, my first goal is to first reconcile AdaCore's ada-* files with the ones on the FSF. That's a lot of micro-redesign, sometimes, to get things to an acceptable state. The good news is, I feel like I am getting really close. And once I'm done, I can start the cleanup in earnest. There are some thing that I need to accept though: If some things are common idioms in Ada, there is now way I am going to be able to stop supporting them without losing my job :-). Believe it or not, though, I do a fair amount of push back against some of the features that get requested internally. > [ ideas ] > Joel> . Redesign a bit the interface. For instance, let the language > Joel> itself iterate over all partial symbols? The default implementation > Joel> would do what we already do. The Ada implementation would do > Joel> something else, not sure what yet. And we could get rid of > Joel> the la_symbol_name_compare method. > > I suppose either this or having a way for the language to compute the > name-matching function. > > I am not so sure about an Ada-specific psymtab walker. I think I'd have > to see the patch or a fuller proposal. OK. I'll try to come up with something along either of those lines... -- Joel