Re: Abstracting "name"

[Jim Blandy <jimb@redhat.com>]

Andrew Cagney <cagney@gnu.org> writes:
> > [Subject changed from Re: [RFA] Introduce notion of "search name"]
> > Andrew Cagney wrote:
> >
> >>> Just like the frame, arch, and regcache code, this won't be easy
> >>> or simple - it will take multiple iterations and true long term
> >>> commitment to GDB.
> >
> >>> What we do need to do is recognize the real value in perusing this
> >>> strategy (screwing down and better defining interfaces), and that
> >>> it is a strategy we can't afford to postpone.  Can we do that?
> > I'm all for good interfaces.  The first step here, it seems to me,
> > is to
> > understand better just what we want out of such an interface---a
> > requirements memo or API sketch.  Andrew has so far listed the following:
> >     symtab_name_put (symbol, ui_file):
> >     Write the printable name to the specified output.
> >     symtab_demangled_cmp (block, symbol, symbol):
> >     Compare two symbols returning their relative position.
> > [Actually, Andrew's name for this last was "symtab_demanged_cmp",
> > which is
> >  appealing, but perhaps too likely to provoke remark. :->)]  Presumably,
> > you'd also need various functions such as     symtab_*_name_matches
> > (char*, symbol)
> (const char * :-)
> 
> FYI, another long term objective is to make published symbol objects a
> flyweight.  Stop trying to differentiate between full and partial
> symbols (except within the symtab code) and stop dictating that
> there's this two stage load.

Yes --- reading symbolic information incrementally is a good strategy,
but it needs to be done differently for STABS and Dwarf 2.  The
interface shouldn't expose how or when various stages take place.

Dividing information about symbols and types into intrinsic (names;
lists of members and their types) and extrinsic (the address this
symbol has in this run of this executable) and then taking advantage
of the new sharing opportunities that enables would be nice, too.

The two are distinct goals, though.