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"
- From: Jim Blandy <jimb at redhat dot com>
- To: Daniel Jacobowitz <drow at false dot org>
- Cc: Paul Hilfinger <hilfingr at gnat dot com>, gdb-patches at sources dot redhat dot com
- Date: 01 Apr 2004 10:20:07 -0500
- Subject: Re: [RFA] Introduce notion of "search name"
- References: <20040303191550.7307DF2DB8@nile.gnat.com><20040305035955.GH5320@nevyn.them.org><20040305103925.A4815F2EE4@nile.gnat.com><20040331221249.GA6811@nevyn.them.org> <vt2brmbeon5.fsf@zenia.home><20040401150022.GA30729@nevyn.them.org>
Daniel Jacobowitz <drow@false.org> writes:
> On Thu, Apr 01, 2004 at 09:52:46AM -0500, Jim Blandy wrote:
> >
> > Daniel Jacobowitz <drow@false.org> writes:
> > > On Fri, Mar 05, 2004 at 05:39:25AM -0500, Paul Hilfinger wrote:
> > > > Daniel,
> > > >
> > > > > It doesn't address on of the thornier problems I hit when doing the
> > > > > same thing, namely that of allocation. OK, someone uses
> > > > > SYMBOL_DEMANGLED_NAME, we lazily allocate a demangled name - where? The
> > > > > objfile is not available. I think there may be no option but to
> > > > > pass the objfile to SYMBOL_DEMANGLED_NAME. What did you do for Ada?
> > > >
> > > > You're right, I did not address this in the patch proper. I had
> > > > prepared a patch in which I used that extra byte in struct symtab to
> > > > tag the union and allow an objfile member. However, I was aware from
> > > > correspondence with you that you were working in this area, and that
> > > > some of what you proposed to do might eventually allow us to re-do Ada
> > > > symbol lookup. So I decided not to modify the symtab struct for the
> > > > moment, and instead submit a patch that would change as little as
> > > > possible. I figured it would be better not to do anything just now
> > > > that might interfere with on-going work on the symbol table.
> > > >
> > > > So as an interim measure, I use your suggestion of 21 Jan and first
> > > > try to find an objfile via the BFD section. When that doesn't work, I
> > > > simply use a global hashtable to hold the demangled strings. Yes,
> > > > that is a memory leak, but on consideration, I realized that it's only
> > > > REALLY a memory leak if (a) I routinely change the entire set of
> > > > demangled names numerous times during a single GDB session, or (b)
> > > > demangle entirely different, large sets of names each time I reload
> > > > the symbol tables. Yeah, I know, it's not pretty, but again I am hoping
> > > > it will ensure that demangled names behave until the next interation of
> > > > symtab modifications allow an entirely different strategy.
> > >
> > > I'm not sure what others will think of this interim measure. I don't
> > > like it much, though.
> >
> > Under what circumstances does finding an objfile by the minsym's BFD
> > section not work? That minsym must have come from somewhere. Do we
> > produce minsyms whose sections are unset, for some reason?
>
> Well, (A) it's inefficient, since there's no pointer from the BFD
> section to the GDB section; (B) I don't know whether we produce minsyms
> whose sections are unset; (C) I really want to remove the section
> pointer from general_symbol_info someday, and this will make that
> harder. I've abandoned that project for the moment while I catch up on
> other projects, but I'll be back to it :)
Yes, (A) was apparent; by asking correctness questions I didn't mean
to imply I thought efficiency was a done deal. :) (B) is the real
question; if someone knows that we do produce such symbols, I'd love
to hear about it. (C) is good to know, too.
I have to say, I think our allocation rules are hairy enough already.
If there is some better solution on the horizon for lazy demangling's
allocation, I am relucantant to put in complex and slow mechanisms,
even temporarily. It's a step backwards, justified by work that isn't
even scheduled.
Paul, how critical is this to the intent of your change? I haven't
reviewed it.