This is the mail archive of the gdb-prs@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug gdb/18214] New: step over breakpoint and deliver signal, while another thread also needs to step over breakpoint, mishandled on software single-step targets


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

            Bug ID: 18214
           Summary: step over breakpoint and deliver signal, while another
                    thread also needs to step over breakpoint, mishandled
                    on software single-step targets
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: gdb
          Assignee: unassigned at sourceware dot org
          Reporter: palves at redhat dot com

Ref: https://sourceware.org/ml/gdb-patches/2015-04/msg00262.html.

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 that other thread is just resumed, it'll
immediately re-trap the same breakpoint it had stopped for.

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]