From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12199 invoked by alias); 2 Apr 2002 05:36:32 -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 12192 invoked from network); 2 Apr 2002 05:36:30 -0000 Received: from unknown (HELO duracef.shout.net) (204.253.184.12) by sources.redhat.com with SMTP; 2 Apr 2002 05:36:30 -0000 Received: (from mec@localhost) by duracef.shout.net (8.11.6/8.11.6) id g325aPi17954; Mon, 1 Apr 2002 23:36:25 -0600 Date: Mon, 01 Apr 2002 21:36:00 -0000 From: Michael Elizabeth Chastain Message-Id: <200204020536.g325aPi17954@duracef.shout.net> To: eliz@is.elta.co.il Subject: Re: [RFA] import drow dbxread.c fix to branch Cc: gdb-patches@sources.redhat.com X-SW-Source: 2002-04/txt/msg00015.txt.bz2 Eli Zaretskii writes: > In general, I think only safe fixes for grave bugs should go into the > branch. Well, yes. PR/379 and PR/380 are broken in places where 5.1 worked correctly. They are on Andrew Cagney's list of high priority bugs for 5.2 (along with PR/381 which has a similar cause but is not fixed yet). I believe this fix is safe because I ran before-and-after tests with: native i686-pc-linux-gnu%rh-7.2 gcc = 2.95.3, 2.96-rh, 3.0.4, gcc-3_1-branch, HEAD goption = -gdwarf-2, -goption That's ten combinations of gcc/goption. I also believe that this fix is safe because it's been on mainline for two full sunday test cycles without any regressions. > Can you please post a simple test program, and a procedure to test the > relevant feature before and after the patch? (I cannot run the test > suite on my system.) The exact configuration is in PR gdb/379: [target = native host = i686-pc-linux-gnu%rh-7.2 gdb = gdb_5_2-branch%20020222 gcc = 2.95.3 glibc = vendor goption = -gstabs+] The important bits are the "gcc 2.95.3" and "-gstabs+". If you use those you are likely to see the problem with a different target and host. All the gdb code involved is not in OS-specific parts of gdb so I believe that the problem is not OS-specific. We had one report from a freebsd system which looked similar. If you want to reproduce this without running the test suite: . use gcc 2.95.3 . copy gdb/testsuite/gdb.base/step-test.c into your local directory . compile with: gcc -gstabs+ -o step-test.exe step-test.c (yes I like .exe extensions even on Unix) . build a 5.2 branch gdb . gdb step-test.exe . break 56 . run . step . note how "step" steps over the function, not into it Here's a log from my system: bash-2.05$ /berman/fsf/OLD/2002-03-29/berman/native/install/gdb/gdb_5_2-branch/bin/gdb step-test.exe GNU gdb 5.1.90-2002-03-30-cvs Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu"... (gdb) break 56 Breakpoint 1 at 0x80484df: file step-test.c, line 56. (gdb) run Starting program: /berman/home/mec/tmp/step-test.exe Breakpoint 1, main () at step-test.c:56 56 large_struct_by_value (r); /* step-test.exp: large struct by value */ (gdb) step 59 exit (0); gdb's behavior for the "step" command is wrong. The correct behavior is to step into the function "large_struct_by_value (r)". Out of curiosity, how come you can't run the test suite? > If we still have problems for which such solutions are > impossible, but which are deemed too grave to not solve them in 5.2, it > would mean that the branch was cut too early, and we should consider > canceling the branch and starting the release cycle anew. That's always an option. My opinion at this time is that we are not at all close to needing a re-branch. Michael C