Pedro Alves [Thu, 6 Aug 2015 14:02:26 +0000 (15:02 +0100)]
gdbserver: move_out_of_jump_pad_callback misses switching current thread
While hacking on the fix for PR threads/18600 (Threads left stopped
after fork+thread spawn), I once saw its test (fork-plus-threads.exp)
FAIL against gdbserver because move_out_of_jump_pad_callback has a
gdb_breakpoint_here call, and the caller isn't making sure the current
thread points to the right thread. In the case I saw, the current
thread pointed to the wrong process, so gdb_breakpoint_here returned
the wrong answer. Unfortunately I didn't save logs. Still, seems
obvious enough and it should fix a potential occasional racy FAIL.
Tested on x86_64 Fedora 20.
gdb/gdbserver/ChangeLog:
2015-08-06 Pedro Alves <palves@redhat.com>
* linux-low.c (move_out_of_jump_pad_callback): Temporarily switch
the current thread.
Pedro Alves [Thu, 6 Aug 2015 12:38:56 +0000 (13:38 +0100)]
Fix gdbserver --debug issues caught by Valgrind
Running gdbserver --debug under Valgrind shows:
==4803== Invalid read of size 4
==4803== at 0x432B62: linux_write_memory (linux-low.c:5320)
==4803== by 0x4143F7: write_inferior_memory (target.c:83)
==4803== by 0x415895: remove_memory_breakpoint (mem-break.c:362)
==4803== by 0x432EF5: linux_remove_point (linux-low.c:5460)
==4803== by 0x416319: delete_raw_breakpoint (mem-break.c:802)
==4803== by 0x4163F3: release_breakpoint (mem-break.c:842)
==4803== by 0x416477: delete_breakpoint_1 (mem-break.c:869)
==4803== by 0x4164EF: delete_breakpoint (mem-break.c:891)
==4803== by 0x416843: delete_gdb_breakpoint_1 (mem-break.c:1069)
==4803== by 0x4168D8: delete_gdb_breakpoint (mem-break.c:1098)
==4803== by 0x4134E3: process_serial_event (server.c:4051)
==4803== by 0x4138E4: handle_serial_event (server.c:4196)
==4803== Address 0x4c6b930 is 0 bytes inside a block of size 1 alloc'd
==4803== at 0x4A0645D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==4803== by 0x4240C6: xmalloc (common-utils.c:43)
==4803== by 0x41439C: write_inferior_memory (target.c:80)
==4803== by 0x415895: remove_memory_breakpoint (mem-break.c:362)
==4803== by 0x432EF5: linux_remove_point (linux-low.c:5460)
==4803== by 0x416319: delete_raw_breakpoint (mem-break.c:802)
==4803== by 0x4163F3: release_breakpoint (mem-break.c:842)
==4803== by 0x416477: delete_breakpoint_1 (mem-break.c:869)
==4803== by 0x4164EF: delete_breakpoint (mem-break.c:891)
==4803== by 0x416843: delete_gdb_breakpoint_1 (mem-break.c:1069)
==4803== by 0x4168D8: delete_gdb_breakpoint (mem-break.c:1098)
==4803== by 0x4134E3: process_serial_event (server.c:4051)
==4803==
And:
==7272== Conditional jump or move depends on uninitialised value(s)
==7272== at 0x3615E48361: vfprintf (vfprintf.c:1634)
==7272== by 0x414E89: debug_vprintf (debug.c:60)
==7272== by 0x42800A: debug_printf (common-debug.c:35)
==7272== by 0x43937B: my_waitpid (linux-waitpid.c:149)
==7272== by 0x42D740: linux_wait_for_event_filtered (linux-low.c:2441)
==7272== by 0x42DADA: linux_wait_for_event (linux-low.c:2552)
==7272== by 0x42E165: linux_wait_1 (linux-low.c:2860)
==7272== by 0x42F5D8: linux_wait (linux-low.c:3453)
==7272== by 0x4144A4: mywait (target.c:107)
==7272== by 0x413969: handle_target_event (server.c:4214)
==7272== by 0x41A1A6: handle_file_event (event-loop.c:429)
==7272== by 0x41996D: process_event (event-loop.c:184)
gdb/ChangeLog:
2015-08-06 Pedro Alves <palves@redhat.com>
* nat/linux-waitpid.c (my_waitpid): Only print *status if waitpid
returned > 0.
gdb/gdbserver/ChangeLog:
2015-08-06 Pedro Alves <palves@redhat.com>
* linux-low.c (linux_write_memory): Rewrite debug output to avoid
reading beyond the passed in buffer length.
This adds a test that has a multithreaded program have several threads
continuously fork, while another thread continuously steps over a
breakpoint.
This exposes several intertwined issues, which this patch addresses:
- When we're stopping and suspending threads, some thread may fork,
and we missed setting its suspend count to 1, like we do when a new
clone/thread is detected. When we next unsuspend threads, the fork
child's suspend count goes below 0, which is bogus and fails an
assertion.
- If a step-over is cancelled because a signal arrives, but then gdb
is not interested in the signal, we pass the signal straight back
to the inferior. However, we miss that we need to re-increment the
suspend counts of all other threads that had been paused for the
step-over. As a result, other threads indefinitely end up stuck
stopped.
- If a detach request comes in just while gdbserver is handling a
step-over (in the test at hand, this is GDB detaching the fork
child), gdbserver internal errors in stabilize_thread's helpers,
which assert that all thread's suspend counts are 0 (otherwise we
wouldn't be able to move threads out of the jump pads). The
suspend counts aren't 0 while a step-over is in progress, because
all threads but the one stepping past the breakpoint must remain
paused until the step-over finishes and the breakpoint can be
reinserted.
- Occasionally, we see "BAD - reinserting but not stepping." being
output (from within linux_resume_one_lwp_throw). That was because
GDB pokes memory while gdbserver is busy with a step-over, and that
suspends threads, and then re-resumes them with proceed_one_lwp,
which missed another reason to tell linux_resume_one_lwp that the
thread should be set back to stepping.
- In a couple places, we were resuming threads that are meant to be
suspended. E.g., when a vCont;c/s request for thread B comes in
just while gdbserver is stepping thread A past a breakpoint. The
resume for thread B must be deferred until the step-over finishes.
- The test runs with both "set detach-on-fork" on and off. When off,
it exercises the case of GDB detaching the fork child explicitly.
When on, it exercises the case of gdb resuming the child
explicitly. In the "off" case, gdb seems to exponentially become
slower as new inferiors are created. This is _very_ noticeable as
with only 100 inferiors gdb is crawling already, which makes the
test take quite a bit to run. For that reason, I've disabled the
"off" variant for now.
gdb/ChangeLog:
2015-08-06 Pedro Alves <palves@redhat.com>
* target/waitstatus.h (enum target_stop_reason)
<TARGET_STOPPED_BY_SINGLE_STEP>: New value.
gdb/gdbserver/ChangeLog:
2015-08-06 Pedro Alves <palves@redhat.com>
* linux-low.c (handle_extended_wait): Set the fork child's suspend
count if stopping and suspending threads.
(check_stopped_by_breakpoint): If stopped by trace, set the LWP's
stop reason to TARGET_STOPPED_BY_SINGLE_STEP.
(linux_detach): Complete an ongoing step-over.
(lwp_suspended_inc, lwp_suspended_decr): New functions. Use
throughout.
(resume_stopped_resumed_lwps): Don't resume a suspended thread.
(linux_wait_1): If passing a signal to the inferior after
finishing a step-over, unsuspend and re-resume all lwps. If we
see a single-step event but the thread should be continuing, don't
pass the trap to gdb.
(stuck_in_jump_pad_callback, move_out_of_jump_pad_callback): Use
internal_error instead of gdb_assert.
(enqueue_pending_signal): New function.
(check_ptrace_stopped_lwp_gone): Add debug output.
(start_step_over): Use internal_error instead of gdb_assert.
(complete_ongoing_step_over): New function.
(linux_resume_one_thread): Don't resume a suspended thread.
(proceed_one_lwp): If the LWP is stepping over a breakpoint, reset
it stepping.
gdb/testsuite/ChangeLog:
2015-08-06 Pedro Alves <palves@redhat.com>
* gdb.threads/forking-threads-plus-breakpoint.exp: New file.
* gdb.threads/forking-threads-plus-breakpoint.c: New file.
Pedro Alves [Thu, 6 Aug 2015 11:07:09 +0000 (12:07 +0100)]
Linux gdbserver confused when event randomization picks process exit event
The tail end of linux_wait_1 isn't expecting that the select_event_lwp
machinery can pick a whole-process exit event to report to GDB. When
that happens, both gdb and gdbserver end up quite confused:
[Thread 24983.24983] #3 stopped.
0x0000003615ebc7cc in __libc_fork () at ../nptl/sysdeps/unix/sysv/linux/fork.c:130
130 pid = ARCH_FORK ();
[New Thread 24984.24984]
Error in re-setting breakpoint -16: PC register is not available
Error in re-setting breakpoint -17: PC register is not available
Error in re-setting breakpoint -18: PC register is not available
Error in re-setting breakpoint -19: PC register is not available
Error in re-setting breakpoint -24: PC register is not available
Error in re-setting breakpoint -25: PC register is not available
Error in re-setting breakpoint -26: PC register is not available
Error in re-setting breakpoint -27: PC register is not available
Error in re-setting breakpoint -28: PC register is not available
Error in re-setting breakpoint -29: PC register is not available
Error in re-setting breakpoint -30: PC register is not available
PC register is not available
(gdb)
gdb/gdbserver/ChangeLog:
2015-08-06 Pedro Alves <palves@redhat.com>
* linux-low.c (add_lwp): Set waitstatus to TARGET_WAITKIND_IGNORE.
(linux_thread_alive): Use lwp_is_marked_dead.
(extended_event_reported): Delete.
(linux_wait_1): Check if waitstatus is TARGET_WAITKIND_IGNORE
instead of extended_event_reported.
(mark_lwp_dead): Don't set the 'dead' flag. Store the waitstatus
as well.
(lwp_is_marked_dead): New function.
(lwp_running): Use lwp_is_marked_dead.
* linux-low.h: Delete 'dead' field, and update 'waitstatus's
comment.
Pedro Alves [Thu, 6 Aug 2015 11:07:09 +0000 (12:07 +0100)]
Linux gdbserver fork event debug output
The "extended event with waitstatus" debug output is unreachable, as
it is guarded by "if (!report_to_gdb)". If extended_event_reported is
true, then so is report_to_gdb. Move it to where we print why we're
reporting an event to GDB.
Also, the debug output currently tries to print the wrong struct
target_waitstatus.
gdb/gdbserver/ChangeLog:
2015-08-06 Pedro Alves <palves@redhat.com>
* linux-low.c (linux_wait_1): Move fork event output out of the
!report_to_gdb check. Pass event_child->waitstatus to
target_waitstatus_to_string instead of ourstatus.
Pedro Alves [Wed, 5 Aug 2015 19:09:28 +0000 (20:09 +0100)]
stepping is disturbed by setjmp/longjmp | try/catch in other threads
At https://sourceware.org/ml/gdb-patches/2015-08/msg00097.html, Joel
observed that trying to next/step a program on GNU/Linux sometimes
results in the following failed assertion:
What happened is that, during the "next" operation, GDB hit a
longjmp/exception/step-resume breakpoint but failed to see that this
breakpoint was set for a different thread than the one being stepped.
Joel's detailed analysis follows:
More precisely, at the end of the "start" command, we are stopped at
the start of function Main in main.adb; there are 4 threads in total,
and we are in the main thread (which is thread 1):
(gdb) info thread
Id Target Id Frame
4 Thread 0xb7a56ba0 (LWP 28379) 0xffffe410 in __kernel_vsyscall ()
3 Thread 0xb7c5aba0 (LWP 28378) 0xffffe410 in __kernel_vsyscall ()
2 Thread 0xb7e5eba0 (LWP 28377) 0xffffe410 in __kernel_vsyscall ()
* 1 Thread 0xb7ea18c0 (LWP 28370) main () at /[...]/main.adb:57
All the logs below reference Thread ID/LWP, but it'll be easier to
talk about the threads by GDB thread number. For instance, thread 1
is LWP 28370 while thread 3 is LWP 28378. So, the explanations below
translate the LWPs into thread numbers.
Back to what happens while we are trying to "next' our program:
(gdb) n
infrun: clear_proceed_status_thread (Thread 0xb7a56ba0 (LWP 28379))
infrun: clear_proceed_status_thread (Thread 0xb7c5aba0 (LWP 28378))
infrun: clear_proceed_status_thread (Thread 0xb7e5eba0 (LWP 28377))
infrun: clear_proceed_status_thread (Thread 0xb7ea18c0 (LWP 28370))
infrun: proceed (addr=0xffffffff, signal=GDB_SIGNAL_DEFAULT)
infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=0, current thread [Thread 0xb7ea18c0 (LWP 28370)] at 0x805451e
infrun: target_wait (-1.0.0, status) =
infrun: 28370.28370.0 [Thread 0xb7ea18c0 (LWP 28370)],
infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x8054523
We've resumed thread 1 (LWP 28370), and received in return a signal
that the same thread stopped slightly further. It's still in the
range of instructions for the line of source we started the "next"
from, as evidenced by the following trace...
infrun: stepping inside range [0x805451e-0x8054531]
... and thus, we decide to continue stepping the same thread:
infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=0, current thread [Thread 0xb7ea18c0 (LWP 28370)] at 0x8054523
infrun: prepare_to_wait
That's when we get an event from a different thread (thread 3)...
... which we find to be at the address where we set a breakpoint on
"the unwinder debug hook" (namely "_Unwind_DebugHook"). But GDB fails
to notice that the breakpoint was inserted for thread 1 only, and so
decides to handle it as...
infrun: BPSTAT_WHAT_SET_LONGJMP_RESUME
... and inserts a breakpoint at the corresponding resume address, as
evidenced by this the next log:
That breakpoint seems innocent right now, but will play a role fairly
quickly. But for now, GDB has inserted the exception-resume
breakpoint, and needs to single-step thread 3 past the breakpoint it
just hit. Thus, it temporarily disables the exception breakpoint, and
requests a step of that thread:
infrun: skipping breakpoint: stepping past insn at: 0x80782d0
infrun: skipping breakpoint: stepping past insn at: 0x80782d0
infrun: skipping breakpoint: stepping past insn at: 0x80782d0
infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=1, current thread [Thread 0xb7c5aba0 (LWP 28378)] at 0x80782d0
infrun: prepare_to_wait
We then get a notification, still from thread 3, that it's now past
that breakpoint...
... so we can resume what we were doing before, which is single-stepping
thread 1 until we get to a new line of code:
infrun: switching back to stepped thread
infrun: Switching context from Thread 0xb7c5aba0 (LWP 28378) to Thread 0xb7ea18c0 (LWP 28370)
infrun: expected thread still hasn't advanced
infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=0, current thread [Thread 0xb7ea18c0 (LWP 28370)] at 0x8054523
The "resume" log above shows that we're resuming thread 1 from where
we left off (0x8054523). We get one more stop at 0x8054529, which is
still inside our stepping range so we go again. That's when we get
the following event, from thread 3:
Now the stop_pc address is interesting, because it's the address of
"exception resume" breakpoint...
infrun: context switch
infrun: Switching context from Thread 0xb7ea18c0 (LWP 28370) to Thread 0xb7c5aba0 (LWP 28378)
infrun: BPSTAT_WHAT_CLEAR_LONGJMP_RESUME
... and since that location is at a different line of code, this is
where it decides the "next" operation should stop:
infrun: stop_waiting
[Switching to Thread 0xb7c5aba0 (LWP 28378)]
0x080542a2 in inte_tache_rt.ttache_rt (
<_task>=0x80968ec <inte_tache_rt_inst.tache2>)
at /[...]/inte_tache_rt.adb:54
54 end loop;
However, what GDB should have noticed earlier that the exception
breakpoint we hit was for a different thread, thus should have
single-stepped that thread out of the breakpoint _without_ inserting
the exception-return breakpoint, and then resumed the single-stepping
of the initial thread (thread 1) until that thread stepped out of its
stepping range.
This is what this patch does, and after applying it, GDB now correctly
stops on the next line of code.
The patch adds a C++ test that exercises this, both for setjmp/longjmp
and exception breakpoints. With an unpatched GDB it shows:
(gdb) next
[Switching to Thread 22445.22455]
thread_try_catch (arg=0x0) at /home/pedro/gdb/mygit/build/../src/gdb/testsuite/gdb.threads/next-other-thr-longjmp.c:59
59 catch (...)
(gdb) FAIL: gdb.threads/next-other-thr-longjmp.exp: next to line 1
next
/home/pedro/gdb/mygit/build/../src/gdb/infrun.c:4865: internal-error: process_event_stop_test: Assertion `ecs->event_thread->control.exception_resume_breakpoint != NULL' fa
iled.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) FAIL: gdb.threads/next-other-thr-longjmp.exp: next to line 2 (GDB internal error)
Resyncing due to internal error.
n
Tested on x86_64-linux, no regressions.
gdb/ChangeLog:
2015-08-05 Pedro Alves <palves@redhat.com>
Joel Brobecker <brobecker@adacore.com>
* breakpoint.c (bpstat_what) <bp_longjmp, bp_longjmp_call_dummy>
<bp_exception, bp_longjmp_resume, bp_exception_resume>: Handle the
case where BS->STOP is not set.
gdb/testsuite/ChangeLog:
2015-08-05 Pedro Alves <palves@redhat.com>
* gdb.threads/next-while-other-thread-longjmps.c: New file.
* gdb.threads/next-while-other-thread-longjmps.exp: New file.
[Thread 28185.28185] #20 stopped.
Cannot remove breakpoints because program is no longer writable.
Further execution is probably impossible.
[Inferior 11 (process 28185) exited normally]
[Inferior 1 (process 28091) exited normally]
PASS: gdb.threads/fork-plus-threads.exp: reached breakpoint
info threads
No threads.
(gdb) PASS: gdb.threads/fork-plus-threads.exp: no threads left
info inferiors
Num Description Executable
* 1 <null> /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.threads/fork-plus-threads
(gdb) PASS: gdb.threads/fork-plus-threads.exp: only inferior 1 left
All the "[Thread FOO] #NN stopped." above are bogus, as well as the
"Cannot remove breakpoints because program is no longer writable.",
which is a consequence.
The problem is that when we intercept a fork event, we should report
the event for the parent, only, and leave the child stopped, but not
report its stop event. GDB later decides whether to follow the parent
or the child. But because handle_extended_wait does not set the
child's last_status.kind to TARGET_WAITKIND_STOPPED, a
stop_all_threads/unstop_all_lwps sequence (e.g., from trying to access
memory) by mistake ends up queueing a SIGSTOP on the child, resuming
it, and then when that SIGSTOP is intercepted, because the LWP has
last_resume_kind set to resume_stop, gdbserver reports the stop to
GDB, as GDB_SIGNAL_0:
...
>>>> entering unstop_all_lwps
unstopping all lwps
proceed_one_lwp: lwp 1600
client wants LWP to remain 1600 stopped
proceed_one_lwp: lwp 1828
Client wants LWP 1828 to stop. Making sure it has a SIGSTOP pending
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Sending sigstop to lwp 1828
pc is 0x3615ebc7cc
Resuming lwp 1828 (continue, signal 0, stop expected)
continue from pc 0x3615ebc7cc
unstop_all_lwps done
sigchld_handler
<<<< exiting unstop_all_lwps
handling possible target event
>>>> entering linux_wait_1
linux_wait_1: [<all threads>]
my_waitpid (-1, 0x40000001)
my_waitpid (-1, 0x1): status(137f), 1828
LWFE: waitpid(-1, ...) returned 1828, ERRNO-OK
LLW: waitpid 1828 received Stopped (signal) (stopped)
pc is 0x3615ebc7cc
Expected stop.
LLW: resume_stop SIGSTOP caught for LWP 1828.1828.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
...
linux_wait_1 ret = LWP 1828.1828, 1, 0
<<<< exiting linux_wait_1
Writing resume reply for LWP 1828.1828:1
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Tested on x86_64 Fedora 20, extended-remote.
gdb/gdbserver/ChangeLog:
2015-07-30 Pedro Alves <palves@redhat.com>
* linux-low.c (handle_extended_wait): Set the child's last
reported status to TARGET_WAITKIND_STOPPED.
Pedro Alves [Thu, 30 Jul 2015 17:55:36 +0000 (18:55 +0100)]
PR threads/18600: Inferiors left around after fork+thread spawn
The new gdb.threads/fork-plus-threads.exp test exposes one more
problem. When one types "info inferiors" after running the program,
one see's a couple inferior left still, while there should only be
inferior #1 left. E.g.:
(gdb) info inferiors
Num Description Executable
4 process 8393 /home/pedro/bugs/src/test
2 process 8388 /home/pedro/bugs/src/test
* 1 <null> /home/pedro/bugs/src/test
(gdb) info threads
Calling prune_inferiors() manually at this point (from a top gdb) does
not remove them, because they still have inf->pid != 0 (while they
shouldn't). This suggests that we never mourned those inferiors.
Enabling logs (master + previous patch) we see:
...
WL: waitpid Thread 0x7ffff7fc2740 (LWP 9513) received Trace/breakpoint trap (stopped)
WL: Handling extended status 0x03057f
LHEW: Got clone event from LWP 9513, new child is LWP 9579
[New Thread 0x7ffff37b8700 (LWP 9579)]
WL: waitpid Thread 0x7ffff7fc2740 (LWP 9508) received 0 (exited)
WL: Thread 0x7ffff7fc2740 (LWP 9508) exited.
^^^^^^^^
[Thread 0x7ffff7fc2740 (LWP 9508) exited]
WL: waitpid Thread 0x7ffff7fc2740 (LWP 9499) received 0 (exited)
WL: Thread 0x7ffff7fc2740 (LWP 9499) exited.
[Thread 0x7ffff7fc2740 (LWP 9499) exited]
RSRL: resuming stopped-resumed LWP Thread 0x7ffff37b8700 (LWP 9579) at 0x3615ef4ce1: step=0
...
(gdb) info inferiors
Num Description Executable
5 process 9508 /home/pedro/bugs/src/test
^^^^
4 process 9503 /home/pedro/bugs/src/test
3 process 9500 /home/pedro/bugs/src/test
2 process 9499 /home/pedro/bugs/src/test
* 1 <null> /home/pedro/bugs/src/test
(gdb)
...
Note the "Thread 0x7ffff7fc2740 (LWP 9508) exited." line.
That's this in wait_lwp:
/* Check if the thread has exited. */
if (WIFEXITED (status) || WIFSIGNALED (status))
{
thread_dead = 1;
if (debug_linux_nat)
fprintf_unfiltered (gdb_stdlog, "WL: %s exited.\n",
target_pid_to_str (lp->ptid));
}
}
That was the leader thread reporting an exit, meaning the whole
process is gone. So the problem is that this code doesn't understand
that an WIFEXITED status of the leader LWP should be reported to
infrun as process exit.
gdb/ChangeLog:
2015-07-30 Pedro Alves <palves@redhat.com>
PR threads/18600
* linux-nat.c (wait_lwp): Report to the core when thread group
leader exits.
gdb/testsuite/ChangeLog:
2015-07-30 Pedro Alves <palves@redhat.com>
PR threads/18600
* gdb.threads/fork-plus-threads.exp: Test that "info inferiors"
only shows inferior 1.
Pedro Alves [Thu, 30 Jul 2015 17:55:36 +0000 (18:55 +0100)]
PR threads/18600: Threads left stopped after fork+thread spawn
When a program forks and another process start threads while gdb is
handling the fork event, newly created threads are left stuck stopped
by gdb, even though gdb presents them as "running", to the user.
This can be seen with the test added by this patch. The test has the
inferior fork a certain number of times and waits for all children to
exit. Each fork child spawns a number of threads that do nothing and
joins them immediately. Normally, the program should run unimpeded
(from the point of view of the user) and exit very quickly. Without
this fix, it doesn't because of some threads left stopped by gdb, so
inferior 1 never exits.
The program triggers when a new clone thread is found while inside the
linux_stop_and_wait_all_lwps call in linux-thread-db.c:
linux_stop_and_wait_all_lwps ();
ALL_LWPS (lp)
if (ptid_get_pid (lp->ptid) == pid)
thread_from_lwp (lp->ptid);
linux_unstop_all_lwps ();
Within linux_stop_and_wait_all_lwps, we reach
linux_handle_extended_wait with the "stopping" parameter set to 1, and
because of that we don't mark the new lwp as resumed. As consequence,
the subsequent resume_stopped_resumed_lwps, called from
linux_unstop_all_lwps, never resumes the new LWP.
There's lots of cruft in linux_handle_extended_wait that no longer
makes sense. On systems with CLONE events support, we don't rely on
libthread_db for thread listing anymore, so the code that preserves
stop_requested and the handling of last_resume_kind is all dead.
So the fix is to remove all that, and simply always mark the new LWP
as resumed, so that resume_stopped_resumed_lwps re-resumes it.
gdb/ChangeLog:
2015-07-30 Pedro Alves <palves@redhat.com>
Simon Marchi <simon.marchi@ericsson.com>
PR threads/18600
* linux-nat.c (linux_handle_extended_wait): On CLONE event, always
mark the new thread as resumed. Remove STOPPING parameter.
(wait_lwp): Adjust call to linux_handle_extended_wait.
(linux_nat_filter_event): Adjust call to
linux_handle_extended_wait.
(resume_stopped_resumed_lwps): Add debug output.
gdb/testsuite/ChangeLog:
2015-07-30 Simon Marchi <simon.marchi@ericsson.com>
Pedro Alves <palves@redhat.com>
PR threads/18600
* gdb.threads/fork-plus-threads.c: New file.
* gdb.threads/fork-plus-threads.exp: New file.
Pedro Alves [Tue, 14 Jul 2015 09:48:05 +0000 (10:48 +0100)]
gdbserver/Linux: internal error when killing a process that is already gone
If the process disappears (e.g., killed with "kill -9" from the shell)
while it was stopped under GDBserver's control, and the GDBserver
tries to kill it, GDBserver asserts:
(gdb) shell kill -9 23084
(gdb) kill
...
Killing process(es): 23084
/home/pedro/gdb/mygit/src/gdb/gdbserver/linux-low.c:972: A problem internal to GDBserver has been detected.
kill_wait_lwp: Assertion `res > 0' failed.
...
gdb/gdbserver/ChangeLog:
2015-07-14 Pedro Alves <palves@redhat.com>
* linux-low.c (kill_wait_lwp): Don't assert if waitpid fails.
Instead, ignore ECHILD, and throw an error for other errnos.
Markus Metzger [Mon, 6 Jul 2015 14:36:45 +0000 (16:36 +0200)]
record: set stop_pc in "record goto" command
When navigating in the recorded execution trace via "record goto", we do not
set stop_pc. This may trigger an internal error in infrun.c when stepping
from that location. Set it.
(gdb) rec full
(gdb) c
Continuing.
Breakpoint 1, foo (void) at foo.c:42
42 x = y
(gdb) rn
foo (void)
at foo.c:41
41 y = x
(gdb) rec go end
Go forward to insn number 98724
at foo.c:42
42 x = y
(gdb) n
infrun.c:2382: internal-error: resume: Assertion `sig != GDB_SIGNAL_0' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)
This happens because there's a breakpoint at PC when the "next"
is issued, so that breapoint should be immediately stepped over.
That should have been detected/done by proceed, here:
if (addr == (CORE_ADDR) -1)
{
if (pc == stop_pc
&& breakpoint_here_p (aspace, pc) == ordinary_breakpoint_here
&& execution_direction != EXEC_REVERSE)
/* There is a breakpoint at the address we will resume at,
step one instruction before inserting breakpoints so that
we do not stop right away (and report a second hit at this
breakpoint).
Note, we don't do this in reverse, because we won't
actually be executing the breakpoint insn anyway.
We'll be (un-)executing the previous instruction. */
tp->stepping_over_breakpoint = 1;
But since stop_pc was stale, the pc == stop_pc check failed, and left the
breakpont at PC inserted.
gdb/
* record-btrace.c (record_btrace_goto_begin, record_btrace_goto_end)
record_btrace_goto): Move call to print_stack_frame ...
(record_btrace_set_replay): ... here. Set stop_pc.
* record-full.c (record_full_goto_entry): Set stop_pc.
Markus Metzger [Tue, 7 Jul 2015 11:54:34 +0000 (13:54 +0200)]
btrace: fix build fail with 32-bit BFD
When compiling GDB with 32-bit BFD, the build fails with:
In file included from btrace.h:33:0,
from btrace.c:23:
/usr/include/intel-pt.h:1643:51: note: expected 'int (*)(uint8_t *, size_t,
const struct pt_asid *, uint64_t, void *)' but argument is of type 'int
(*)(gdb_byte *, size_t, const struct pt_asid *, CORE_ADDR, void *)' extern
pt_export int pt_image_set_callback(struct pt_image *image, ^
gdb/
* btrace.c (btrace_pt_readmem_callback): Change type of PC argument.
Andrew Burgess [Wed, 8 Jul 2015 14:02:32 +0000 (15:02 +0100)]
gdb/doc: Update 'frame' command documentation.
The documentation for the 'frame' command has gotten a little out of
date, it still mentions architecturally specific details that are no
longer relevant.
This commit removes the old details that no longer apply, and tries to
expand the existing text a little to make the usage clearer for some
cases.
gdb/doc/ChangeLog:
* gdb.texinfo (Selection): Update documentation for 'frame'
command.
Jan Kratochvil [Wed, 8 Jul 2015 12:42:19 +0000 (14:42 +0200)]
compile: Warn for old GCC on cv-qualified self-reference
GDB could:
compile code struct_object.selffield = &struct_object
./compile/compile-c-types.c:83: internal-error: insert_type: Assertion `add == NULL || add->gcc_type == gcc_type' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) FAIL: gdb.compile/compile.exp: compile code struct_object.selffield = &struct_object (GDB internal
error)
The bug was not in GDB but in the GCC part interfacing with GDB.
Alexandre Oliva has fixed it the right way:
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;a=commitdiff;h=072dfdba0ea62abb65514cb3a90cdf3868efe286
git://gcc.gnu.org/git/gcc.git
aoliva/libcp1
Attaching this GDB testsuite update + info to user s/he should upgrade GCC.
After Alex upstreams the fix I can update the message to contain the specific
GCC release.
gdb/ChangeLog
2015-07-08 Jan Kratochvil <jan.kratochvil@redhat.com>
PR compile/18484
* compile/compile-c-types.c (insert_type): Change gdb_assert to error.
gdb/testsuite/ChangeLog
2015-07-08 Jan Kratochvil <jan.kratochvil@redhat.com>
PR compile/18484
* gdb.compile/compile.c (struct struct_type): Add volatile to
selffield's type.
* gdb.compile/compile.exp
(compile code struct_object.selffield = &struct_object): Skip further
struct_object tests if this one xfails.
'ext 64' should be 'ext 8'; this bytecode evaluates to 255 instead of
the correct result of -1. The fix is simple. I ran the entire test
suite on x86-64 and there were no new test failures.
gdb/ChangeLog:
2015-07-08 Robert O'Callahan <robert@ocallahan.org>
PR exp/18617
* ax-gdb.c (gen_conversion): Extend to 'to' bits, not 'from'.
gdb/testsuite/ChangeLog:
2015-07-08 Robert O'Callahan <robert@ocallahan.org>
-PASS: gdb.cp/classes.exp: calling method for small class
+FAIL: gdb.cp/classes.exp: calling method for small class
The above is likely caused by GDB not removing the permanent
breakpoints from the target, leading to the inferior executing
the breakpoint instruction and tripping on a SIGSEGV.
gdb/ChangeLog:
2015-07-06 Luis Machado <lgustavo@codesourcery.com>
* breakpoint.c (remove_breakpoint_1): Don't handle permanent
breakpoints in a special way.
(remove_breakpoint): Likewise.
(mark_breakpoints_out): Likewise.
Andrew Burgess [Mon, 6 Jul 2015 10:37:24 +0000 (11:37 +0100)]
gdb/doc: Fix incorrect use of @xref.
All uses of @xref must be followed by either '.' or ','. In commit a4ea0946c an incorrect use of @xref was introduced. This commit
adds a comma after the use of @xref.
Andrew Burgess [Mon, 6 Jul 2015 15:56:42 +0000 (16:56 +0100)]
gdb/tui: Don't cast between window types.
Instead of casting between structure types to get the 'tui_gen_win_info'
info from a 'tui_win_info' access the generic member variable. This is
inline with what is done throughout the rest of the tui code.
gdb/ChangeLog:
* tui/tui-win.c (tui_set_focus): Use structure member 'generic'
instead of casting the structure type.
Simon Marchi [Mon, 6 Jul 2015 17:10:56 +0000 (13:10 -0400)]
search_struct_field: remove OFFSET parameter
I was trying to understand what the OFFSET parameter was for, and
realized it was set to 0 in every call to search_struct_field. I
assume that it was used at some point, but some subsequent changes
made it useless.
Simon Marchi [Mon, 6 Jul 2015 17:04:11 +0000 (13:04 -0400)]
Cleanup value_fetch_lazy's comment and return value
The comment for value_fetch_lazy seems outdated. It says that it's only
called from the value_contents and value_contents_all (macros!), which
is not true. Also, the return value seems useless now, despite what the
comment says.
gdb/ChangeLog:
* value.c (value_fetch_lazy): Update comment, change return
value to void.
* value.h (value_fetch_lazy): Change return value to void.
Andrew Burgess [Mon, 6 Jul 2015 14:32:11 +0000 (15:32 +0100)]
gdb: tui_win_name: Make parameter and result const.
This commit makes the parameter and the result for 'tui_win_name'
constant. There's one place in the code that is then updated as a
result of this change.
gdb/ChangeLog:
* tui/tui-data.c (tui_partial_win_by_name): Window name is const.
(tui_win_name): Make parameter and result const.
* tui/tui-data.h (tui_win_name): Make parameter and result const.
Patrick Palka [Thu, 2 Jul 2015 15:55:01 +0000 (11:55 -0400)]
Don't throw an error in "show mpx bound" implementation
"show" functions should not throw an exception in part because it causes
the output of the commands "info set" and "show" to get truncated.
This fixes the following fails:
FAIL: gdb.base/default.exp: info set
FAIL: gdb.base/default.exp: show
gdb/ChangeLog:
* i386-tdep.c (i386_mpx_info_bounds): Don't call error, instead
use printf_unfiltered.
(set_mpx_cmd): Add missing trailing space to command string
literal.
(_initialize_i386_tdep): Give the "mpx" prefix command its
correct name.
bfd/
* elf64-ppc.c (toc_adjusting_stub_needed): Use the symbol value
plus addend rather than the original st_value when looking up
entries in opd->adjust.
ld/testsuite/
* ld-powerpc/tocopt6-inc.s, ld-powerpc/tocopt6a.s,
ld-powerpc/tocopt6b.s, ld-powerpc/tocopt6c.s,
ld-powerpc/tocopt6.d: New test.
* ld-powerpc/powerpc.exp (ppc64elftests): Add it.
Alan Modra [Fri, 3 Jul 2015 01:26:26 +0000 (10:56 +0930)]
Remove ppc860, ppc750cl, ppc7450 insns from common ppc.
Back in the day support for these processors was added, we probably
didn't want to waste PPC_OPCODE bits on minor variations. I've had a
complaint that disassembly of mfspr/mtspr was wrong for power8. This
patch fixes that problem.
Note that since -m860/-m850/-m821 are new gas options enabling the
mpc8xx specific mfspr/mtspr variants it is possible that this change
will break some mpc8xx assembly code. ie. you might need to modify
makefiles to pass -m860 to gas.
Kevin Buettner [Thu, 2 Jul 2015 23:46:31 +0000 (16:46 -0700)]
Add support for backtracing through Renesas RX exception frames.
This change adds support for backtracing through Renesas RX exception
frames.
Determination about the type of frame is made by scanning the
remainder of the function for a return instruction and then looking at
which, if any, return instruction is found. A normal RTS instruction
indicates that the frame is a normal frame. An RTFI instruction
indicates that it's a fast interrupt, and an RTE instruction indicates
that the frame is a (normal) exception frame. If no return instruction
is found within the scanned region - which can happen when the end of
the function cannot be found - it is assumed to be a normal frame.
I was able to test that normal prologue scanning still works by
disabling the dwarf2 sniffer. I've tested this code for normal
interrupts. The fast interrupt case has not been tested.
gdb/ChangeLog:
* rx-tdep.c (RX_USP_REGNUM, RX_BPC_REGNUM): New constants.
(enum rx_frame_type): New.
(struct rx_prologue): Add new field `frame_type'.
(rx_analyze_prologue): Add `frame_type' parameter. Cache this
parameter in the prologue struct. Add code for recording
locations of PC and PSW for fast interrupt and exception frames.
(rx_skip_prologue): Adjust call to rx_analyze_prologue.
(rx_analyze_frame_prologue): Add `frame_type' parameter.
(rx_frame_type): New function.
(rx_frame_base): Fetch frame type and pass it to rx_analyze_prologue.
(rx_frame_this_id): Rename parameter `this_prologue_cache' to
`this_cache'.
(rx_frame_prev_register): Rename parameter `this_prologue_cache' to
`this_cache'. Add cases for RX_FRAME_TYPE_EXCEPTION and
RX_FRAME_TYPE_FAST_INTERRUPT.
(normal_frame_p, exception_frame_p, rx_frame_sniffer_common)
(rx_frame_sniffer, rx_exception_sniffer): New functions.
(rx_frame_unwind): Use rx_frame_sniffer instead of
default_frame_sniffer.
(rx_frame_unwind): New unwinder.
(rx_gdbarch_init): Register new unwinder.
Kevin Buettner [Thu, 2 Jul 2015 22:02:56 +0000 (15:02 -0700)]
rx: Create and use flags types for psw, bpsw, and fpsw registers.
This change adds two flags types for the (Renesas RX) psw, bpsw, and
fpsw registers. As a result, symbolic flags are displayed for these
registers in the output of GDB's "info registers" command as well as
in output from other commands, such as "print".
gdb/ChangeLog:
* rx-tdep.c (RX_BPSW_REGNUM, RX_FPSW_REGNUM): New constants.
(struct gdbarch_tdep): Add fields rx_psw_type and rx_fpsw_type.
(rx_register_type): Add cases for RX_PSW_REGNUM, RX_BPSW_REGNUM,
and RX_FPSW_REGNUM.
(rx_gdbarch_init): Initialize PSW, BPSW, and FPSW flags types.
Jan Kratochvil [Thu, 2 Jul 2015 20:39:57 +0000 (22:39 +0200)]
Fix GCC false warning
At least on
gcc-4.4.7-11.el6.i686
./configure --enable-64-bit-bfd --enable-targets=all
GDB does not build due to:
cc1: warnings being treated as errors
s390-linux-tdep.c: In function ‘s390_handle_arg’:
s390-linux-tdep.c:2575: error: ‘val’ may be used uninitialized in this function
gdb/ChangeLog
2015-07-02 Jan Kratochvil <jan.kratochvil@redhat.com>
Fix GCC false warning.
* s390-linux-tdep.c (s390_handle_arg): Initialize VAL.
Markus Metzger [Mon, 17 Nov 2014 10:18:05 +0000 (11:18 +0100)]
btrace, linux: use data_size and data_offset
In struct perf_event_mmap_page there are new fields data_size and data_offset
that give the location of the perf_event data buffer relative to the mmap
page. Use them if they are present.
gdb/
* nat/linux-btrace.c (linux_enable_bts): Check for
PERF_ATTR_SIZE_VER5.
Check for data_offset and data_size fields. Use them.
Markus Metzger [Fri, 24 Jan 2014 12:45:47 +0000 (13:45 +0100)]
btrace: support Intel(R) Processor Trace
Adds a new command "record btrace pt" to configure the kernel to use
Intel(R) Processor Trace instead of Branch Trace Strore.
The "record btrace" command chooses the tracing format automatically.
Intel(R) Processor Trace support requires Linux 4.1 and libipt.
gdb/
* NEWS: Announce new commands "record btrace pt" and "record pt".
Announce new options "set|show record btrace pt buffer-size".
* btrace.c: Include "rsp-low.h".
Include "inttypes.h".
(btrace_add_pc): Add forward declaration.
(pt_reclassify_insn, ftrace_add_pt, btrace_pt_readmem_callback)
(pt_translate_cpu_vendor, btrace_finalize_ftrace_pt)
(btrace_compute_ftrace_pt): New.
(btrace_compute_ftrace): Support BTRACE_FORMAT_PT.
(check_xml_btrace_version): Update version check.
(parse_xml_raw, parse_xml_btrace_pt_config_cpu)
(parse_xml_btrace_pt_raw, parse_xml_btrace_pt)
(btrace_pt_config_cpu_attributes, btrace_pt_config_children)
(btrace_pt_children): New.
(btrace_children): Add support for "pt".
(parse_xml_btrace_conf_pt, btrace_conf_pt_attributes): New.
(btrace_conf_children): Add support for "pt".
* btrace.h: Include "intel-pt.h".
(btrace_pt_error): New.
* common/btrace-common.c (btrace_format_string, btrace_data_fini)
(btrace_data_empty): Support BTRACE_FORMAT_PT.
* common/btrace-common.h (btrace_format): Add BTRACE_FORMAT_PT.
(struct btrace_config_pt): New.
(struct btrace_config)<pt>: New.
(struct btrace_data_pt_config, struct btrace_data_pt): New.
(struct btrace_data)<pt>: New.
* features/btrace-conf.dtd (btrace-conf)<pt>: New.
(pt): New.
* features/btrace.dtd (btrace)<pt>: New.
(pt, pt-config, cpu): New.
* nat/linux-btrace.c (perf_event_read, perf_event_read_all)
(perf_event_pt_event_type, kernel_supports_pt)
(linux_supports_pt): New.
(linux_supports_btrace): Support BTRACE_FORMAT_PT.
(linux_enable_bts): Free tinfo on error.
(linux_enable_pt): New.
(linux_enable_btrace): Support BTRACE_FORMAT_PT.
(linux_disable_pt): New.
(linux_disable_btrace): Support BTRACE_FORMAT_PT.
(linux_fill_btrace_pt_config, linux_read_pt): New.
(linux_read_btrace): Support BTRACE_FORMAT_PT.
* nat/linux-btrace.h (struct btrace_tinfo_pt): New.
(struct btrace_target_info)<pt>: New.
* record-btrace.c (set_record_btrace_pt_cmdlist)
(show_record_btrace_pt_cmdlist): New.
(record_btrace_print_pt_conf): New.
(record_btrace_print_conf): Support BTRACE_FORMAT_PT.
(btrace_ui_out_decode_error): Support BTRACE_FORMAT_PT.
(cmd_record_btrace_pt_start): New.
(cmd_record_btrace_start): Support BTRACE_FORMAT_PT.
(cmd_set_record_btrace_pt, cmd_show_record_btrace_pt): New.
(_initialize_record_btrace): Add new commands.
* remote.c (PACKET_Qbtrace_pt, PACKET_Qbtrace_conf_pt_size): New.
(remote_protocol_features): Add "Qbtrace:pt".
Add "Qbtrace-conf:pt:size".
(remote_supports_btrace): Support BTRACE_FORMAT_PT.
(btrace_sync_conf): Support PACKET_Qbtrace_conf_pt_size.
(remote_enable_btrace): Support BTRACE_FORMAT_PT.
(_initialize_remote): Add new commands.
gdbserver/
* linux-low.c: Include "rsp-low.h"
(linux_low_encode_pt_config, linux_low_encode_raw): New.
(linux_low_read_btrace): Support BTRACE_FORMAT_PT.
(linux_low_btrace_conf): Support BTRACE_FORMAT_PT.
(handle_btrace_enable_pt): New.
(handle_btrace_general_set): Support "pt".
(handle_btrace_conf_general_set): Support "pt:size".
doc/
* gdb.texinfo (Process Record and Replay): Spell out that variables
and registers are not available during btrace replay.
Describe the new "record btrace pt" command.
Describe the new "set|show record btrace pt buffer-size" options.
(General Query Packets): Describe the new Qbtrace:pt and
Qbtrace-conf:pt:size packets.
Expand "bts" to "Branch Trace Store".
Update the branch trace DTD.
Jan Kratochvil [Thu, 2 Jul 2015 06:01:35 +0000 (08:01 +0200)]
debug compile: Replace confusing debug message
It was found that from
(gdb) set debug compile 1
(gdb) compile code 1
[...]
allocated 0x7f bytes at 0x7ffff7ff9000 prot 5
allocated 0x38 bytes at 0x7ffff7ff8000 prot 1
lookup undefined ELF symbol "_GLOBAL_OFFSET_TABLE_"
allocated 0x10 bytes at 0x7ffff7ff7000 for registers
(gdb) _
the message 'lookup undefined ELF symbol' looks as an error to people,
including to myself once.
Change it to:
allocated 0x7f bytes at 0x7ffff7ff9000 prot 5
allocated 0x38 bytes at 0x7ffff7ff8000 prot 1
ELF symbol "_GLOBAL_OFFSET_TABLE_" relocated to zero
allocated 0x10 bytes at 0x7ffff7ff7000 for registers
(gdb) _
gdb/ChangeLog
2015-07-02 Jan Kratochvil <jan.kratochvil@redhat.com>
* compile/compile-object-load.c (compile_object_load): Replace debug
message "lookup undefined ELF symbol" by 3 more specific messages.
Kevin Buettner [Wed, 1 Jul 2015 23:18:35 +0000 (16:18 -0700)]
rl78: Create a flags type for the psw register.
For the Renesas rl78 architecture, associate a flags type with the PSW
register. This will cause symbolic flags to be printed when using
the "info registers" command.
gdb/ChangeLog:
* rl78-tdep.c (struct gdbarch_tdep): Add new field, rl78_psw_type.
(rl78_register_type): Add case for RL78_PSW_REGNUM.
(rl78_gdbarch_init): Initialize rl78_psw_type.
2015-07-01 Sandra Loosemore <sandra@codesourcery.com>
Cesar Philippidis <cesar@codesourcery.com>
bfd/
* bfd-in2.h: Regenerated.
* elf32-nios2.c (elf_nios2_howto_table_rel): Rename to...
(elf_nios2_r1_howto_table_rel): This.
(elf_nios2_r2_howto_table_rel): New.
(BFD_IS_R2): New.
(lookup_howto): Add ABFD parameter. Adjust to look up in either
the R1 or R2 relocation table, as determined by ABFD.
(nios2_reloc_map): Add R2 relocations.
(nios2_elf32_bfd_reloc_type_lookup): Do lookup using lookup_howto.
Pass it the ABFD parameter.
(nios2_elf32_bfd_reloc_name_lookup): Use ABFD to decide whether to
return an R1 or R2 relocation.
(nios2_elf32_info_to_howto): Do lookup using lookup_howto.
Pass it the ABFD parameter.
(nios2_elf32_do_call26_relocate): Check for alignment on a 4-byte
boundary.
(nios2_elf32_relocate_section): Adjust call to lookup_howto.
* libbfd.h: Regenerated.
* reloc.c (BFD_RELOC_NIOS2_R2_S12): New.
(BFD_RELOC_NIOS2_R2_I10_1_PCREL): New.
(BFD_RELOC_NIOS2_R2_T1I7_1_PCREL): New.
(BFD_RELOC_NIOS2_R2_T1I7_2): New.
(BFD_RELOC_NIOS2_R2_T2I4): New.
(BFD_RELOC_NIOS2_R2_T2I4_1): New.
(BFD_RELOC_NIOS2_R2_T2I4_2): New.
(BFD_RELOC_NIOS2_R2_X1I7_2): New.
(BFD_RELOC_NIOS2_R2_X2L5): New.
(BFD_RELOC_NIOS2_R2_F1I5_2): New.
(BFD_RELOC_NIOS2_R2_L5I4X1): New.
(BFD_RELOC_NIOS2_R2_T1X1I6): New.
(BFD_RELOC_NIOS2_R2_T1X1I6_2): New.
Patrick Palka [Wed, 1 Jul 2015 12:02:09 +0000 (08:02 -0400)]
TUI: Make sure to update registers if frame information has changed
When I replaced TUI's frame_changed hook to fix PR tui/13378 I assumed
that there's no reason to refresh register information following a call
to "up", "down" or "frame". This assumption was made to fix the problem
of refreshing frame information twice following a sync-execution normal
stop (once in tui_normal_stop and then in tui_before_prompt) -- the
second refresh removing any highlights made by the first.
I was wrong about that -- GDB's snapshot of register information is
per-frame, and when the frame changes, registers do too (most
prominently the %rip and %rsp registers). So e.g. GDB 7.8 would
highlight such register changes after invoking "up", "down" or "frame",
and current GDB does not.
To fix this regression, this patch adds another (sufficient) condition
for refreshing register information: in
tui_refresh_frame_and_register_information, always refresh register
information if frame information has changed. This makes register
information get refreshed following a call to "up", "down" or "frame"
while still avoiding the "double refresh" issue following a normal stop.
This condition may seem to obsolete the existing registers_too_p
parameter, but it does not: following a normal stop, it is possible that
registers may have changed while frame information had not. We could be
on the exact same PC with different register values. The new condition
would not catch such a case, but the registers_too_p condition will. So
both conditions seem necessary (and either one is sufficient).
gdb/ChangeLog:
* tui/tui-hooks.c (tui_refresh_frame_and_register_information):
Update commentary. Always refresh the registers when frame
information has changed.
* tui/tui-stack.c (tui_show_frame_info): Update commentary.
Change return type to int. Return 1 if frame information has
changed, 1 otherwise.
(tui_before_prompt): Update commentary.
* tui/tui-stack.h (tui_show_frame_info): Change return type to
int.
Patrick Palka [Tue, 30 Jun 2015 17:56:49 +0000 (13:56 -0400)]
Replace TUI's select_frame hook (PR tui/13378)
The select_frame hook is used by TUI to update TUI's frame and register
information following changes to the selected frame. The problem with
this hook is that it gets called after every single frame change, even
if the frame change is only temporary or internal. This is the primary
cause of flickering and slowdown when running the inferior under TUI
with conditional breakpoints set. Internal GDB events are the source of
many calls to select_frame and these internal events are triggered
frequently, especially when a few conditional breakpoints are set.
This patch removes the select_frame hook altogether and instead makes
the frame and register information get updated in two key places (using
observers): after an inferior stops, and right before displaying a
prompt. The latter hook covers the case when frame information must be
updated following a call to "up", "down" or "frame", and the former
covers the case when frame and register information must be updated
after a call to "continue", "step", etc. or after the inferior stops in
async execution mode. Together these hooks should cover all the cases
when frame information ought to be refreshed (and when the relevant
windows ought to be subsequently updated).
The print_frame_info_listing hook is also effectively obsolete now, but
it still must be set while the TUI is active because its caller
print_frame_info will otherwise assume that the CLI is active, and will
print the frame informaion accordingly. So this patch also sets the
print_frame_info_listing hook to a dummy callback, in lieu of outright
removing it yet.
Effectively, with this patch, frame/PC changes that do not immediately
precede an inferior-stop event or a prompt display event no longer cause
TUI's frame and register information to be updated.
And as a result of this change and of the previous change to
tui_show_frame_info, the TUI is much more disciplined about updating the
screen, and so the flicker as described in the PR is totally gone.
gdb/ChangeLog:
PR tui/13378
* frame.c (select_frame): Remove reference to
deprecated_selected_frame_level_changed_hook.
* frame.h (deprecated_selected_frame_level_changed_hook): Remove
declaration.
* stack.c (deprecated_selected_frame_level_changed_hook):
Likewise.
* tui/tui-hooks.c (tui_selected_frame_level_changed_hook):
Rename to ...
(tui_refresh_frame_and_register_information): ... this. Bail
out if there is no stack. Don't update register information
unless registers_too_p is true.
(tui_print_frame_info_listing_hook): Rename to ...
(tui_dummy_print_frame_info_listing_hook): ... this.
(tui_before_prompt): New function.
(tui_normal_stop): New function.
(tui_before_prompt_observer): New observer.
(tui_normal_stop_observer): New observer.
(tui_install_hooks): Set
deprecated_print_frame_info_listing_hook to
tui_dummy_print_frame_info_listing_hook. Register
tui_before_prompt_observer to call tui_before_prompt and
tui_normal_stop_observer to call tui_normal_stop. Remove
reference to deprecated_selected_frame_level_changed_hook.
(tui_remove_hooks): Detach and unset tui_before_prompt_observer
and tui_normal_stop_observer. Remove reference to
deprecated_selected_frame_level_changed_hook.
Patrick Palka [Sat, 27 Jun 2015 00:38:30 +0000 (20:38 -0400)]
Be lazy about refreshing the windows in tui_show_frame_info (PR tui/13378)
tui_show_frame_info is responsible for updating the visible windows
following a change in frame information (that being the currently
selected frame, PC, line number, etc). Currently it always redraws and
refreshes each window even if frame information has not changed. This
behavior is inefficient and helps contribute to the occassional
flickering of the TUI as described in the mentioned PR.
This patch makes tui_show_frame_info refresh the windows only if frame
information has changed. Determining whether frame information has
changed is done indirectly by determining whether the locator has
changed. This approach is convenient and yet sensible because the
locator contains all the relevant info we need to check anyway: the
current PC, the line number, the name of the executable and the name of
the current function. Probably only the PC is really necessary to
check, but it doesn't hurt to check every field.
Effectively, with this patch, consecutive calls to select_frame with the
same frame/PC no longer cause TUI's frame information to be updated
multiple times.
gdb/ChangeLog:
PR tui/13378
* tui/tui-stack.c (tui_set_locator_info): Change prototype to
return an int instead of void. Return whether the locator
window has changed.
(tui_show_frame_info): If the locator info has not changed, then
bail out early to avoid refreshing the windows.
Patrick Palka [Sat, 27 Jun 2015 00:17:56 +0000 (20:17 -0400)]
Correctly initialize the TUI locator window
The call to tui_alloc_content in tui_set_locator_info passes
locator->type as the type of the window whose content is being
allocated. This may seem correct but it's actually not because when
this code path actually get executed locator->type has not yet been to
set LOCATOR_WIN so it defaults to 0 i.e. SRC_WIN. Thus we allocate the
content of the locator window as if it was the source window. This
oversight turns out not to be a big deal in practice but the patch that
follows depends on the locator's proc_name and full_name arrays to be
initialized to the empty string which is done by tui_alloc_content if
we pass to it LOCATOR_WIN.
This patch fixes this bug by explicitly passing LOCATOR_WIN to
tui_alloc_content.
gdb/ChangeLog:
* tui/tui-stack.c (tui_set_locator_info): Explicitly pass
LOCATOR_WIN to tui_alloc_content.
projects / thirdparty / binutils-gdb.git / log
