From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29173 invoked by alias); 24 Nov 2011 10:56:52 -0000 Received: (qmail 29161 invoked by uid 22791); 24 Nov 2011 10:56:51 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from mel.act-europe.fr (HELO mel.act-europe.fr) (194.98.77.210) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 24 Nov 2011 10:56:33 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-smtp.eu.adacore.com (Postfix) with ESMTP id 7AD01CB02E3; Thu, 24 Nov 2011 11:56:33 +0100 (CET) Received: from mel.act-europe.fr ([127.0.0.1]) by localhost (smtp.eu.adacore.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dyKA4xQai6DW; Thu, 24 Nov 2011 11:56:23 +0100 (CET) Received: from province.act-europe.fr (province.act-europe.fr [10.10.0.214]) by mel.act-europe.fr (Postfix) with ESMTP id 0B20CCB02E5; Thu, 24 Nov 2011 11:56:05 +0100 (CET) Received: by province.act-europe.fr (Postfix, from userid 560) id 2139B164827; Thu, 24 Nov 2011 11:56:03 +0100 (CET) Date: Thu, 24 Nov 2011 10:56:00 -0000 From: Jerome Guitton To: Joel Brobecker Cc: Tom Tromey , gdb-patches@sourceware.org Subject: Re: GDB 7.4 branching status? (2011-11-23) Message-ID: <20111124105603.GA91879@adacore.com> References: <20111123163917.GA13809@adacore.com> <20111123232406.GQ13809@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111123232406.GQ13809@adacore.com> User-Agent: Mutt/1.5.17 (2007-11-01) 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-11/txt/msg00678.txt.bz2 Joel Brobecker (brobecker@adacore.com): > > First, I think having too many locations is better than having too few. > > With too many, at least the user can disable some. With too few, > > whoops, gdb isn't doing as asked. > > > > Second, at least initially the heuristic only has to perform as well as > > what gdb already does. > > I agree. > > Right now, we're stuck between a rock and a hard place. So it's > more of a matter of deciding which approach matches our goals > the most. If we go by the principles above, the simpler heuristic > seems the way to go. It introduces an apparent regression for Ada, > but I don't see a simple way around it that does not sacrifice > a little bit of the principles above. We're just going to have > to call it a limitation. Well, having a regression for Ada defeats the second principle, IMHO :) And I think that it is not Ada-specific at all actually; to reproduce the problem in C++, you just need to have a couple of templates/inlined functions in a header and have them instanciated in different source files. What about having the same heuristics as expand_line_sal used to have for this kind of issue? At least we would have the exact same behavior as before... You reported that this heuristic was the following: The approach they use is to select exact matches first. And then, if there are no exact matches, then select exact matches for the first line above the selected line. This heuristic is flawed as well, but the other that have been proposed so far have some issues themselves. So maybe we should just start with what we already have before trying to find a clever solution?