From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13614 invoked by alias); 2 Apr 2002 05:43:23 -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 13602 invoked from network); 2 Apr 2002 05:43:21 -0000 Received: from unknown (HELO is.elta.co.il) (199.203.121.2) by sources.redhat.com with SMTP; 2 Apr 2002 05:43:21 -0000 Received: from is (is [199.203.121.2]) by is.elta.co.il (8.9.3/8.8.8) with SMTP id IAA00124; Tue, 2 Apr 2002 08:42:02 +0200 (IST) Date: Mon, 01 Apr 2002 21:43:00 -0000 From: Eli Zaretskii X-Sender: eliz@is To: Michael Elizabeth Chastain cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] import drow dbxread.c fix to branch In-Reply-To: <200204020536.g325aPi17954@duracef.shout.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2002-04/txt/msg00016.txt.bz2 On Mon, 1 Apr 2002, Michael Elizabeth Chastain wrote: > 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. DJGPP supports stabs, so yes, I should be able to reproduce this. > gdb's behavior for the "step" command is wrong. The correct behavior > is to step into the function "large_struct_by_value (r)". Thanks, I will try that. > Out of curiosity, how come you can't run the test suite? It requires async subprocesses that DJGPP doesn't support. (And no, I cannot afford doing that in a cross-compilation environment, either.) > > 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. I wrote that because the number of changes that are retrofitted into the branch is disturbingly high (IMHO). Perhaps Andrew should have held us under the threat of the branch slightly longer. I alwaus thought that a branch is effectively feature-frozen. Perhaps I misunderstood the policy.