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

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

[Jim Ingham]

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

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

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

[Daniel Jacobowitz]

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

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

[Jim Ingham]

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

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

[Daniel Jacobowitz]

On Thu, Jul 11, 2002 at 11:10:28AM -0700, Jim Ingham wrote:
> 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.

Thanks for the excellent explanation.

<snip explanation of the original SLINE problem, which I understand>

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

You've switched functions.  That code is in read_dbx_symtab.  There was
no variable in process_one_symbol by that name until quite recently. 
They do have the same meaning however.  That's what I meant about your
archeology being wrong.  The comment that function_start_offset is
only correct for Solaris is also wrong; I can verify that it is correct
on GNU/Linux.  That's not your fault, though, the comments in dbxread.c
range from mediocre to misleading.  What comments referencing Solaris 2
(rather than referencing something about Sun's lame tools) often
mean is "on SVR4-ish systems".

I judge from your example that MacOSX has resolved addresses attached
to N_SLINE stabs, but not in ending N_FUN stabs?  GDB assumes that
function_start_offset applies to both of them equally (and it will be
zero if we expect both to be resolved).  On GNU/Linux both N_SLINE and
final N_FUN have offsets within the function.  I suspect that on some
Solaris variant N_SLINE and final N_FUN will both have resolved values.
In that case using last_function_start + valu will put us well outside
of the actual function, causing mayhem.

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

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

[Jim Ingham]

Daniel,

On Thursday, July 11, 2002, at 11:42  AM, Daniel Jacobowitz wrote:

>
> You've switched functions.  That code is in read_dbx_symtab.  There was
> no variable in process_one_symbol by that name until quite recently.
> They do have the same meaning however.  That's what I meant about your
> archeology being wrong.  The comment that function_start_offset is
> only correct for Solaris is also wrong; I can verify that it is correct
> on GNU/Linux.  That's not your fault, though, the comments in dbxread.c
> range from mediocre to misleading.  What comments referencing Solaris 2
> (rather than referencing something about Sun's lame tools) often
> mean is "on SVR4-ish systems".
>

Okay...

> I judge from your example that MacOSX has resolved addresses attached
> to N_SLINE stabs, but not in ending N_FUN stabs?  GDB assumes that
> function_start_offset applies to both of them equally (and it will be
> zero if we expect both to be resolved).  On GNU/Linux both N_SLINE and
> final N_FUN have offsets within the function.  I suspect that on some
> Solaris variant N_SLINE and final N_FUN will both have resolved values.
> In that case using last_function_start + valu will put us well outside
> of the actual function, causing mayhem.

That's right.  MacOS X's linker does fix up the SLINE stabs, but it 
does what stabs.texi says to do with the end of function stabs.

It would suprise me if there were a Solaris compile/linker that does 
otherwise with the end of FUN stab.  After all, it seems like the 
Solaris tools go out of their way to avoid having STABS that the linker 
has to fix up.  Also, the comment in stabs.texi says "Recent versions 
of GCC will mark the end of the function with an N_FUN symbol..."  
Sounds like the Solaris compilers may not have this end of function FUN 
stab at all.

Would somebody with access to a Solaris box with acc on it compile a 
simple program with "-g" and see if it has this stab, and if so what 
its value is?

I bet the code I suggested will work fine.

Jim
--
Jim Ingham                                   jingham@apple.com
Developer Tools - gdb
Apple Computer

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

[Daniel Jacobowitz]

On Thu, Jul 11, 2002 at 02:10:49PM -0700, Jim Ingham wrote:
> >I judge from your example that MacOSX has resolved addresses attached
> >to N_SLINE stabs, but not in ending N_FUN stabs?  GDB assumes that
> >function_start_offset applies to both of them equally (and it will be
> >zero if we expect both to be resolved).  On GNU/Linux both N_SLINE and
> >final N_FUN have offsets within the function.  I suspect that on some
> >Solaris variant N_SLINE and final N_FUN will both have resolved values.
> >In that case using last_function_start + valu will put us well outside
> >of the actual function, causing mayhem.
> 
> That's right.  MacOS X's linker does fix up the SLINE stabs, but it 
> does what stabs.texi says to do with the end of function stabs.
> 
> It would suprise me if there were a Solaris compile/linker that does 
> otherwise with the end of FUN stab.  After all, it seems like the 
> Solaris tools go out of their way to avoid having STABS that the linker 
> has to fix up.  Also, the comment in stabs.texi says "Recent versions 
> of GCC will mark the end of the function with an N_FUN symbol..."  
> Sounds like the Solaris compilers may not have this end of function FUN 
> stab at all.
> 
> Would somebody with access to a Solaris box with acc on it compile a 
> simple program with "-g" and see if it has this stab, and if so what 
> its value is?
> 
> I bet the code I suggested will work fine.

ACC is HP/UX, isn't it?  The Sun compiler is Sun Workshop CC.  In any
case, it appears that Solaris does not mark the end of functions with
stabs.  I'm satisfied; sorry for the runaround.

You might want to repost the patch not-mangled this time; since your
mail client persistently wraps things attaching it might be simplest.

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

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

[Jim Ingham]

[-- Attachment #1: Type: text/plain, Size: 2630 bytes --]

Daniel,

On Friday, July 12, 2002, at 10:30  AM, Daniel Jacobowitz wrote:

> On Thu, Jul 11, 2002 at 02:10:49PM -0700, Jim Ingham wrote:
>>> I judge from your example that MacOSX has resolved addresses attached
>>> to N_SLINE stabs, but not in ending N_FUN stabs?  GDB assumes that
>>> function_start_offset applies to both of them equally (and it will be
>>> zero if we expect both to be resolved).  On GNU/Linux both N_SLINE 
>>> and
>>> final N_FUN have offsets within the function.  I suspect that on some
>>> Solaris variant N_SLINE and final N_FUN will both have resolved 
>>> values.
>>> In that case using last_function_start + valu will put us well 
>>> outside
>>> of the actual function, causing mayhem.
>>
>> That's right.  MacOS X's linker does fix up the SLINE stabs, but it
>> does what stabs.texi says to do with the end of function stabs.
>>
>> It would suprise me if there were a Solaris compile/linker that does
>> otherwise with the end of FUN stab.  After all, it seems like the
>> Solaris tools go out of their way to avoid having STABS that the 
>> linker
>> has to fix up.  Also, the comment in stabs.texi says "Recent versions
>> of GCC will mark the end of the function with an N_FUN symbol..."
>> Sounds like the Solaris compilers may not have this end of function 
>> FUN
>> stab at all.
>>
>> Would somebody with access to a Solaris box with acc on it compile a
>> simple program with "-g" and see if it has this stab, and if so what
>> its value is?
>>
>> I bet the code I suggested will work fine.
>
> ACC is HP/UX, isn't it?  The Sun compiler is Sun Workshop CC.  In any
> case, it appears that Solaris does not mark the end of functions with
> stabs.  I'm satisfied; sorry for the runaround.

It has been five or six years since I actually worked on a Sun box that 
somebody had paid for Sun's tools for, but my memory was the actual 
binary was called acc.  I remember it wasn't called cc, 'cause it 
ticked me off at the time...

Anywya, thanks for looking into this.

>
> You might want to repost the patch not-mangled this time; since your
> mail client persistently wraps things attaching it might be simplest.

Yeah, it is an okay mailer in many other ways, but it does have this 
little quirk...  Here is the ChangeLog, and the patch as an attachment:

2002-07-10  Jim Ingham   <jingham@apple.com>

         * dbxread.c (process_one_symbol): Use last_function_start rather
         than function_start_offset to find the real beginning of the
         current function.  The latter is just the text section offset on
         some systems, the former is always the real function start...



[-- Attachment #2: dbxread.c.patch --]
[-- Type: application/octet-stream, Size: 1591 bytes --]

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	12 Jul 2002 17:34:50 -0000
***************
*** 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,2806 ----
  	{
  	  /* 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 ();
  

[-- Attachment #3: Type: text/plain, Size: 110 bytes --]



Jim
--
Jim Ingham                                   jingham@apple.com
Developer Tools - gdb
Apple Computer

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

[Elena Zannoni]

I've committed this change.

elena


Jim Ingham writes:
 > Daniel,
 > 
 > On Friday, July 12, 2002, at 10:30  AM, Daniel Jacobowitz wrote:
 > 
 > > On Thu, Jul 11, 2002 at 02:10:49PM -0700, Jim Ingham wrote:
 > >>> I judge from your example that MacOSX has resolved addresses attached
 > >>> to N_SLINE stabs, but not in ending N_FUN stabs?  GDB assumes that
 > >>> function_start_offset applies to both of them equally (and it will be
 > >>> zero if we expect both to be resolved).  On GNU/Linux both N_SLINE 
 > >>> and
 > >>> final N_FUN have offsets within the function.  I suspect that on some
 > >>> Solaris variant N_SLINE and final N_FUN will both have resolved 
 > >>> values.
 > >>> In that case using last_function_start + valu will put us well 
 > >>> outside
 > >>> of the actual function, causing mayhem.
 > >>
 > >> That's right.  MacOS X's linker does fix up the SLINE stabs, but it
 > >> does what stabs.texi says to do with the end of function stabs.
 > >>
 > >> It would suprise me if there were a Solaris compile/linker that does
 > >> otherwise with the end of FUN stab.  After all, it seems like the
 > >> Solaris tools go out of their way to avoid having STABS that the 
 > >> linker
 > >> has to fix up.  Also, the comment in stabs.texi says "Recent versions
 > >> of GCC will mark the end of the function with an N_FUN symbol..."
 > >> Sounds like the Solaris compilers may not have this end of function 
 > >> FUN
 > >> stab at all.
 > >>
 > >> Would somebody with access to a Solaris box with acc on it compile a
 > >> simple program with "-g" and see if it has this stab, and if so what
 > >> its value is?
 > >>
 > >> I bet the code I suggested will work fine.
 > >
 > > ACC is HP/UX, isn't it?  The Sun compiler is Sun Workshop CC.  In any
 > > case, it appears that Solaris does not mark the end of functions with
 > > stabs.  I'm satisfied; sorry for the runaround.
 > 
 > It has been five or six years since I actually worked on a Sun box that 
 > somebody had paid for Sun's tools for, but my memory was the actual 
 > binary was called acc.  I remember it wasn't called cc, 'cause it 
 > ticked me off at the time...
 > 
 > Anywya, thanks for looking into this.
 > 
 > >
 > > You might want to repost the patch not-mangled this time; since your
 > > mail client persistently wraps things attaching it might be simplest.
 > 
 > Yeah, it is an okay mailer in many other ways, but it does have this 
 > little quirk...  Here is the ChangeLog, and the patch as an attachment:
 > 
 > 2002-07-10  Jim Ingham   <jingham@apple.com>
 > 
 >          * dbxread.c (process_one_symbol): Use last_function_start rather
 >          than function_start_offset to find the real beginning of the
 >          current function.  The latter is just the text section offset on
 >          some systems, the former is always the real function start...
 > 
 > 
 > 
 > 
 > Jim
 > --
 > Jim Ingham                                   jingham@apple.com
 > Developer Tools - gdb
 > Apple Computer
 >