From: dje@google.com (Doug Evans)
To: gdb@sourceware.org
Subject: call_function_by_hand doesn't restore target async?
Date: Thu, 04 Dec 2008 20:19:00 -0000 [thread overview]
Message-ID: <20081204201837.29DF91C7A10@localhost> (raw)
Hi.
Should there be a cleanup to restore target_async_mask?
call_function_by_hand has this:
{
struct cleanup *old_cleanups = make_cleanup (null_cleanup, 0);
struct cleanup *old_cleanups2;
int saved_async = 0;
struct thread_info *tp = inferior_thread ();
/* Save this thread's ptid, we need it later but the thread
may have exited. */
this_thread_ptid = tp->ptid;
/* If all error()s out of proceed ended up calling normal_stop
(and perhaps they should; it already does in the special case
of error out of resume()), then we wouldn't need this. */
make_cleanup (breakpoint_auto_delete_contents, NULL);
disable_watchpoints_before_interactive_call_start ();
tp->proceed_to_finish = 1; /* We want stop_registers, please... */
if (target_can_async_p ())
saved_async = target_async_mask (0);
old_cleanups2 = make_cleanup_restore_integer (&suppress_resume_observer);
suppress_resume_observer = 1;
make_cleanup_restore_integer (&suppress_stop_observer);
suppress_stop_observer = 1;
proceed (real_pc, TARGET_SIGNAL_0, 0);
do_cleanups (old_cleanups2);
if (saved_async)
target_async_mask (saved_async);
enable_watchpoints_after_interactive_call_stop ();
discard_cleanups (old_cleanups);
}
target.h has this:
/* This is to be used ONLY within call_function_by_hand(). It provides
a workaround, to have inferior function calls done in sychronous
mode, even though the target is asynchronous. After
target_async_mask(0) is called, calls to target_can_async_p() will
return FALSE , so that target_resume() will not try to start the
target asynchronously. After the inferior stops, we IMMEDIATELY
restore the previous nature of the target, by calling
target_async_mask(1). After that, target_can_async_p() will return
TRUE. ANY OTHER USE OF THIS FEATURE IS DEPRECATED.
FIXME ezannoni 1999-12-13: we won't need this once we move
the turning async on and off to the single execution commands,
from where it is done currently, in remote_resume(). */
#define target_async_mask(MASK) \
(current_target.to_async_mask (MASK))
I don't see any other calls to target_async_mask. Given that it's
only to be used by call_function_by_hand that's understandable,
but then I don't understand how target_async_mask gets restored
if proceed errors out.
I'll add a fix to my dummy-frames patch if there's a bug here.
If there isn't a bug I'll at least add a comment. :-)
[and I'll need to start breaking it into a set of smaller patches ...]
next reply other threads:[~2008-12-04 20:19 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-04 20:19 Doug Evans [this message]
2008-12-04 21:23 ` Pedro Alves
2008-12-04 21:33 ` Pedro Alves
2008-12-04 21:37 ` Doug Evans
2008-12-04 22:14 ` Pedro Alves
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=20081204201837.29DF91C7A10@localhost \
--to=dje@google.com \
--cc=gdb@sourceware.org \
/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