This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA] dummy frame handling cleanup, plus inferior fun call signal handling improvement
- From: Pedro Alves <pedro at codesourcery dot com>
- To: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- Cc: Doug Evans <dje at google dot com>, gdb-patches at sourceware dot org
- Date: Thu, 4 Dec 2008 15:53:37 +0000
- Subject: Re: [RFA] dummy frame handling cleanup, plus inferior fun call signal handling improvement
- References: <200812041531.mB4FVEKt030233@d12av02.megacenter.de.ibm.com>
On Thursday 04 December 2008 15:31:14, Ulrich Weigand wrote:
> Hmmm, that's not quite what what the code actually does. ?The state is also
> restored if some error is thrown during the proceed call, for example.
> I'm not sure whether this is really the right thing to do ...
And it *can happen* (although it should be rare) that when the exception is
thrown, inferior_ptid is set to a different ptid the infcall started
with (say, while you're handling a thread specific breakpoint hitting the wrong thread),
so, the cleanup can still write the context back, the wrong thread. Threading
and infcalls failing is a clear mess.
Thinking out loud, I wonder if we shouldn't be storing the
thread state prior to the infcall in struct thread_info itself, and
leave out in a separate object only the session state (what doesn't make
sense to have in thread_info). So, a thread_info would hold two objects
of the same type, something like, thread_info->infrun_state,
thread_info->stored_infrun_state.
If a thread exits, (or the whole inferior) while doing the infcall, the
state is automatically deleted/discarded when you delete the thread.
If an exception is thrown, you'd go through all threads and set the
infrun_state from the stored_infrun_state, if there's any.
--
Pedro Alves