diff options
author | Pedro Alves <palves@redhat.com> | 2016-01-13 10:40:33 +0000 |
---|---|---|
committer | Pedro Alves <palves@redhat.com> | 2016-01-13 10:40:33 +0000 |
commit | a911d87ad714cbfbbc5c5752cb8b445a7e70196c (patch) | |
tree | f7a48df5a040748238538d62ea9c2b0f51f41a43 /gdb/gdbthread.h | |
parent | 8405419985b2a5f9c4f79b28af6c2324655b5c5b (diff) | |
download | gdb-a911d87ad714cbfbbc5c5752cb8b445a7e70196c.zip gdb-a911d87ad714cbfbbc5c5752cb8b445a7e70196c.tar.gz gdb-a911d87ad714cbfbbc5c5752cb8b445a7e70196c.tar.bz2 |
Fix PR19388: Can't access $_siginfo in breakpoint (catch signal) condition
This commit merges both the registers and $_siginfo "thread
running/executing" checks into a single function.
Accessing $_siginfo from a "catch signal" breakpoint condition doesn't
work. The condition always fails with "Selected thread is running":
(gdb) catch signal
Catchpoint 3 (standard signals)
(gdb)
condition $bpnum $_siginfo.si_signo == 5
(gdb) continue
Continuing.
Error in testing breakpoint condition:
Selected thread is running.
Catchpoint 3 (signal SIGUSR1), 0x0000003615e35877 in __GI_raise (sig=10) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
56 return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
(gdb)
When accessing the $_siginfo object, we check whether the thread is
marked running (external/public) state and refuse the access if so.
This is so "print $_siginfo" at the prompt fails nicelly when the
current thread is running. While evaluating breakpoint conditionals,
we haven't decided yet whether the thread is going to stop, so
is_running still returns true, and we thus always error out.
Evaluating an expression that requires registers access is really
conceptually the same -- we could think of $_siginfo as a pseudo
register. However, in that case we check whether the thread is marked
executing (internal/private state), not running (external/public
state). Changing the $_siginfo validation to check is_executing as
well fixes the bug in question.
Note that checking is_executing is not fully correct, not even for
registers. See PR 19389. However, I think this is the lesser of two
evils and ends up as an improvement. We at least now have a single
place to fix.
Tested on x86_64 GNU/Linux.
gdb/ChangeLog:
2016-01-13 Pedro Alves <palves@redhat.com>
PR breakpoints/19388
* frame.c (get_current_frame): Use validate_registers_access.
* gdbthread.h (validate_registers_access): Declare.
* infrun.c (validate_siginfo_access): Delete.
(siginfo_value_read, siginfo_value_write): Use
validate_registers_access.
* thread.c (validate_registers_access): New function.
gdb/testsuite/ChangeLog:
2016-01-13 Pedro Alves <palves@redhat.com>
PR breakpoints/19388
* gdb.base/catch-signal-siginfo-cond.c: New file.
* gdb.base/catch-signal-siginfo-cond.exp: New file.
Diffstat (limited to 'gdb/gdbthread.h')
-rw-r--r-- | gdb/gdbthread.h | 5 |
1 files changed, 5 insertions, 0 deletions
diff --git a/gdb/gdbthread.h b/gdb/gdbthread.h index b75184b..c9f5926 100644 --- a/gdb/gdbthread.h +++ b/gdb/gdbthread.h @@ -555,6 +555,11 @@ extern int thread_is_in_step_over_chain (struct thread_info *tp); extern void thread_cancel_execution_command (struct thread_info *thr); +/* Check whether it makes sense to access a register of the current + thread at this point. If not, throw an error (e.g., the thread is + executing). */ +extern void validate_registers_access (void); + extern struct thread_info *thread_list; #endif /* GDBTHREAD_H */ |