From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2179 invoked by alias); 5 Jan 2002 01:55:51 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 2125 invoked from network); 5 Jan 2002 01:55:48 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sources.redhat.com with SMTP; 5 Jan 2002 01:55:48 -0000 Received: from drow by nevyn.them.org with local (Exim 3.33 #1 (Debian)) id 16Mg4N-0001Kw-00; Fri, 04 Jan 2002 20:56:23 -0500 Date: Fri, 04 Jan 2002 17:55:00 -0000 From: Daniel Jacobowitz To: law@redhat.com Cc: gdb-patches@sources.redhat.com Subject: Re: Test for GCC debug symbol bug Message-ID: <20020104205623.A4968@nevyn.them.org> Mail-Followup-To: law@redhat.com, gdb-patches@sources.redhat.com References: <1754.1010182499@porcupine.cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1754.1010182499@porcupine.cygnus.com> User-Agent: Mutt/1.3.23i X-SW-Source: 2002-01/txt/msg00055.txt.bz2 On Fri, Jan 04, 2002 at 03:14:59PM -0700, law@redhat.com wrote: > > This patch adds a test for a GCC bug in its line number output. > > Basically if we have a multi-line IF or WHILE conditional, GCC will > emit incorrect line numbers for the IF/WHILE statement. > > The incorrect line numbers (of course) make debugging multi-line > IF/WHILE statements a PITA. > > To help ensure the GCC team doesn't break this again, I'd like to > add this relatively simple test to the GDB testsuite. > > > * gdb.base/break.c (multi_line_if_conditional): New function. > (multi_ilne_while_conditional): Likewise. > * gdb.base/break.exp: Verify that a breakpoint on a multi-line > IF or WHILE condition puts the breakpoint at the start of > the condition. This is obvious; please do commit it. I'm all in favor of debug info tests. Of course, we may want to mark it XFAIL if we end up stopping where broken GCC's would have; I really dislike FAILs that GDB can do nothing about, although in some cases they're unavoidable. Do we have a documented policy for what all the DejaGNU result codes mean in the GDB testsuite? If not, should I propose one? -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer