From: Fernando Nasser <fnasser@redhat.com>
To: Jim Blandy <jimb@cygnus.com>
Cc: Fernando Nasser <fnasser@cygnus.com>,
Christopher Faylor <cgf@redhat.com>,
gdb-patches@sources.redhat.com
Subject: Re: Simple but crucial bug fix to gdb
Date: Thu, 31 May 2001 05:30:00 -0000 [thread overview]
Message-ID: <3B1638A2.79AE4BCF@redhat.com> (raw)
In-Reply-To: <npvgmimcih.fsf@zwingli.cygnus.com>
Jim Blandy wrote:
>
> Fernando Nasser <fnasser@cygnus.com> writes:
> > I cannot approve the patch because I am not the maintainer of the
> > stabs reader, but (for the reasons you've explained above) this
> > seems to fall clearly into the obvious fix rule.
>
> This is *not* an obvious fix.
>
> The stabs reader has seen a symbol definition, before it has any idea
> what compilation unit that symbol belongs to. Are you *sure* it's
> okay to just ignore that symbol definition? Won't the psymtab's start
> and end addresses get set wrong?
Irrelevant to the fact that his compiler may not be doing the right
thing, GDB should not be dumping core.
Furthermore, as Chris said, the previous test already test for 'pst'
being set, so he would not be making it any worse than it was.
Furthermore, it would not affect any one with a more sane compiler.
Furthermore, the condition of _this_ if already test for 'pst' after
'textlow_not_set' is reset (i.e., on every subsequent pass of the loop
after this test succeeds the first time).
So,
original:
if (textlow_not_set
|| (pst && CUR_SYMBOL_VALUE < pst->textlow
&& CUR_SYMBOL_VALUE
!= ANOFFSET (objfile->section_offsets, SECT_OFF_TEXT
(objfile))))
and
changed:
if (pst && textlow_not_set
|| (pst && CUR_SYMBOL_VALUE < pst->textlow
&& CUR_SYMBOL_VALUE
!= ANOFFSET (objfile->section_offsets, SECT_OFF_TEXT
(objfile))))
are either as right or as wrong as each other, except that the second
one is more defensive and IMHO more right than the first one, where we
guard from one condition (pst not set) on the second part of the if and
not on the first).
This is an obvious fix! If the original code there is wrong, it has
been so for a while. You, as the maintainer, should go there and see
what is wrong (or understand why it does that ;-) ). But letting GDB
dump core on someone is just not the right thing to do.
I sincerely expect that you provide us with the "more correct" fix asap.
Regards,
Fernando
------------------------code from the file-----------------------
case 'f':
CUR_SYMBOL_VALUE += ANOFFSET (objfile->section_offsets,
SECT_OFF_TEXT (objfile));
#ifdef DBXREAD_ONLY
/* Kludges for ELF/STABS with Sun ACC */
last_function_name = namestring;
#ifdef SOFUN_ADDRESS_MAYBE_MISSING
/* Do not fix textlow==0 for .o or NLM files, as 0 is a legit
value for the bottom of the text seg in those cases. */
if (pst && textlow_not_set)
{
pst->textlow =
find_stab_function_addr (namestring, pst->filename,
objfile);
textlow_not_set = 0;
}
#endif
/* End kludge. */
/* Keep track of the start of the last function so we
can handle end of function symbols. */
last_function_start = CUR_SYMBOL_VALUE;
/* In reordered executables this function may lie outside
the bounds created by N_SO symbols. If that's the case
use the address of this function as the low bound for
the partial symbol table. */
if (textlow_not_set
|| (pst && CUR_SYMBOL_VALUE < pst->textlow
&& CUR_SYMBOL_VALUE
!= ANOFFSET (objfile->section_offsets, SECT_OFF_TEXT
(objfile))))
{
pst->textlow = CUR_SYMBOL_VALUE;
textlow_not_set = 0;
}
#endif /* DBXREAD_ONLY */
add_psymbol_to_list (namestring, p - namestring,
VAR_NAMESPACE, LOC_BLOCK,
&objfile->static_psymbols,
0, CUR_SYMBOL_VALUE,
psymtab_language, objfile);
continue;
--
Fernando Nasser
Red Hat Canada Ltd. E-Mail: fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario M4P 2C9
next prev parent reply other threads:[~2001-05-31 5:30 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-05-30 14:27 Charlie Mills
2001-05-30 14:36 ` Christopher Faylor
2001-05-30 15:16 ` Fernando Nasser
2001-05-30 20:18 ` Jim Blandy
2001-05-30 20:25 ` Christopher Faylor
2001-05-31 5:30 ` Fernando Nasser [this message]
2001-05-31 13:55 ` Jim Blandy
2001-05-31 14:43 ` Fernando Nasser
2001-05-31 16:46 ` Christopher Faylor
2001-05-31 17:40 ` Daniel Berlin
2001-05-31 20:00 ` Frank Ch. Eigler
2001-06-01 9:41 ` Fernando Nasser
2001-06-01 10:01 ` Michael Snyder
2001-06-01 11:14 ` Daniel Berlin
2001-06-01 11:25 ` Fernando Nasser
2001-06-01 14:05 ` Charlie Mills
2001-06-06 6:01 ` Andrew Cagney
2001-05-30 20:00 ` Christopher Faylor
2001-05-30 20:43 ` Christopher Faylor
2001-05-30 20:12 ` Jim Blandy
2001-05-30 21:23 ` Daniel Berlin
2001-06-01 13:35 ` Jim Blandy
2001-06-01 13:41 ` Fernando Nasser
2001-06-01 14:07 ` Daniel Berlin
2001-06-01 14:15 ` Jim Blandy
2001-06-01 14:17 ` Jim Blandy
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=3B1638A2.79AE4BCF@redhat.com \
--to=fnasser@redhat.com \
--cc=cgf@redhat.com \
--cc=fnasser@cygnus.com \
--cc=gdb-patches@sources.redhat.com \
--cc=jimb@cygnus.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