From: Daniel Jacobowitz <drow@false.org>
To: Jim Blandy <jimb@redhat.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFA/dwarf] Eliminate dwarf2_tmp_obstack
Date: Mon, 19 Apr 2004 13:21:00 -0000 [thread overview]
Message-ID: <20040419132113.GB13666@nevyn.them.org> (raw)
In-Reply-To: <vt2hdvgxyt5.fsf@zenia.home>
On Mon, Apr 19, 2004 at 01:32:38AM -0500, Jim Blandy wrote:
>
> Daniel Jacobowitz <drow@false.org> writes:
> > dwarf2_tmp_obstack serves as a general purpose dumping ground. After my
> > previous patches, there are only two things left on it: the linked list we
> > use to fudge GCC 2.95 line number tables (some day soon I think this hack
> > should go away; it was primarily for the benefit of the testsuite, and was
> > fixed at least as of GCC 3.1), and the block structures created in
> > read_attribute_value.
> >
> > Both of these are clearly associated with a particular compilation unit.
> > If we put them on the comp_unit_obstack, then we don't have any need for
> > the global obstack any more.
> >
> > Since my following patches change the lifetimes of individual CUs, I felt
> > this was a worthwhile cleanup. OK?
>
> You need to fix up the comments above free_stack_comp_unit; it's no
> longer "only used during partial symbol processing".
Will do.
> I'd like free_stack_comp_unit renamed to free_comp_unit_obstack, so
> that when I search for comp_unit_obstack, I'll also run into the calls
> to make_cleanup that will free it.
>
> Otherwise, looks good.
Mind if I don't do this one? Right now, we have:
/* This cleanup function is passed the address of a dwarf2_cu on the stack
when we're finished with it. We can't free the pointer itself, but
release any associated storage.
But on the intercu branch, it says:
/* This cleanup function is passed the address of a dwarf2_cu on the stack
when we're finished with it. We can't free the pointer itself, but be
sure to unlink it from the cache. Also release any associated storage
and perform cache maintenance.
The most important thing the function does is remove a pointer from the
objfile's compilation unit cache to the stack frame of the function
that's ending.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
next prev parent reply other threads:[~2004-04-19 13:21 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-04-19 3:17 Daniel Jacobowitz
2004-04-19 5:55 ` Eli Zaretskii
2004-04-19 12:42 ` Jim Blandy
2004-04-19 13:18 ` Daniel Jacobowitz
2004-04-19 12:42 ` Jim Blandy
2004-04-19 13:21 ` Daniel Jacobowitz [this message]
2004-04-19 18:15 ` Jim Blandy
2004-04-19 23:30 ` Daniel Jacobowitz
2004-04-19 18:25 Michael Elizabeth Chastain
2004-04-19 18:27 ` Daniel Jacobowitz
2004-04-19 18:33 Michael Elizabeth Chastain
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040419132113.GB13666@nevyn.them.org \
--to=drow@false.org \
--cc=gdb-patches@sources.redhat.com \
--cc=jimb@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox