This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [rfa] Add SYMBOL_SET_LINKAGE_NAME
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