From: David Carlton <carlton@math.stanford.edu>
To: Elena Zannoni <ezannoni@redhat.com>
Cc: "Martin M. Hunt" <hunt@redhat.com>, gdb@sources.redhat.com
Subject: Re: very very slow symbol searches
Date: Wed, 22 Jan 2003 17:41:00 -0000 [thread overview]
Message-ID: <ro1lm1dw08n.fsf@jackfruit.Stanford.EDU> (raw)
In-Reply-To: <15918.45982.254578.620499@localhost.redhat.com>
On Wed, 22 Jan 2003 10:07:10 -0500, Elena Zannoni <ezannoni@redhat.com> said:
> Martin M. Hunt writes:
>> Anyone have any idea why search_symbols in symtab.c is now a few
>> thousand times slower than it used to be? At least it is on Linux
>> x86.
>> Insight calls search_symbols twice on startup. Sometime 2-4 weeks
>> ago, (builds from CVS on sources) Insight started taking a minute
>> or two to load when debugging itself. It is very fast when
>> debugging small programs, but large things like insight or gdb take
>> forever. At first glance the problem is that search_symbols() is
>> taking 20-30 seconds to return.
> there have been some changes to that function on 12-23. Could you
> try backing those out? This was a change we convinced ourselves it
> was ok to do, but maybe it is problematic.
Yeah, I actually submitted a patch to revert the search_symbols part
of my 12-23 change as part of my patch to demangle partial symbols:
now that I understand lookup_symbol_aux_minimal better, I'm sure
that's not the right thing to call in that situation. I'd been
waiting on pushing that reversion until we'd made a final decision as
to whether or not to demangle partial symbols, but probably reverting
it now would be a good idea.
Of course, even if the search_symbols part of that patch is reverted,
it may be the case that the change to lookup_symbol_aux_minimal also
causes problems. I hope not, but it's certainly not out of the
question. I'm including the patch that Elena referred to after my
signature: Martin, could you test if reverting just the search_symbols
part helps, or if it's necessary to revert the whole thing? (Or we
might be barking up the wrong tree entirely, I suppose.)
David Carlton
carlton@math.stanford.edu
Index: symtab.c
===================================================================
RCS file: /cvs/src/src/gdb/symtab.c,v
retrieving revision 1.82
diff -u -p -r1.82 symtab.c
--- symtab.c 17 Dec 2002 18:34:06 -0000 1.82
+++ symtab.c 19 Dec 2002 23:02:35 -0000
@@ -117,8 +117,7 @@ struct symbol *lookup_symbol_aux_minsyms
const char *mangled_name,
const namespace_enum namespace,
int *is_a_field_of_this,
- struct symtab **symtab,
- int *force_return);
+ struct symtab **symtab);
static struct symbol *find_active_alias (struct symbol *sym, CORE_ADDR addr);
@@ -805,14 +804,6 @@ lookup_symbol_aux (const char *name, con
struct symbol *sym;
const struct block *static_block;
- /* FIXME: carlton/2002-11-05: This variable is here so that
- lookup_symbol_aux will sometimes return NULL after receiving a
- NULL return value from lookup_symbol_aux_minsyms, without
- proceeding on to the partial symtab and static variable tests. I
- suspect that that's a bad idea. */
-
- int force_return;
-
/* Search specified block and its superiors. Don't search
STATIC_BLOCK or GLOBAL_BLOCK. */
@@ -931,13 +922,11 @@ lookup_symbol_aux (const char *name, con
a mangled variable that is stored in one of the minimal symbol tables.
Eventually, all global symbols might be resolved in this way. */
- force_return = 0;
-
sym = lookup_symbol_aux_minsyms (name, mangled_name,
namespace, is_a_field_of_this,
- symtab, &force_return);
+ symtab);
- if (sym != NULL || force_return == 1)
+ if (sym != NULL)
return sym;
#endif
@@ -981,13 +970,11 @@ lookup_symbol_aux (const char *name, con
*/
- force_return = 0;
-
sym = lookup_symbol_aux_minsyms (name, mangled_name,
namespace, is_a_field_of_this,
- symtab, &force_return);
+ symtab);
- if (sym != NULL || force_return == 1)
+ if (sym != NULL)
return sym;
#endif
@@ -1172,13 +1159,20 @@ lookup_symbol_aux_psymtabs (int block_in
tables. Eventually, all global symbols might be resolved in this
way. */
+/* NOTE: carlton/2002-12-05: At one point, this function was part of
+ lookup_symbol_aux, and what are now 'return' statements within
+ lookup_symbol_aux_minsyms returned from lookup_symbol_aux, even if
+ sym was NULL. As far as I can tell, this was basically accidental;
+ it didn't happen every time that msymbol was non-NULL, but only if
+ some additional conditions held as well, and it caused problems
+ with HP-generated symbol tables. */
+
static struct symbol *
lookup_symbol_aux_minsyms (const char *name,
const char *mangled_name,
const namespace_enum namespace,
int *is_a_field_of_this,
- struct symtab **symtab,
- int *force_return)
+ struct symtab **symtab)
{
struct symbol *sym;
struct blockvector *bv;
@@ -1271,7 +1265,6 @@ lookup_symbol_aux_minsyms (const char *n
if (symtab != NULL && sym != NULL)
*symtab = s;
- *force_return = 1;
return fixup_symbol_section (sym, s->objfile);
}
else if (MSYMBOL_TYPE (msymbol) != mst_text
@@ -1280,7 +1273,6 @@ lookup_symbol_aux_minsyms (const char *n
{
/* This is a mangled variable, look it up by its
mangled name. */
- *force_return = 1;
return lookup_symbol_aux (SYMBOL_NAME (msymbol), mangled_name,
NULL, namespace, is_a_field_of_this,
symtab);
@@ -2904,12 +2896,31 @@ search_symbols (char *regexp, namespace_
{
if (0 == find_pc_symtab (SYMBOL_VALUE_ADDRESS (msymbol)))
{
- if (kind == FUNCTIONS_NAMESPACE
- || lookup_symbol (SYMBOL_NAME (msymbol),
- (struct block *) NULL,
- VAR_NAMESPACE,
- 0, (struct symtab **) NULL) == NULL)
- found_misc = 1;
+ if (kind == FUNCTIONS_NAMESPACE)
+ {
+ found_misc = 1;
+ }
+ else
+ {
+ struct symbol *sym;
+
+ if (SYMBOL_DEMANGLED_NAME (msymbol) != NULL)
+ sym
+ = lookup_symbol_aux_minsyms (SYMBOL_DEMANGLED_NAME
+ (msymbol),
+ SYMBOL_NAME (msymbol),
+ VAR_NAMESPACE,
+ NULL, NULL);
+ else
+ sym
+ = lookup_symbol_aux_minsyms (SYMBOL_NAME (msymbol),
+ NULL,
+ VAR_NAMESPACE,
+ NULL, NULL);
+
+ if (sym == NULL)
+ found_misc = 1;
+ }
}
}
}
next prev parent reply other threads:[~2003-01-22 17:41 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-01-22 11:58 Martin M. Hunt
2003-01-22 15:02 ` Elena Zannoni
2003-01-22 17:41 ` David Carlton [this message]
2003-01-22 19:36 ` Andrew Cagney
2003-01-22 20:46 ` Martin M. Hunt
2003-01-23 1:14 ` Martin M. Hunt
2003-01-23 1:45 ` Daniel Jacobowitz
2003-01-23 2:43 ` Martin M. Hunt
2003-01-23 6:10 ` Eli Zaretskii
2003-01-23 16:54 ` Daniel Jacobowitz
2003-01-23 20:06 ` Andrew Cagney
2003-01-22 18:26 ` David Carlton
2003-01-22 18:44 ` David Carlton
2003-01-26 7:48 ` Martin M. Hunt
2003-01-27 17:03 ` 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=ro1lm1dw08n.fsf@jackfruit.Stanford.EDU \
--to=carlton@math.stanford.edu \
--cc=ezannoni@redhat.com \
--cc=gdb@sources.redhat.com \
--cc=hunt@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