Re: [rfa] Add SYMBOL_SET_LINKAGE_NAME

[Daniel Jacobowitz <drow@false.org>]

On Tue, Feb 17, 2004 at 10:57:39AM -0500, Andrew Cagney wrote:
> >On Mon, Feb 16, 2004 at 04:48:57PM -0500, Elena Zannoni wrote:
> >
> >>Daniel Jacobowitz writes:
> >> > After this patch and my others from today there are no direct
> >> > assignments to the symbol name. In addition to the cleanup value, I'm
> >> > testing an approach which would change the storage of symbol names,
> >> > which prompted me to do this.  
> >>
> >>can you elaborate on where you are going?
> >
> >
> >Sure.  I'm not sure if it's actually going to end up this way, since
> >I'm thinking it wasn't a great idea and it has some truly gross bits I
> >haven't figured out what to do with yet - it was just a hack job last
> >weekend.  But here's what my current tree does.
> >
> >The C++ demangled name pointer in lang_specific is removed.  The name
> >pointer becomes a union, and a flag bit (there's about a byte's worth
> >of empty space in general_symbol_info) is added.  They look like this:
> 
> Er, why not start by defining a relevant interface and then work 
> inwards?  That way potential clients, such as paulh, can determine if it 
> is sufficient for their needs.  The first implementation doesn't even 
> need to be fast, just correct.  Once we've hard data on the interfaces 
> run-time behavioral characteristics we can consider symtab internal changes.

Because the cleaner interface is not my goal - it's a side goal to my
actual aims, which are improved GDB startup time and memory usage.  An
implementation which is not fast is a step backwards.  I don't
understand how you can propose to measure "hard data" on "run-time
behavioral characteristics" without implementing the symtab internal
changes - what am I missing?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer