[Bug gdb/19389] GDB sometimes mistakenly allows accessing registers of running threads

["cvs-commit at gcc dot gnu.org" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=19389

--- Comment #1 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Pedro Alves <palves@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=a911d87ad714cbfbbc5c5752cb8b445a7e70196c

commit a911d87ad714cbfbbc5c5752cb8b445a7e70196c
Author: Pedro Alves <palves@redhat.com>
Date:   Wed Jan 13 10:40:33 2016 +0000

    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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.