Re: [patch] Fix to processing end of function stab in dbxread.c

[Jim Ingham <jingham at apple dot com>]

Daniel,

We are talking about two different things here - I am talking about  
converting the value in the blank FUN stab that marks the end of a  
function to a read address, NOT correcting an SLINE stab.  That may  
seem confusing given that I was talking about linetables, so I will  
give my previous explanation in a little more detail.

What is happening is that Fred was trying to work around the problem  
that SLINE's only give the start of the region of code assigned to that  
source line.  You rely on the next SLINE to get the end.  However, you  
can't always rely on the last line in a function to be properly  
terminated by a reasonable SLINE stab.  For instance MacOS X's linker  
will coalesce all the out-of-line copies of an inlined function, or of  
lots of the compiler generated C++ goop, and shove them in a separate  
segment at the end of the text section.  When it does that it updates  
all the various debug output.  So we end up with something like  
(StrLength here was an inlined function):

0001abcc - 01 0099 SLINE
0001abf0 - 01 009c SLINE
0001abfc - 01 009d SLINE
0001ac08 - 01 009f SLINE
0001ac20 - 01 00a0 SLINE
0001ac30 - 01 00a2 SLINE
0001ac5c - 01 00a3 SLINE
0001ac88 - 01 00a4 SLINE
0001abcc - 01 0099   FUN _Z14GetPictureSizesPlS_:f(1,1)
00000078 - 00 0099  PSYM resID:p(1,145)
0000007c - 00 0099  PSYM height:p(1,260)=*(1,81)
00000080 - 00 0099  PSYM width:p(1,260)
00000040 - 00 009a  LSYM picture:(1,171)
0001abf0 - 01 0000 LBRAC
0001ac88 - 01 0000 RBRAC
000000d0 - 00 0000   FUN
00031fd4 - 0c 0000   SOL  
/System/Library/Frameworks/CoreServices.framework/Headers/../ 
Frameworks/CarbonCore.framework/Headers/MacTypes.h
00031fd4 - 0c 019c SLINE
00031fe4 - 0c 019c SLINE
00031fd4 - 0c 019c   FUN StrLength:F(1,73)
00000048 - 00 019c  PSYM string:p(1,261)=(1,262)=*(1,263)=k(1,73)
00000000 - 00 0194  LSYM ConstStr255Param:t(1,261)
0000002c - 00 0000   FUN

Now line 0xa4 is going to stretch from 0001ac88 to 00031fd4.  Bad, bad,  
bad...

Fred's fix was to emit a fake linetable entry - with linenumber 0, when  
he sees the end of function stab.  That way, in the linetable there is  
just a region with no associated linenumbers from the end of the  
function to 00031fd4.  The problem was getting "the end of the  
function" from the data in the null FUN stab.  The value of the stab is  
the offset from the beginning of the function.  He was adding that to  
function_start_offset which according to the comment in the file is NOT  
the address of the last function on any system but Solaris.  It is the  
offset to the text section on other platforms, (which is clever,  
because then it is the correct thing to use to relocate the addresses  
in the SLINE entries on all platforms).  But it is not an appropriate  
thing to add to the offset from the end function stab.

Note also that in the one other place where we get the real address  
from the end fun stab (dbxread.c around 1726), we do:

          /* See if this is an end of function stab.  */
          if (pst && nlist.n_type == N_FUN && *namestring == '\000')
          {
            CORE_ADDR valu;

            /* It's value is the size (in bytes) of the function for
               function relative stabs, or the address of the function's
               end for old style stabs.  */
            valu = nlist.n_value + last_function_start;
            if (TEXTHIGH (pst) == 0 || valu > TEXTHIGH (pst))
              TEXTHIGH (pst) = valu;
            break;
          }

again using last_function_start, not function_start_offset.

Jim

On Wednesday, July 10, 2002, at 08:46  PM, Daniel Jacobowitz wrote:

> On Wed, Jul 10, 2002 at 07:08:16PM -0700, Jim Ingham wrote:
> > Index: dbxread.c
> > ===================================================================
> > RCS file: /cvs/src/src/gdb/dbxread.c,v
> > retrieving revision 1.33
> > diff -c -w -r1.33 dbxread.c
> > *** dbxread.c   10 May 2002 07:32:50 -0000      1.33
> > --- dbxread.c   11 Jul 2002 01:58:29 -0000
> > ***************
> > Hi, all...
> >
> > Fred added an extra record_line call which closes off the last SLINE  
> > in
> > a function when we come across the end of function N_FUN stab.  This
> > was a good thing, but unfortunately, he used function_start_offset,
> > which on most systems is just the offset to the TEXT section (the
> > exception being Solaris, where is actually is the real function  
> > start).
> >  He really meant to use last_function_start, which is the real address
> > of the last N_FUN stab seen.
> >
> > I also fixed the comment before sline_found_in_function to accord with
> > its current usage, since the old comment is wrong.  We set
> > sline_found_in_function = 0 at the same time we set
> > last_function_start, but then we set it to 1 when we see the FIRST
> > SLINE in a function, but last_function_start is still good after that.
> > And nobody ever checks it to see if they should use  
> > last_function_start
> > or not...
> Well, the archeology is hardly correct.  I added both
> last_function_start and sline_found_in_function recently;
> last_function_start was because I couldn't convince myself that I could
> trust the other.  Note that in the normal N_SLINE handling, we use
> function_start_offset and not last_function_start.  So if your change
> was really correct then all the N_SLINEs for your function would be in
> the wrong places too.
>
> Could you please explain what problem you're trying to fix, and support
> it with some stabs dumps?
>
> > *** 2761,2768 ****
> >     static CORE_ADDR last_function_start;
> >
> >     /* If this is nonzero, we've seen an N_SLINE since the start of  
> > the
> > current
> > !      function.  Initialized to nonzero to assure that
> > last_function_start
> > !      is never used uninitialized.  */
> >     static int sline_found_in_function = 1;
> >
> >     /* If this is nonzero, we've seen a non-gcc N_OPT symbol for this
> > source
> > --- 2761,2768 ----
> >     static CORE_ADDR last_function_start;
> >
> >     /* If this is nonzero, we've seen an N_SLINE since the start of  
> > the
> > current
> > !      function.  We use this to tell us to move the first sline to  
> > the
> > beginning
> > !      of the function regardless of what its given value is. */
> >     static int sline_found_in_function = 1;
> >
> >     /* If this is nonzero, we've seen a non-gcc N_OPT symbol for this
> > source
> > ***************
> > *** 2799,2805 ****
> >         {
> >           /* This N_FUN marks the end of a function.  This closes off
> > the
> >              current block.  */
> > !         record_line (current_subfile, 0, function_start_offset +
> > valu);
> >           within_function = 0;
> >           new = pop_context ();
> >
> > --- 2799,2805 ----
> >         {
> >           /* This N_FUN marks the end of a function.  This closes off
> > the
> >              current block.  */
> > !         record_line (current_subfile, 0, last_function_start +  
> > valu);
> >           within_function = 0;
> >           new = pop_context ();
> >
> > Jim
> > --
> > Jim Ingham                                   jingham@apple.com
> > Developer Tools - gdb
> > Apple Computer
> --
> Daniel Jacobowitz                           Carnegie Mellon University
> MontaVista Software                         Debian GNU/Linux Developer
--
Jim Ingham                                   jingham@apple.com
Developer Tools - gdb
Apple Computer