This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Patch to generate correct dwarf2 debugging info
- To: Will Cohen <wcohen at redhat dot com>
- Subject: Re: Patch to generate correct dwarf2 debugging info
- From: Jeffrey A Law <law at cygnus dot com>
- Date: Thu, 14 Sep 2000 12:05:17 -0600
- cc: gcc-patches at gcc dot gnu dot org
- Reply-To: law at cygnus dot com
In message <39C0F3C8.47F8C429@redhat.com>you write:
> > If there's no good way to get a handle on when to free the information,
> > then you might consider using the garbage collector to allocate space for
> > you.
>
> I was following what I saw in other places in the dwarf2out.c file.
> There are a number of other xmalloc function calls that have the
> same purpose as the patch.
Understood, but I would consider those calls broken too :-) Just because
existing code does something dumb (leak memory) doesn't mean new code should
do something dumb.
> Where can I find information about using garbage collection?
It's pretty simple. We have the capability to allocate space that will be
reclaimed by a garbage collector that (typically) runs between major passes
of the compiler.
So if you have information that you want to allocate for the duration of a
pass (ie, it is not live across a call to the collector), then you can just
allocate it with one of the ggc_* routines and use it however you need and
ignore deallocation.
So the biggest question is can we call into the collector after you've
allocated space for ARRAY, but before it's used by output_die?
The collector is triggered by ggc_collect calls in toplev.c and selected
other locations.
To allocate collected memory you use ggc_alloc or ggc_alloc_cleared.
jeff