This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
[pushed] unbreak infcalls
- From: Pedro Alves <palves at redhat dot com>
- To: gdb-patches at sourceware dot org
- Date: Thu, 29 May 2014 17:33:24 +0100
- Subject: [pushed] unbreak infcalls
- Authentication-results: sourceware.org; auth=none
I managed to miss an interaction between the recent *running patch,
and target-async, which resulted in infcalls being completely broken
on GNU/Linux and remote targets (that is, the async-capable targets).
Temporary breakpoint 1, main () at threads.c:35
35 long i = 0;
(gdb) p malloc (0)
The program being debugged stopped while in a function called from GDB.
Evaluation of the expression containing the function
(malloc) will be abandoned.
When the function is done executing, GDB will silently stop.
(gdb) p malloc (0)
Program received signal SIGSEGV, Segmentation fault.
0x000000000058d7e8 in get_regcache_aspace (regcache=0x0) at ../../src/gdb/regcache.c:281
281 return regcache->aspace;
(top-gdb)
The issue is that when running an infcall, the thread is no longer
marked as running, so run_inferior_call is not calling
wait_for_inferior anymore.
Fix this by doing what the comment actually says we do:
"Do here what `proceed' itself does in sync mode."
And proceed doesn't check whether the target is running.
I notice this is broken in case of the early return in proceed, but we
were broken before in that case anyway, because run_inferior_call will
think the call actually ran. Seems like we should make proceed have a
boolean return, and go through all callers making use of it, if
necessary.
But for now, just fix the regression.
Tested on x86_64 Fedora 20.
gdb/
2014-05-29 Pedro Alves <palves@redhat.com>
* infcall.c (run_inferior_call): Don't check whether the current
thread is running after the proceed call.
---
gdb/ChangeLog | 5 +++++
gdb/infcall.c | 2 +-
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/gdb/ChangeLog b/gdb/ChangeLog
index 341698b..3225ceb 100644
--- a/gdb/ChangeLog
+++ b/gdb/ChangeLog
@@ -1,4 +1,9 @@
2014-05-29 Pedro Alves <palves@redhat.com>
+
+ * infcall.c (run_inferior_call): Don't check whether the current
+ thread is running after the proceed call.
+
+2014-05-29 Pedro Alves <palves@redhat.com>
Tom Tromey <tromey@redhat.com>
* NEWS: Mention "maint set target-async", "set mi-async", and that
diff --git a/gdb/infcall.c b/gdb/infcall.c
index 9a85958..685b8a4 100644
--- a/gdb/infcall.c
+++ b/gdb/infcall.c
@@ -407,7 +407,7 @@ run_inferior_call (struct thread_info *call_thread, CORE_ADDR real_pc)
/* Inferior function calls are always synchronous, even if the
target supports asynchronous execution. Do here what
`proceed' itself does in sync mode. */
- if (target_can_async_p () && is_running (inferior_ptid))
+ if (target_can_async_p ())
{
wait_for_inferior ();
normal_stop ();
--
1.9.0