From: Andrew Cagney <cagney@gnu.org>
To: Daniel Jacobowitz <drow@false.org>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [rfa/mips] Stop backtraces when we've lost the PC
Date: Fri, 19 Mar 2004 00:09:00 -0000 [thread overview]
Message-ID: <4058AFE6.8030609@gnu.org> (raw)
In-Reply-To: <20040308202557.GA28874@nevyn.them.org>
> {
> int low, mid, high;
> char *ptr;
> + CORE_ADDR pdr_pc;
>
> low = 0;
> high = priv->size / 32;
>
> + /* First, find the last .pdr entry starting at or before PC. */
A summary here of what the objective is and what / why the follow on
code is doing.
> do
> {
> - CORE_ADDR pdr_pc;
> -
> mid = (low + high) / 2;
>
> ptr = priv->contents + mid * 32;
> pdr_pc = bfd_get_signed_32 (sec->objfile->obfd, ptr);
> pdr_pc += ANOFFSET (sec->objfile->section_offsets,
> SECT_OFF_TEXT (sec->objfile));
> - if (pdr_pc == startaddr)
> + if (pdr_pc == pc)
> break;
> - if (pdr_pc > startaddr)
> + if (pdr_pc > pc)
> high = mid;
> else
> low = mid + 1;
> }
> while (low != high);
Other than that, just an observation that the binary search is [already]
pretty messed up. In all likelyhood the test:
if (pdr_pc == pc)
will never fire and having it gains little if anything (one less
iteration VS logN extra compares). Eliminating it means cleaning up the
binary search though. Can you attach a fixme to that test indicating
that it should be eliminated.
I also suspect that STARTADDR's computation can be delayed until it is
needed (the latter reference that goes with the "pathological", should
no longer occure, I think it has been moved into symbol reading.
However, leave that for the moment.
Otherwize ok, and way better than the original patch, thanks,
Andrew
WARNING: multiple messages have this Message-ID
From: Andrew Cagney <cagney@gnu.org>
To: Daniel Jacobowitz <drow@false.org>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [rfa/mips] Stop backtraces when we've lost the PC
Date: Wed, 17 Mar 2004 22:11:00 -0000 [thread overview]
Message-ID: <4058AFE6.8030609@gnu.org> (raw)
Message-ID: <20040317221100.AzsJe8VGlEI7MQAGZ1_ORxGJDFEfQTkThsf7i8GlUuQ@z> (raw)
In-Reply-To: <20040308202557.GA28874@nevyn.them.org>
> {
> int low, mid, high;
> char *ptr;
> + CORE_ADDR pdr_pc;
>
> low = 0;
> high = priv->size / 32;
>
> + /* First, find the last .pdr entry starting at or before PC. */
A summary here of what the objective is and what / why the follow on
code is doing.
> do
> {
> - CORE_ADDR pdr_pc;
> -
> mid = (low + high) / 2;
>
> ptr = priv->contents + mid * 32;
> pdr_pc = bfd_get_signed_32 (sec->objfile->obfd, ptr);
> pdr_pc += ANOFFSET (sec->objfile->section_offsets,
> SECT_OFF_TEXT (sec->objfile));
> - if (pdr_pc == startaddr)
> + if (pdr_pc == pc)
> break;
> - if (pdr_pc > startaddr)
> + if (pdr_pc > pc)
> high = mid;
> else
> low = mid + 1;
> }
> while (low != high);
Other than that, just an observation that the binary search is [already]
pretty messed up. In all likelyhood the test:
if (pdr_pc == pc)
will never fire and having it gains little if anything (one less
iteration VS logN extra compares). Eliminating it means cleaning up the
binary search though. Can you attach a fixme to that test indicating
that it should be eliminated.
I also suspect that STARTADDR's computation can be delayed until it is
needed (the latter reference that goes with the "pathological", should
no longer occure, I think it has been moved into symbol reading.
However, leave that for the moment.
Otherwize ok, and way better than the original patch, thanks,
Andrew
next prev parent reply other threads:[~2004-03-17 22:11 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-03-19 0:09 Daniel Jacobowitz
2004-03-06 23:17 ` Daniel Jacobowitz
2004-03-08 0:56 ` Andrew Cagney
2004-03-08 3:23 ` Daniel Jacobowitz
2004-03-19 0:09 ` Daniel Jacobowitz
2004-03-08 15:48 ` Daniel Jacobowitz
2004-03-08 20:26 ` Daniel Jacobowitz
2004-03-19 0:09 ` Andrew Cagney [this message]
2004-03-17 22:11 ` Andrew Cagney
2004-03-22 21:07 ` Daniel Jacobowitz
2004-03-19 0:09 ` Daniel Jacobowitz
2004-03-11 20:51 ` Andrew Cagney
2004-03-19 0:09 ` Daniel Jacobowitz
2004-03-11 20:57 ` Daniel Jacobowitz
2004-03-19 0:09 ` Andrew Cagney
2004-03-11 23:47 ` Andrew Cagney
2004-03-19 0:09 ` Daniel Jacobowitz
2004-03-12 0:00 ` Daniel Jacobowitz
2004-03-19 0:09 ` Andrew Cagney
2004-03-19 0:09 ` Daniel Jacobowitz
2004-03-08 17:41 ` Daniel Jacobowitz
2004-03-19 0:09 ` Andrew Cagney
2004-03-08 16:33 ` Andrew Cagney
2004-03-19 0:09 ` Daniel Jacobowitz
2004-03-19 0:09 ` Andrew Cagney
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=4058AFE6.8030609@gnu.org \
--to=cagney@gnu.org \
--cc=drow@false.org \
--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