From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29972 invoked by alias); 2 Sep 2003 03:28:35 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 29965 invoked from network); 2 Sep 2003 03:28:35 -0000 Received: from unknown (HELO concert.shout.net) (204.253.184.25) by sources.redhat.com with SMTP; 2 Sep 2003 03:28:35 -0000 Received: from duracef.shout.net (duracef.shout.net [204.253.184.12]) by concert.shout.net (8.12.9/8.12.9) with ESMTP id h823SXrY027150; Mon, 1 Sep 2003 22:28:33 -0500 Received: from duracef.shout.net (localhost [127.0.0.1]) by duracef.shout.net (8.12.9/8.12.9) with ESMTP id h823SXHK013674; Mon, 1 Sep 2003 22:28:33 -0500 Received: (from mec@localhost) by duracef.shout.net (8.12.9/8.12.9/Submit) id h823SW1F013673; Mon, 1 Sep 2003 23:28:32 -0400 Date: Tue, 02 Sep 2003 03:28:00 -0000 From: Michael Elizabeth Chastain Message-Id: <200309020328.h823SW1F013673@duracef.shout.net> To: drow@mvista.com, gdb@sources.redhat.com Subject: Re: gcc HEAD moves line number directives -- gcc bug? X-SW-Source: 2003-09/txt/msg00006.txt.bz2 drow> our testsuite certainly must accept returning to drow> both line 23 and 24. There are a number of architecures where a drow> function call includes instructions after the return (stack adjustment, drow> $gp reload...). I didn't think of that. You are right. This is a bug in the test script, independent of whether the compiler has a bug too. In fact, even on x86, a "call" instruction might or might not be followed by "add %esp, $N" to pop a arguments. We had a similar bug in gdb.base/advance.exp earlier this year. Mumble grep ... 2003-02-01 Michael Chastain * gdb.base/advance.c (marker1): New marker function. * gdb.base/advance.exp: When the 'advance' command lands on the return breakpoint, it can legitimately stop on either the current line or the next line. Accommodate both outcomes. * gdb.base/until.exp: Likewise. So I will submit a patch to fix gdb.mi/mi*-until.exp. > Line 24 is the addl. The leal is generated probably in reload; it's > not really part of any line, even though it was generated for line 24. Okay, then I won't file a gcc PR about the 'leal' insn moving up from line 24 to line 23. I'm still kinda wary and sensitive about it though. There are about a dozen gdb regressions from gcc 3.3.1 to gcc HEAD with -gdwarf-2, and a lot more with -gstabs+ due to gcc/12066. I'll keep grinding them. Thanks, Michael C