Re: [RFA] import drow dbxread.c fix to branch

Re: [RFA] import drow dbxread.c fix to branch

[Michael Elizabeth Chastain]

Jim Blandy writes:
> Perhaps this is bad attitude on my part, but I think we should go
> ahead with the changes (which we know are helpful), and wait until the
> older problem surfaces.

Sounds good to me.

DanielJ's patches have all been in areas unrelated to FredF's original
patch.  What's more, they are fixing more than FredF's patch broke.
So I'm happy with the path we are on.  I just want to nail all the
regressions in the 5.2 branch before it ships.

Michael C

Re: [RFA] import drow dbxread.c fix to branch

[Michael Elizabeth Chastain]

Maybe I am some e-mails behind here.  But: if "gcc sometimes emits
line directives with a linenumber of 0", we may have a conflict.
FredF's patch synthesizes entries with a line number of 0.

So far DanielJ's patches have been adhering to the new meaning
per FredF.

Michael C

  2002-02-21  Fred Fish  <fnf@redhat.com>

	  * dbxread.c (process_one_symbol): When finding an N_FUN symbol
	  that marks the end of the range of a function, enter a line number
	  entry that has a line number of zero and a PC offset that matches
	  the end of the function.  This starts a range of PC's for which no
	  line number information is known.
	  * symtab.c (find_pc_sect_line): If our best fit is in a range of
	  PC's for which no line number info is found (line number is zero)
	  then we didn't find any valid line information.
	  * symtab.h: Document use of zero line number entry.

Re: [RFA] import drow dbxread.c fix to branch

[Daniel Jacobowitz]

On Thu, Apr 04, 2002 at 08:17:51PM -0600, Michael Elizabeth Chastain wrote:
> Maybe I am some e-mails behind here.  But: if "gcc sometimes emits
> line directives with a linenumber of 0", we may have a conflict.
> FredF's patch synthesizes entries with a line number of 0.

Right now it doesn't; that referred to a copy of the GnuPro toolchain
that (I think) is dead.  The comment was a bit on the old side.

I might be wrong about its deadness, and it might come alive again some
day; Andrew would know better than I.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFA] import drow dbxread.c fix to branch

[Elena Zannoni]

Daniel Jacobowitz writes:
 > On Thu, Apr 04, 2002 at 08:17:51PM -0600, Michael Elizabeth Chastain wrote:
 > > Maybe I am some e-mails behind here.  But: if "gcc sometimes emits
 > > line directives with a linenumber of 0", we may have a conflict.
 > > FredF's patch synthesizes entries with a line number of 0.
 > 
 > Right now it doesn't; that referred to a copy of the GnuPro toolchain
 > that (I think) is dead.  The comment was a bit on the old side.
 > 

All I could find out from cvs about that code is that is was
introduced sometimes in 1999, before sourceware was started.

Elena

 > I might be wrong about its deadness, and it might come alive again some
 > day; Andrew would know better than I.
 > 
 > -- 
 > Daniel Jacobowitz                           Carnegie Mellon University
 > MontaVista Software                         Debian GNU/Linux Developer

Re: [RFA] import drow dbxread.c fix to branch

[Jim Blandy]

Elena Zannoni <ezannoni@redhat.com> writes:
> Daniel Jacobowitz writes:
>  > On Thu, Apr 04, 2002 at 08:17:51PM -0600, Michael Elizabeth Chastain wrote:
>  > > Maybe I am some e-mails behind here.  But: if "gcc sometimes emits
>  > > line directives with a linenumber of 0", we may have a conflict.
>  > > FredF's patch synthesizes entries with a line number of 0.
>  > 
>  > Right now it doesn't; that referred to a copy of the GnuPro toolchain
>  > that (I think) is dead.  The comment was a bit on the old side.
>  > 
> 
> All I could find out from cvs about that code is that is was
> introduced sometimes in 1999, before sourceware was started.

Perhaps this is bad attitude on my part, but I think we should go
ahead with the changes (which we know are helpful), and wait until the
older problem surfaces.

When it does, we can find another way to deal with it.  For example,
we could check for zeros in SLINE stabs, and fix them there, before
they ever make it into GDB's line table structure.

Re: [RFA] import drow dbxread.c fix to branch

[Daniel Jacobowitz]

On Fri, Apr 05, 2002 at 04:10:21PM -0500, Jim Blandy wrote:
> 
> Elena Zannoni <ezannoni@redhat.com> writes:
> > Daniel Jacobowitz writes:
> >  > On Thu, Apr 04, 2002 at 08:17:51PM -0600, Michael Elizabeth Chastain wrote:
> >  > > Maybe I am some e-mails behind here.  But: if "gcc sometimes emits
> >  > > line directives with a linenumber of 0", we may have a conflict.
> >  > > FredF's patch synthesizes entries with a line number of 0.
> >  > 
> >  > Right now it doesn't; that referred to a copy of the GnuPro toolchain
> >  > that (I think) is dead.  The comment was a bit on the old side.
> >  > 
> > 
> > All I could find out from cvs about that code is that is was
> > introduced sometimes in 1999, before sourceware was started.
> 
> Perhaps this is bad attitude on my part, but I think we should go
> ahead with the changes (which we know are helpful), and wait until the
> older problem surfaces.
> 
> When it does, we can find another way to deal with it.  For example,
> we could check for zeros in SLINE stabs, and fix them there, before
> they ever make it into GDB's line table structure.

I agree - and we have.  If the GCC extension in question resurfaces,
we'll deal with it then.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFA] import drow dbxread.c fix to branch

[Michael Elizabeth Chastain]

My test bed likes it: no regressions; fixes PR gdb/381 as advertised.

You do need to bump the copyright datei mi-cmd-disas.c.

I'll keep posting these testsuite/ tarballs when I file bug reports
based on test failures.

Michael C

2002-04-04  Daniel Jacobowitz  <drow@mvista.com>

	* mi-cmd-disas.c (mi_cmd_disassemble): Skip end-of-function
	markers in the line table.

Re: [RFA] import drow dbxread.c fix to branch

[Michael Elizabeth Chastain]

DanielJ writes:
> Only shows on GCC 3.1, eh?  I'll try to look at it later, but I have no
> post-3.0 toolchain installed right now.  Actually, I should
> investigate, to make sure it isn't a 3.1 regression...

On the next spin, I'll make a special report of regressions for gcc
3.0.4 versus gcc-3_1-branch.  You can already look at "difference by gcc"
in the regular report if you want to pick up a hot spot or two.

BTW my test harness now saves the whole test directory, including all
the executable files.  In fact I'll just throw some tarball up in my
ftp directory in case it might help someone:

  ftp://ftp.shout.net/pub/users/mec/gdb/for-pr-gdb-381.tar.gz
  ftp://ftp.shout.net/pub/users/mec/gdb/for-pr-gdb-381-src.tar.gz

Michael C

Re: [RFA] import drow dbxread.c fix to branch

[Daniel Jacobowitz]

On Wed, Apr 03, 2002 at 11:36:06PM -0600, Michael Elizabeth Chastain wrote:
> DanielJ writes:
> > Only shows on GCC 3.1, eh?  I'll try to look at it later, but I have no
> > post-3.0 toolchain installed right now.  Actually, I should
> > investigate, to make sure it isn't a 3.1 regression...
> 
> On the next spin, I'll make a special report of regressions for gcc
> 3.0.4 versus gcc-3_1-branch.  You can already look at "difference by gcc"
> in the regular report if you want to pick up a hot spot or two.
> 
> BTW my test harness now saves the whole test directory, including all
> the executable files.  In fact I'll just throw some tarball up in my
> ftp directory in case it might help someone:
> 
>   ftp://ftp.shout.net/pub/users/mec/gdb/for-pr-gdb-381.tar.gz
>   ftp://ftp.shout.net/pub/users/mec/gdb/for-pr-gdb-381-src.tar.gz

Thanks.  It does help - that was pretty easy, actually :).  I've found
the bug; mi-cmd-disassemble does not recognize '0' line numbers, and it
needs to.  I don't know why only 3.1 triggers this.  Probably a
function padding thing; the end of the previous function seems to share
a PC with the beginning of the one being listed.  Here's a patch;
Andrew, how's this look?

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

2002-04-04  Daniel Jacobowitz  <drow@mvista.com>

	* mi-cmd-disas.c (mi_cmd_disassemble): Skip end-of-function
	markers in the line table.

Index: mi/mi-cmd-disas.c
===================================================================
RCS file: /cvs/src/src/gdb/mi/mi-cmd-disas.c,v
retrieving revision 1.12
diff -u -p -r1.12 mi-cmd-disas.c
--- mi-cmd-disas.c	2002/01/05 04:30:46	1.12
+++ mi-cmd-disas.c	2002/04/04 05:59:51
@@ -332,6 +332,10 @@ mi_cmd_disassemble (char *command, char 
 	      && le[i].pc == le[i + 1].pc)
 	    continue;		/* Ignore duplicates */
 
+	  /* Skip any end-of-function markers.  */
+	  if (le[i].line == 0)
+	    continue;
+
 	  mle[newlines].line = le[i].line;
 	  if (le[i].line > le[i + 1].line)
 	    out_of_order = 1;

Re: [RFA] import drow dbxread.c fix to branch

[Andrew Cagney]

> On Wed, Apr 03, 2002 at 11:36:06PM -0600, Michael Elizabeth Chastain wrote:
> 
>> DanielJ writes:
> 
>> > Only shows on GCC 3.1, eh?  I'll try to look at it later, but I have no
>> > post-3.0 toolchain installed right now.  Actually, I should
>> > investigate, to make sure it isn't a 3.1 regression...
> 
>> 
>> On the next spin, I'll make a special report of regressions for gcc
>> 3.0.4 versus gcc-3_1-branch.  You can already look at "difference by gcc"
>> in the regular report if you want to pick up a hot spot or two.
>> 
>> BTW my test harness now saves the whole test directory, including all
>> the executable files.  In fact I'll just throw some tarball up in my
>> ftp directory in case it might help someone:
>> 
>> ftp://ftp.shout.net/pub/users/mec/gdb/for-pr-gdb-381.tar.gz
>> ftp://ftp.shout.net/pub/users/mec/gdb/for-pr-gdb-381-src.tar.gz
> 
> 
> Thanks.  It does help - that was pretty easy, actually :).  I've found
> the bug; mi-cmd-disassemble does not recognize '0' line numbers, and it
> needs to.  I don't know why only 3.1 triggers this.  Probably a
> function padding thing; the end of the previous function seems to share
> a PC with the beginning of the one being listed.  Here's a patch;
> Andrew, how's this look?

For this command, I'm the wrong person to ask.  Elena?

Andrew

Re: [RFA] import drow dbxread.c fix to branch

[Elena Zannoni]

Daniel Jacobowitz writes:
 > On Wed, Apr 03, 2002 at 11:36:06PM -0600, Michael Elizabeth Chastain wrote:
 > > DanielJ writes:
 > > > Only shows on GCC 3.1, eh?  I'll try to look at it later, but I have no
 > > > post-3.0 toolchain installed right now.  Actually, I should
 > > > investigate, to make sure it isn't a 3.1 regression...
 > > 
 > > On the next spin, I'll make a special report of regressions for gcc
 > > 3.0.4 versus gcc-3_1-branch.  You can already look at "difference by gcc"
 > > in the regular report if you want to pick up a hot spot or two.
 > > 
 > > BTW my test harness now saves the whole test directory, including all
 > > the executable files.  In fact I'll just throw some tarball up in my
 > > ftp directory in case it might help someone:
 > > 
 > >   ftp://ftp.shout.net/pub/users/mec/gdb/for-pr-gdb-381.tar.gz
 > >   ftp://ftp.shout.net/pub/users/mec/gdb/for-pr-gdb-381-src.tar.gz
 > 
 > Thanks.  It does help - that was pretty easy, actually :).  I've found
 > the bug; mi-cmd-disassemble does not recognize '0' line numbers, and it
 > needs to.  I don't know why only 3.1 triggers this.  Probably a
 > function padding thing; the end of the previous function seems to share
 > a PC with the beginning of the one being listed.  Here's a patch;
 > Andrew, how's this look?
 > 

Take a look at the way gdbtk does it, in
gdbtk/generic/gdbtk-cmd.c:gdb_disassemble_driver().
Can we adopt that solution?

(I really can't wait until we can get rid of this duplication/triplication of
disassembly code. I think I'll start cleaning some things up).

Elena

 > -- 
 > Daniel Jacobowitz                           Carnegie Mellon University
 > MontaVista Software                         Debian GNU/Linux Developer
 > 
 > 2002-04-04  Daniel Jacobowitz  <drow@mvista.com>
 > 
 > 	* mi-cmd-disas.c (mi_cmd_disassemble): Skip end-of-function
 > 	markers in the line table.
 > 
 > Index: mi/mi-cmd-disas.c
 > ===================================================================
 > RCS file: /cvs/src/src/gdb/mi/mi-cmd-disas.c,v
 > retrieving revision 1.12
 > diff -u -p -r1.12 mi-cmd-disas.c
 > --- mi-cmd-disas.c	2002/01/05 04:30:46	1.12
 > +++ mi-cmd-disas.c	2002/04/04 05:59:51
 > @@ -332,6 +332,10 @@ mi_cmd_disassemble (char *command, char 
 >  	      && le[i].pc == le[i + 1].pc)
 >  	    continue;		/* Ignore duplicates */
 >  
 > +	  /* Skip any end-of-function markers.  */
 > +	  if (le[i].line == 0)
 > +	    continue;
 > +
 >  	  mle[newlines].line = le[i].line;
 >  	  if (le[i].line > le[i + 1].line)
 >  	    out_of_order = 1;

Re: [RFA] import drow dbxread.c fix to branch

[Daniel Jacobowitz]

On Thu, Apr 04, 2002 at 02:27:05PM -0500, Elena Zannoni wrote:
> Daniel Jacobowitz writes:
>  > On Wed, Apr 03, 2002 at 11:36:06PM -0600, Michael Elizabeth Chastain wrote:
>  > > DanielJ writes:
>  > > > Only shows on GCC 3.1, eh?  I'll try to look at it later, but I have no
>  > > > post-3.0 toolchain installed right now.  Actually, I should
>  > > > investigate, to make sure it isn't a 3.1 regression...
>  > > 
>  > > On the next spin, I'll make a special report of regressions for gcc
>  > > 3.0.4 versus gcc-3_1-branch.  You can already look at "difference by gcc"
>  > > in the regular report if you want to pick up a hot spot or two.
>  > > 
>  > > BTW my test harness now saves the whole test directory, including all
>  > > the executable files.  In fact I'll just throw some tarball up in my
>  > > ftp directory in case it might help someone:
>  > > 
>  > >   ftp://ftp.shout.net/pub/users/mec/gdb/for-pr-gdb-381.tar.gz
>  > >   ftp://ftp.shout.net/pub/users/mec/gdb/for-pr-gdb-381-src.tar.gz
>  > 
>  > Thanks.  It does help - that was pretty easy, actually :).  I've found
>  > the bug; mi-cmd-disassemble does not recognize '0' line numbers, and it
>  > needs to.  I don't know why only 3.1 triggers this.  Probably a
>  > function padding thing; the end of the previous function seems to share
>  > a PC with the beginning of the one being listed.  Here's a patch;
>  > Andrew, how's this look?
>  > 
> 
> Take a look at the way gdbtk does it, in
> gdbtk/generic/gdbtk-cmd.c:gdb_disassemble_driver().
> Can we adopt that solution?
> 
> (I really can't wait until we can get rid of this duplication/triplication of
> disassembly code. I think I'll start cleaning some things up).

I'm not sure.  That code assumes a different meaning of line==0 than
the one we're using.  Particularly, if I understand correctly, the
meaning in gdbtk comes from a set of Cygnus-internal stabs for handling
live range splitting, which never made it into any public GCC and are
completely obsoleted by DWARF-2.  I prefer:

 > +      /* Skip any end-of-function markers.  */
 > +      if (le[i].line == 0)
 > +        continue;
 > +


to:

          /* GCC sometimes emits line directives with a linenumber
             of 0.  It does this to handle live range splitting.
             This may be a bug, but we need to be able to handle it.
             For now, use the previous instructions line number.
             Since this is a bit of a hack anyway, we will just lose
             if the bogus sline is the first line of the range.  For
             functions, I have never seen this to be the case.  */
          
          if (le[i].line != 0)
            {
              mle[newlines].line = le[i].line;
            }
          else
            {
              if (newlines > 0)
                mle[newlines].line = mle[newlines - 1].line;
            }


i.e. skip the line, not fake up a line number for it.  It's a
special-purpose marker, not a generic line number.

If you agree with me, want me to update gdbtk's version to match?  Does
this same code exist in a third location?

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFA] import drow dbxread.c fix to branch

[Elena Zannoni]

Daniel Jacobowitz writes:
 > > 
 > > Take a look at the way gdbtk does it, in
 > > gdbtk/generic/gdbtk-cmd.c:gdb_disassemble_driver().
 > > Can we adopt that solution?
 > > 
 > > (I really can't wait until we can get rid of this duplication/triplication of
 > > disassembly code. I think I'll start cleaning some things up).
 > 
 > I'm not sure.  That code assumes a different meaning of line==0 than
 > the one we're using.  Particularly, if I understand correctly, the
 > meaning in gdbtk comes from a set of Cygnus-internal stabs for handling
 > live range splitting, which never made it into any public GCC and are
 > completely obsoleted by DWARF-2.  I prefer:
 > 

Yes, you are right, that code predates even gdbtk bein contributed
publically. I initially thought that it was a recent fix.


 >  > +      /* Skip any end-of-function markers.  */
 >  > +      if (le[i].line == 0)
 >  > +        continue;
 >  > +
 > 
 > 
 > to:
 > 
 >           /* GCC sometimes emits line directives with a linenumber
 >              of 0.  It does this to handle live range splitting.
 >              This may be a bug, but we need to be able to handle it.
 >              For now, use the previous instructions line number.
 >              Since this is a bit of a hack anyway, we will just lose
 >              if the bogus sline is the first line of the range.  For
 >              functions, I have never seen this to be the case.  */
 >           
 >           if (le[i].line != 0)
 >             {
 >               mle[newlines].line = le[i].line;
 >             }
 >           else
 >             {
 >               if (newlines > 0)
 >                 mle[newlines].line = mle[newlines - 1].line;
 >             }
 > 
 > 
 > i.e. skip the line, not fake up a line number for it.  It's a
 > special-purpose marker, not a generic line number.
 > 
 > If you agree with me, want me to update gdbtk's version to match?  Does
 > this same code exist in a third location?
 > 

I guess posting a patch to the insight list can do no harm. It's up to
them to approve it.

There is no real third location, but rather a third way to do
disassembly in gdb proper (disassemble_cmd).

Anyway, the code can go in for the MI part.

Elena


 > -- 
 > Daniel Jacobowitz                           Carnegie Mellon University
 > MontaVista Software                         Debian GNU/Linux Developer

Re: [RFA] import drow dbxread.c fix to branch

[Daniel Jacobowitz]

On Thu, Apr 04, 2002 at 03:09:28PM -0500, Elena Zannoni wrote:
> I guess posting a patch to the insight list can do no harm. It's up to
> them to approve it.

I'll do that.

> There is no real third location, but rather a third way to do
> disassembly in gdb proper (disassemble_cmd).

Which doesn't try to do mixed source/asm display, so it's not affected.

> Anyway, the code can go in for the MI part.

Thanks, it's in.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFA] import drow dbxread.c fix to branch

[Andrew Cagney]

> I'm not sure.  That code assumes a different meaning of line==0 than
> the one we're using.  Particularly, if I understand correctly, the
> meaning in gdbtk comes from a set of Cygnus-internal stabs for handling
> live range splitting, which never made it into any public GCC ...

``Would not be accepted into FSF's official GCC sources?''.  I'm trying 
to find out what the status actually is.

Andrew

Re: [RFA] import drow dbxread.c fix to branch

[Daniel Berlin]

On Thu, 4 Apr 2002, Andrew Cagney wrote:

> > I'm not sure.  That code assumes a different meaning of line==0 than
> > the one we're using.  Particularly, if I understand correctly, the
> > meaning in gdbtk comes from a set of Cygnus-internal stabs for handling
> > live range splitting, which never made it into any public GCC ...
> 
> ``Would not be accepted into FSF's official GCC sources?''.  I'm trying 
> to find out what the status actually is.

Is that a question (IE are you querying whether it would be accepted, and 
what the status in the official gcc is?)
If so, I can answer it.
> 
> Andrew
> 

Re: [RFA] import drow dbxread.c fix to branch

[Andrew Cagney]

> On Thu, 4 Apr 2002, Andrew Cagney wrote:
> 
> 
>> > I'm not sure.  That code assumes a different meaning of line==0 than
>> > the one we're using.  Particularly, if I understand correctly, the
>> > meaning in gdbtk comes from a set of Cygnus-internal stabs for handling
>> > live range splitting, which never made it into any public GCC ...
> 
>> 
>> ``Would not be accepted into FSF's official GCC sources?''.  I'm trying 
>> to find out what the status actually is.
> 
> 
> Is that a question (IE are you querying whether it would be accepted, and 
> what the status in the official gcc is?)

No.

> If so, I can answer it.

Andrew

Re: [RFA] import drow dbxread.c fix to branch

[Michael Elizabeth Chastain]

Welcome back, Andrew!

Andrew Cagney writes:
> Fortunatly (for JimB), DanielJ found a fix for the problem and that has 
> slowly been working its way into the branch.

Here is the current status from my perspective:

. DanielJ's fix is great for PR gdb/379 and PR gdb/380.  It has been in
  mainline for a couple of test cycles with no regressions.  It's one of the
  steps DanielJ took to reach his fabulous "NO FAIL" tree.

. I grabbed the patch and tested it on the 5.2 branch.  It tests great
  over there.

. I'm waiting for approval to commit to the branch.  Then I can spin more
  test results and produce another detailed "5.1.1 versus gdb_5_2-branch"
  report.

. This fix does not fix PR gdb/381.  gdb/381 is still happening in mainline.
  I'm secretly hoping that DanielJ will take an interest in it.

. I am ambivalent about whether gdb/381 is a showstopper.  On one hand:
  any regression is bad and should be nailed down before a release.
  On the other hand: gdb/381 happens only in gcc-3_1-branch and
  gcc HEAD, which are not released.  "Ambivalence" also translates to:
  I'll be comfortable with whatever Andrew decides.

Michael C

Re: [RFA] import drow dbxread.c fix to branch

[Daniel Jacobowitz]

On Wed, Apr 03, 2002 at 10:48:09PM -0600, Michael Elizabeth Chastain wrote:
> . This fix does not fix PR gdb/381.  gdb/381 is still happening in mainline.
>   I'm secretly hoping that DanielJ will take an interest in it.

Didn't know it was there :)

> . I am ambivalent about whether gdb/381 is a showstopper.  On one hand:
>   any regression is bad and should be nailed down before a release.
>   On the other hand: gdb/381 happens only in gcc-3_1-branch and
>   gcc HEAD, which are not released.  "Ambivalence" also translates to:
>   I'll be comfortable with whatever Andrew decides.

Only shows on GCC 3.1, eh?  I'll try to look at it later, but I have no
post-3.0 toolchain installed right now.  Actually, I should
investigate, to make sure it isn't a 3.1 regression...

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFA] import drow dbxread.c fix to branch

[Michael Elizabeth Chastain]

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

Re: [RFA] import drow dbxread.c fix to branch

[Eli Zaretskii]

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.

Re: [RFA] import drow dbxread.c fix to branch

[Andrew Cagney]

>> > 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.

I've known about this one for a month or so - ever since JimB approved 
FredF's symtab change and MichaelC promptly flaged the regressions it 
caused.

As far as I know, my options were:

- delay the branch until it the regressions were fixed (an unknown time 
frame)

- branch but threaten to pull the patch unless JimB (who approved it) 
fixed the problem

- branch and ship with the regression (not an option)

I went with the second option.

Fortunatly (for JimB), DanielJ found a fix for the problem and that has 
slowly been working its way into the branch.

>> 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.

This one is a regression :-(

Andrew

Re: [RFA] import drow dbxread.c fix to branch

[Michael Elizabeth Chastain]

Followup:

My test bed loves it for 5.2 (linux native).  It improves gcc 2.95.3
-gstabs+ and has no change with any other gcc/goption combination.

Okay to import into 5.2?

(I'm basically gonna focus on 5.1.1 -> 5.2 regressions for a while,
and this is one of them).

Michael C

  2002-03-21  Daniel Jacobowitz  <drow@mvista.com>
  * dbxread.c (process_one_symbol): Extend the first N_SLINE
  in a function to cover the entire beginning of the function
  as well if it does not already.

Re: [RFA] import drow dbxread.c fix to branch

[Eli Zaretskii]

On Mon, 1 Apr 2002, Michael Elizabeth Chastain wrote:

> My test bed loves it for 5.2 (linux native).  It improves gcc 2.95.3
> -gstabs+ and has no change with any other gcc/goption combination.
> 
> Okay to import into 5.2?

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.)

In general, I think only safe fixes for grave bugs should go into the 
branch.  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.

[RFA] import drow dbxread.c fix to branch

[Michael Elizabeth Chastain]

I would like to import this bug fix to the 5.2 branch:

  http://sources.redhat.com/ml/gdb-cvs/2002-03/msg00149.html

  2002-03-21  Daniel Jacobowitz  <drow@mvista.com>
  * dbxread.c (process_one_symbol): Extend the first N_SLINE
  in a function to cover the entire beginning of the function
  as well if it does not already.

This ought to fix a major regression with gcc 2.95.3 -gstabs+, as reported
in PR gdb/379 and PR gdb/380.

I'm about to run a test of this in my Linux test bed.  Assuming that
it works and doesn't regress anything else, is it okay to import this
patch to the 5.2 branch?

Michael C