From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23481 invoked by alias); 24 Nov 2011 16:33:27 -0000 Received: (qmail 23470 invoked by uid 22791); 24 Nov 2011 16:33:26 -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; Thu, 24 Nov 2011 16:33:11 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 3F63C2BABB7; Thu, 24 Nov 2011 11:33: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 IW+1zrsTVBC8; Thu, 24 Nov 2011 11:33:11 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 6621E2BABA7; Thu, 24 Nov 2011 11:33:10 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id C7D97145615; Thu, 24 Nov 2011 11:33:04 -0500 (EST) Date: Thu, 24 Nov 2011 16:33:00 -0000 From: Joel Brobecker To: Jerome Guitton Cc: Tom Tromey , gdb-patches@sourceware.org Subject: Re: GDB 7.4 branching status? (2011-11-23) Message-ID: <20111124163304.GR13809@adacore.com> References: <20111123163917.GA13809@adacore.com> <20111123232406.GQ13809@adacore.com> <20111124105603.GA91879@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111124105603.GA91879@adacore.com> 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/msg00684.txt.bz2 > Well, having a regression for Ada defeats the second principle, IMHO :) Yes, but right now, we cannot seem to satisfy all of our principles, so it is a matter of deciding what's best for this iteration. > 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... We proposed that as well, and I am fine with that approach too. But we have to bear in mind that we will be missing some location in some (corner only?) cases. So, for now, either approach is fine with me, maybe with a slight preference for possibly accepting more locations in order to avoid missing some. So prefer keeping the previous the previous heuristic, which I think makes sense as well - no surprise in a way. What do others think? -- Joel