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

[Daniel Jacobowitz <drow at mvista dot com>]

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