This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFC/RFA] Per-objfile data mechanism
- From: David Carlton <carlton at kealia dot com>
- To: Mark Kettenis <kettenis at chello dot nl>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Mon, 11 Aug 2003 08:45:17 -0700
- Subject: Re: [RFC/RFA] Per-objfile data mechanism
- References: <200307131717.h6DHH425098569@elgar.kettenis.dyndns.org><20030715161729.GA32437@nevyn.them.org><yf24r1nn3c0.fsf@hawaii.kealia.com><200308101903.h7AJ32Bx079942@elgar.kettenis.dyndns.org>
On Sun, 10 Aug 2003 21:03:02 +0200 (CEST), Mark Kettenis <kettenis@chello.nl> said:
> From: David Carlton <carlton@kealia.com>
> Date: Tue, 15 Jul 2003 09:48:31 -0700
>> I was also going to write, based on a cursory misreading of Mark's
>> patch, that it simplified memory management in some circumstances,
>> but now that I look at it more closely, I think I just misread the
>> patch. (I may still be misreading the patch; my head is spinning
>> with other things.) Would it be possible/beneficial to modify the
>> mechanism to provide an optional per-datum cleanup function as
>> well?
> I quite deliberately left per-datum initializers and destructors out
> to encourage the use of the per-objfile obstacks. But they can
> always be added if they're needed.
The concrete reason for that suggestion is that I have a patch
awaiting review adding some per-objfile data that consists of an
expanding hash table; that can't be handled with an obstack. In
general, I get the feeling that we're moving a bit more to data
structures that are less obstack friendly, but who knows. Having said
that:
> So what's the final verdict. Should my patch go in, or do people
> have concrete ideas about necessary improvements or alternative
> implementations?
I certainly wouldn't want to stand in the way of putting it in now: if
we do decide we want to add per-datum cleanup mechanisms to your
patch, we can do it just as easily after the patch has been applied as
before the patch has been applied.
David Carlton
carlton@kealia.com