[Bug gdb/18216] displaced step+deliver signal, while another thread also needs to step over breakpoint, crashes gdb on hardware step targets

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

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

--- 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=f3770638ca377ff2bdd7cec2cb239d2909034690

commit f3770638ca377ff2bdd7cec2cb239d2909034690
Author: Pedro Alves <palves@redhat.com>
Date:   Wed Apr 8 19:59:03 2015 +0100

    Add test for PR18214 and PR18216 - multiple step-overs with queued signals

    Both PRs are triggered by the same use case.

    PR18214 is about software single-step targets.  On those, the 'resume'
    code that detects that we're stepping over a breakpoint and delivering
    a signal at the same time:

      /* Currently, our software single-step implementation leads to different
         results than hardware single-stepping in one situation: when stepping
         into delivering a signal which has an associated signal handler,
         hardware single-step will stop at the first instruction of the
handler,
         while software single-step will simply skip execution of the handler.
    ...
         Fortunately, we can at least fix this particular issue.  We detect
         here the case where we are about to deliver a signal while software
         single-stepping with breakpoints removed.  In this situation, we
         revert the decisions to remove all breakpoints and insert single-
         step breakpoints, and instead we install a step-resume breakpoint
         at the current address, deliver the signal without stepping, and
         once we arrive back at the step-resume breakpoint, actually step
         over the breakpoint we originally wanted to step over.  */

    doesn't handle the case of _another_ thread also needing to step over
    a breakpoint.  Because the other thread is just resumed at the PC
    where it had stopped and a breakpoint is still inserted there, the
    thread immediately re-traps the same breakpoint.  This test exercises
    that.  On software single-step targets, it fails like this:

     KFAIL: gdb.threads/multiple-step-overs.exp: displaced=off: signal thr3:
continue to sigusr1_handler
     KFAIL: gdb.threads/multiple-step-overs.exp: displaced=off: signal thr2:
continue to sigusr1_handler

    gdb.log (simplified):

     (gdb) continue
     Continuing.

     Breakpoint 4, child_function_2 (arg=0x0) at
src/gdb/testsuite/gdb.threads/multiple-step-overs.c:66
     66            callme (); /* set breakpoint thread 2 here */
     (gdb) thread 3
     (gdb) queue-signal SIGUSR1
     (gdb) thread 1
     [Switching to thread 1 (Thread 0x7ffff7fc1740 (LWP 24824))]
     #0  main () at src/gdb/testsuite/gdb.threads/multiple-step-overs.c:106
     106       wait_threads (); /* set wait-threads breakpoint here */
     (gdb) break sigusr1_handler
     Breakpoint 5 at 0x400837: file
src/gdb/testsuite/gdb.threads/multiple-step-overs.c, line 31.
     (gdb) continue
     Continuing.
     [Switching to Thread 0x7ffff7fc0700 (LWP 24828)]

     Breakpoint 4, child_function_2 (arg=0x0) at
src/gdb/testsuite/gdb.threads/multiple-step-overs.c:66
     66            callme (); /* set breakpoint thread 2 here */
     (gdb) KFAIL: gdb.threads/multiple-step-overs.exp: displaced=off: signal
thr3: continue to sigusr1_handler


    For good measure, I made the test try displaced stepping too.  And
    then I found it crashes GDB on x86-64 (a hardware step target), but
    only when displaced stepping... :

     KFAIL: gdb.threads/multiple-step-overs.exp: displaced=on: signal thr1:
continue to sigusr1_handler (PRMS: gdb/18216)
     KFAIL: gdb.threads/multiple-step-overs.exp: displaced=on: signal thr2:
continue to sigusr1_handler (PRMS: gdb/18216)
     KFAIL: gdb.threads/multiple-step-overs.exp: displaced=on: signal thr3:
continue to sigusr1_handler (PRMS: gdb/18216)

     Program terminated with signal SIGSEGV, Segmentation fault.
     #0  0x000000000062a83a in process_event_stop_test (ecs=0x7fff847eeee0) at
src/gdb/infrun.c:4964
     4964          if (sr_bp->loc->permanent
     Setting up the environment for debugging gdb.
     Breakpoint 1 at 0x79fcfc: file src/gdb/common/errors.c, line 54.
     Breakpoint 2 at 0x50a26c: file src/gdb/cli/cli-cmds.c, line 217.
     (top-gdb) p sr_bp
     $1 = (struct breakpoint *) 0x0
     (top-gdb) bt
     #0  0x000000000062a83a in process_event_stop_test (ecs=0x7fff847eeee0) at
src/gdb/infrun.c:4964
     #1  0x000000000062a1af in handle_signal_stop (ecs=0x7fff847eeee0) at
src/gdb/infrun.c:4715
     #2  0x0000000000629097 in handle_inferior_event (ecs=0x7fff847eeee0) at
src/gdb/infrun.c:4165
     #3  0x0000000000627482 in fetch_inferior_event (client_data=0x0) at
src/gdb/infrun.c:3298
     #4  0x000000000064ad7b in inferior_event_handler
(event_type=INF_REG_EVENT, client_data=0x0) at src/gdb/inf-loop.c:56
     #5  0x00000000004c375f in handle_target_event (error=0, client_data=0x0)
at src/gdb/linux-nat.c:4658
     #6  0x0000000000648c47 in handle_file_event (file_ptr=0x2e0eaa0,
ready_mask=1) at src/gdb/event-loop.c:658

    The all-stop-non-stop series fixes this, but meanwhile, this augments
    the multiple-step-overs.exp test to cover this, KFAILed.

    gdb/testsuite/ChangeLog:
    2015-04-08  Pedro Alves  <palves@redhat.com>

        PR gdb/18214
        PR gdb/18216
        * gdb.threads/multiple-step-overs.c (sigusr1_handler): New
        function.
        (main): Install it as SIGUSR1 handler.
        * gdb.threads/multiple-step-overs.exp (setup): Remove 'prefix'
        parameter.  Always use "setup" as prefix.  Toggle "set
        displaced-stepping" off/on depending on global.  Don't switch to
        thread 1 here.
        (top level): Add displaced stepping "off/on" test axis.  Update
        "setup" calls.  Wrap each subtest with with_test_prefix.  Test
        continuing with a queued signal in each thread.

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