This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFA] Introduce notion of "search name"


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?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]