From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11462 invoked by alias); 23 Nov 2011 23:24:28 -0000 Received: (qmail 11452 invoked by uid 22791); 23 Nov 2011 23:24:27 -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, 23 Nov 2011 23:24:12 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id EB5942BAFB9; Wed, 23 Nov 2011 18:24:11 -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 yVrj1Ax7QGXg; Wed, 23 Nov 2011 18:24:11 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id C19AB2BAF6C; Wed, 23 Nov 2011 18:24:11 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id D647F145615; Wed, 23 Nov 2011 18:24:06 -0500 (EST) Date: Wed, 23 Nov 2011 23:24:00 -0000 From: Joel Brobecker To: Tom Tromey Cc: gdb-patches@sourceware.org Subject: Re: GDB 7.4 branching status? (2011-11-23) Message-ID: <20111123232406.GQ13809@adacore.com> References: <20111123163917.GA13809@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-11/txt/msg00662.txt.bz2 Thanks, Tom, for sending out a summary (this started out as an informal discussion on IRC while asking Tom questions about what we were seeing when we tried the patch out). On second thoughts, I don't think the heuristics I proposed are going to work. It's easy to defeat by trying to insert a breakpoint inside a generic function (procedure Second is our Generic/Template function here): 7 procedure Second is 8 begin 9 Do_Nothing; 10 end Second; 11 12 procedure Third is 13 begin 14 Do_Nothing; 15 end Third; With that, AdaCore's GDB yields: (gdb) b pck.adb:9 [0] cancel [1] all [2] pck.third <<<<---------- This one is wrong [3] foo.good_second So, the idea of marking the lines below the first line of code as suspect doesn't work. All we need is to produce the issue is a "hole" in the linetable. Heuristic 4 (where exact matches in a given symtab, as determine by dirname + filename override inexact matches) isn't bad, and I think it would prevent us from seeing the problem with generics above. That's actually what we do today, except that we don't do the dirname + filename check, because we're only concerned with returning one single location. However, I think it would miss some location as I explained using my example with inlined functions. I think that it's a bit of a corner case, but still legitimate. On the other hand, the other heuristic that I like the most so far is the simplest one, which takes the first line we find, inexact and all. The downside is that we'll have too many matches. > A couple of observations. > > 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. -- Joel