MatCat.OpenSource/8sa1-binutils-gdb
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

* symtab.c: Remove a function that has been commented out 3 years ago.

Browse Source
This commit is contained in:
Joel Brobecker 2007-08-29 18:34:47 +00:00
parent c25c34f8fb
commit fd4a0f2fbb
2 changed files with 4 additions and 135 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
gdb/ChangeLog
View File

@ -1,3 +1,7 @@
2007-08-29 Joel Brobecker <brobecker@adacore.com>
* symtab.c: Remove a function that has been commented out 3 years ago.
2007-08-29 Randolph Chung <tausq@debian.org>
* hppa-tdep.c (hppa32_cannot_fetch_register)

135
gdb/symtab.c
View File

@ -108,15 +108,6 @@ struct symbol *lookup_symbol_aux_psymtabs (int block_index,
const domain_enum domain,
struct symtab **symtab);
#if 0
static
struct symbol *lookup_symbol_aux_minsyms (const char *name,
const char *linkage_name,
const domain_enum domain,
int *is_a_field_of_this,
struct symtab **symtab);
#endif
static void fixup_section (struct general_symbol_info *, struct objfile *);
static int file_matches (char *, char **, int);
@ -1466,132 +1457,6 @@ lookup_symbol_aux_psymtabs (int block_index, const char *name,
return NULL;
}
#if 0
/* Check for the possibility of the symbol being a function or a
mangled variable that is stored in one of the minimal symbol
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. */
/* NOTE: carlton/2003-05-14: This function was once used as part of
lookup_symbol. It is currently unnecessary for correctness
reasons, however, and using it doesn't seem to be any faster than
using lookup_symbol_aux_psymtabs, so I'm commenting it out. */
static struct symbol *
lookup_symbol_aux_minsyms (const char *name,
const char *linkage_name,
const domain_enum domain,
int *is_a_field_of_this,
struct symtab **symtab)
{
struct symbol *sym;
struct blockvector *bv;
const struct block *block;
struct minimal_symbol *msymbol;
struct symtab *s;
if (domain == VAR_DOMAIN)
{
msymbol = lookup_minimal_symbol (name, NULL, NULL);
if (msymbol != NULL)
{
/* OK, we found a minimal symbol in spite of not finding any
symbol. There are various possible explanations for
this. One possibility is the symbol exists in code not
compiled -g. Another possibility is that the 'psymtab'
isn't doing its job. A third possibility, related to #2,
is that we were confused by name-mangling. For instance,
maybe the psymtab isn't doing its job because it only
know about demangled names, but we were given a mangled
name... */
/* We first use the address in the msymbol to try to locate
the appropriate symtab. Note that find_pc_sect_symtab()
has a side-effect of doing psymtab-to-symtab expansion,
for the found symtab. */
s = find_pc_sect_symtab (SYMBOL_VALUE_ADDRESS (msymbol),
SYMBOL_BFD_SECTION (msymbol));
if (s != NULL)
{
/* This is a function which has a symtab for its address. */
bv = BLOCKVECTOR (s);
block = BLOCKVECTOR_BLOCK (bv, GLOBAL_BLOCK);
/* This call used to pass `SYMBOL_LINKAGE_NAME (msymbol)' as the
`name' argument to lookup_block_symbol. But the name
of a minimal symbol is always mangled, so that seems
to be clearly the wrong thing to pass as the
unmangled name. */
sym =
lookup_block_symbol (block, name, linkage_name, domain);
/* We kept static functions in minimal symbol table as well as
in static scope. We want to find them in the symbol table. */
if (!sym)
{
block = BLOCKVECTOR_BLOCK (bv, STATIC_BLOCK);
sym = lookup_block_symbol (block, name,
linkage_name, domain);
}
/* NOTE: carlton/2002-12-04: The following comment was
taken from a time when two versions of this function
were part of the body of lookup_symbol_aux: this
comment was taken from the version of the function
that was #ifdef HPUXHPPA, and the comment was right
before the 'return NULL' part of lookup_symbol_aux.
(Hence the "Fall through and return 0" comment.)
Elena did some digging into the situation for
Fortran, and she reports:
"I asked around (thanks to Jeff Knaggs), and I think
the story for Fortran goes like this:
"Apparently, in older Fortrans, '_' was not part of
the user namespace. g77 attached a final '_' to
procedure names as the exported symbols for linkage
(foo_) , but the symbols went in the debug info just
like 'foo'. The rationale behind this is not
completely clear, and maybe it was done to other
symbols as well, not just procedures." */
/* If we get here with sym == 0, the symbol was
found in the minimal symbol table
but not in the symtab.
Fall through and return 0 to use the msymbol
definition of "foo_".
(Note that outer code generally follows up a call
to this routine with a call to lookup_minimal_symbol(),
so a 0 return means we'll just flow into that other routine).
This happens for Fortran "foo_" symbols,
which are "foo" in the symtab.
This can also happen if "asm" is used to make a
regular symbol but not a debugging symbol, e.g.
asm(".globl _main");
asm("_main:");
*/
if (symtab != NULL && sym != NULL)
*symtab = s;
return fixup_symbol_section (sym, s->objfile);
}
}
}
return NULL;
}
#endif /* 0 */
/* A default version of lookup_symbol_nonlocal for use by languages
that can't think of anything better to do. This implements the C
lookup rules. */