Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Michael Elizabeth Chastain <mec@shout.net>
To: eliz@is.elta.co.il
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFA] import drow dbxread.c fix to branch
Date: Mon, 01 Apr 2002 21:36:00 -0000	[thread overview]
Message-ID: <200204020536.g325aPi17954@duracef.shout.net> (raw)

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


             reply	other threads:[~2002-04-02  5:36 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-04-01 21:36 Michael Elizabeth Chastain [this message]
2002-04-01 21:43 ` Eli Zaretskii
2002-04-03 19:43   ` Andrew Cagney
  -- strict thread matches above, loose matches on Subject: below --
2002-04-05 13:34 Michael Elizabeth Chastain
2002-04-04 18:17 Michael Elizabeth Chastain
2002-04-04 18:36 ` Daniel Jacobowitz
2002-04-04 19:35   ` Elena Zannoni
2002-04-05 13:10     ` Jim Blandy
2002-04-05 13:16       ` Daniel Jacobowitz
2002-04-04  8:37 Michael Elizabeth Chastain
2002-04-03 21:36 Michael Elizabeth Chastain
2002-04-03 22:01 ` Daniel Jacobowitz
2002-04-04 10:58   ` Andrew Cagney
2002-04-04 11:33   ` Elena Zannoni
2002-04-04 11:40     ` Daniel Jacobowitz
2002-04-04 12:15       ` Elena Zannoni
2002-04-04 12:24         ` Daniel Jacobowitz
2002-04-04 12:18       ` Andrew Cagney
2002-04-04 12:20         ` Daniel Berlin
2002-04-04 12:30           ` Andrew Cagney
2002-04-03 20:48 Michael Elizabeth Chastain
2002-04-03 21:09 ` Daniel Jacobowitz
2002-04-01 11:22 Michael Elizabeth Chastain
2002-04-01 20:49 ` Eli Zaretskii
2002-04-01  8:56 Michael Elizabeth Chastain

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200204020536.g325aPi17954@duracef.shout.net \
    --to=mec@shout.net \
    --cc=eliz@is.elta.co.il \
    --cc=gdb-patches@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox