From: Sergio Durigan Junior <sergiodj@redhat.com>
To: "Pierre Muller" <pierre.muller@ics-cnrs.unistra.fr>
Cc: <gdb-patches@sourceware.org>
Subject: Re: [patch] Fix crash in read_pe_exported_syms
Date: Sun, 03 Mar 2013 23:06:00 -0000 [thread overview]
Message-ID: <m31ubwytg9.fsf@redhat.com> (raw)
In-Reply-To: <00e101ce175a$f921f210$eb65d630$@muller@ics-cnrs.unistra.fr> (Pierre Muller's message of "Sat, 2 Mar 2013 16:31:11 +0100")
Hi Pierre,
On Saturday, March 02 2013, Pierre Muller wrote:
> I still didn't really get a fully correct picture of the correct way to handle
> the cleanups, but I think that your analysis is correct and that this patch should
> be approved by a global maintainer.
Not sure if you meant that you want to understand how cleanups work, but
anyway...
Think of cleanups as a stack. When you call `make_cleanup', you are
asking for a new operation to be put in the stack, and you receive the
pointer to the last operation in that stack (before yours, which becomes
the new head). When you call `do_cleanups', you are telling GDB to
iterate over the stack in reverse and execute each operation until the
one you provide as the argument of the function. `discard_cleanups'
does a similar job, but instead of executing each operation, it discards
them.
When you know that you will have many cleanups and don't want to keep
track of each one individually, you can use the same trick as
`read_pe_exported_syms': you register a dummy cleanup (null_cleanup,
which does nothing) and then start calling `make_cleanup' without caring
about its return value. Then, when the time comes (e.g., you are about
to return from the function), you can either call `do_cleanups' or
`discard_cleanups' using as the argument the one you received in the
first call to `make_cleanup' with a dummy cleanup, and you'll be sure
that all the cleanup chain will be executed or discarded up to the point
where you started your function.
Sorry if you already knew all that and I misunderstood your question
:-).
> PS: It would also be better that this goes in before branching 7.6!
I agree.
--
Sergio
next prev parent reply other threads:[~2013-03-03 23:06 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-02 11:02 Corinna Vinschen
2013-03-02 15:31 ` Pierre Muller
2013-03-03 23:06 ` Sergio Durigan Junior [this message]
2013-03-03 22:53 ` Sergio Durigan Junior
2013-03-04 13:24 ` Pedro Alves
2013-03-04 14:35 ` Corinna Vinschen
2013-03-04 14:41 ` Joel Brobecker
2013-03-04 15:10 ` Corinna Vinschen
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=m31ubwytg9.fsf@redhat.com \
--to=sergiodj@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=pierre.muller@ics-cnrs.unistra.fr \
/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