From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11345 invoked by alias); 31 Jan 2008 18:45:27 -0000 Received: (qmail 11323 invoked by uid 22791); 31 Jan 2008 18:45:23 -0000 X-Spam-Check-By: sourceware.org Received: from fk-out-0910.google.com (HELO fk-out-0910.google.com) (209.85.128.185) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 31 Jan 2008 18:44:49 +0000 Received: by fk-out-0910.google.com with SMTP id 26so800346fkx.8 for ; Thu, 31 Jan 2008 10:44:46 -0800 (PST) Received: by 10.82.150.20 with SMTP id x20mr4449070bud.5.1201805085819; Thu, 31 Jan 2008 10:44:45 -0800 (PST) Received: from ?192.168.0.101? ( [85.240.251.38]) by mx.google.com with ESMTPS id g9sm12697609gvc.4.2008.01.31.10.44.43 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 31 Jan 2008 10:44:43 -0800 (PST) Message-ID: <47A2171C.6080209@portugalmail.pt> Date: Thu, 31 Jan 2008 19:53:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pt-BR; rv:1.8.1.9) Gecko/20071031 Thunderbird/2.0.0.9 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Joel Brobecker CC: Pierre Muller , gdb-patches@sourceware.org Subject: Re: Our next GDB release (GDB version 6.8) References: <20080126005319.GD21874@adacore.com> <000501c8619c$5261e940$f725bbc0$@u-strasbg.fr> <20080130180336.GD11271@adacore.com> <000901c863de$9fe9fa60$dfbdef20$@u-strasbg.fr> <20080131172435.GH12387@adacore.com> In-Reply-To: <20080131172435.GH12387@adacore.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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: 2008-01/txt/msg00863.txt.bz2 Joel Brobecker wrote: > In my opinion, this is not a critical issue. IIUC, this is not a regression, > and the only issue is that, for the "main", the breakpoint will be placed > at a location such that the debugger will stop at the open curly brace. > So the user will need an extra "next". > That and the fact that global c++ ctors will only run after "next". That's what's most different, and surprising. > I did notice that the fix gets rid of a lot of FAILs though. > This happens, because a lot of tests fail because runto_main or similar fails. > If it was just me, I would categorize this as non release-critical. > But the rest of the group might disagree, so I'll defer to them. > I agree. I'd like this to go in, of course, but there's no rush from me. -- Pedro Alves