From: Jim Ingham <jingham@apple.com>
To: Daniel Jacobowitz <drow@mvista.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [patch] Fix to processing end of function stab in dbxread.c
Date: Thu, 11 Jul 2002 16:40:00 -0000 [thread overview]
Message-ID: <ACB33854-9512-11D6-AB35-00039379E320@apple.com> (raw)
In-Reply-To: <20020711184252.GA29207@nevyn.them.org>
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
next prev parent reply other threads:[~2002-07-11 21:10 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-07-10 19:08 Jim Ingham
2002-07-11 2:42 ` Daniel Jacobowitz
2002-07-11 11:42 ` Jim Ingham
2002-07-11 11:52 ` Daniel Jacobowitz
2002-07-11 16:40 ` Jim Ingham [this message]
2002-07-12 10:46 ` Daniel Jacobowitz
2002-07-12 11:03 ` Jim Ingham
2003-02-18 15:41 ` Elena Zannoni
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ACB33854-9512-11D6-AB35-00039379E320@apple.com \
--to=jingham@apple.com \
--cc=drow@mvista.com \
--cc=gdb-patches@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox