This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFA] Introduce notion of "search name"
A quick grep of GDB shows that we're already doing:
$ grep -e SYMBOL_PRINT_NAME -e SYMBOL_CPLUS_DEMANGLED_NAME -e
DEPRECATED_SYMBOL_NAME -e SYMBOL_NATURAL_NAME -e SYMBOL_SOURCE_NAME -e
SYMBOL_LINKAGE_NAME *.c | grep -v -e ^sym -e syms.c: -e read.c: | cut
-d: -f1 | sort -u
ada-lang.c
ada-typeprint.c
ax-gdb.c
blockframe.c
breakpoint.c
buildsym.c
c-valprint.c
cp-namespace.c
cp-support.c
cp-valprint.c
dictionary.c
dwarf2loc.c
expprint.c
f-valprint.c
findvar.c
glibc-tdep.c
gnu-v2-abi.c
hppa-hpux-tdep.c
i386-tdep.c
infcall.c
infcmd.c
jv-lang.c
linespec.c
maint.c
objc-lang.c
objfiles.c
p-valprint.c
ppc-sysv-tdep.c
printcmd.c
rs6000-tdep.c
solib-frv.c
somsolib.c
stack.c
tracepoint.c
typeprint.c
valops.c
I.e., through out GDB there is the assumption that symtab internally
uses simple strings.
We shouldn't. Recalling that one of the underlying problems here was
the need to construct search names on the fly using more complext debug
info, we should instead have interfaces such as:
symtab_name_put (symtab, ui_file):
Write the printable name to the specified output.
symtab_demanged_cmp (block, symtab, symtab):
Compare to symbols returning their relative position.
that completly abastract symbol name lifetimes (you never know if it is
defined).
By doing that we better specify the symtab interface; clarify the
clients requirements; and free the symtab code of specific
implementation assumptions.
We can also finally answer questions such as:
- how often is the printed name used
- how often is a symbol comparison performed
and use that to adjust the internal representation so that it better
meets real needs
Andrew