This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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: dbxread.c.patch
Description: Binary data


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]