From: Joel Brobecker <brobecker@gnat.com>
To: Jason Molenda <jmolenda@apple.com>
Cc: Andrew Cagney <cagney@gnu.org>, gdb-patches@sources.redhat.com
Subject: Re: Question about blockframe.c:inside_main_func()
Date: Thu, 29 Apr 2004 01:02:00 -0000 [thread overview]
Message-ID: <20040429010205.GS867@gnat.com> (raw)
In-Reply-To: <9B827536-9972-11D8-9EA7-000A9569836A@apple.com>
> We're bringing up the currentish gdb sources here at Apple and I was
> debugging a problem with inside_main_func () [*] when I noticed that
> there seems to be a bit of extra computation that has snuck into the
> function during the changes since July.
Indeed, it seems that we could improve a bit this code: It really looks
like we are trying to compute the low/high addresses for function main
twice! Even when main is found within the debug info, we go through the
through the trouble of finding the bounds of function "main" from the
min syms anyway. A missing condition somewhere?
At first glance, I would think something like this ought to work:
if (lowpc == INVALID && highpc == INVALID)
{
msymbol = lookup_minimal_symbol (main_name ()
if (msymbol != NULL)
{
/* Try finding the bounds from the debug info. */
struct symbol *mainsym = find_pc_function (...);
if (mainsym != NULL && ...)
{
lowpc = BLOCK_START (...);
highpc = BLOCK_END (...);
}
else
{
/* Not found in the debug info, use the minsyms... */
CORE_ADDR maddr = SYMBOL_VALUE_ADDRESS (msymbol);
[...]
}
}
}
return (lowpc <= pc && highpc > pc);
Unless Andrew had a reason to believe that recomputing the low/high
PCs was necessary?
See http://sources.redhat.com/ml/gdb-patches/2003-07/msg00144.html,
where the block computing the function bounds from minimal symbols
was introduced.
--
Joel
next prev parent reply other threads:[~2004-04-29 1:02 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-04-29 0:17 Jason Molenda
2004-04-29 1:02 ` Joel Brobecker [this message]
2004-04-29 1:50 ` Jason Molenda
2004-04-29 15:09 ` Andrew Cagney
2004-04-30 0:27 ` Jason Molenda
2004-04-30 0:49 ` 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=20040429010205.GS867@gnat.com \
--to=brobecker@gnat.com \
--cc=cagney@gnu.org \
--cc=gdb-patches@sources.redhat.com \
--cc=jmolenda@apple.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