[Bug gdb/17000] New: sss breakpoint on top of a regular breakpoint; gdb loses control

[Bug gdb/17000] New: sss breakpoint on top of a regular breakpoint; gdb loses control

[palves at redhat dot com]

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

            Bug ID: 17000
           Summary: sss breakpoint on top of a regular breakpoint; gdb
                    loses control
           Product: gdb
           Version: 7.7
            Status: NEW
          Severity: normal
          Priority: P2
         Component: gdb
          Assignee: unassigned at sourceware dot org
          Reporter: palves at redhat dot com

This was first reported as a regression caused by the fix for 
bug 7143.  See discussion starting at:

 https://sourceware.org/bugzilla/show_bug.cgi?id=7143#c12

On software single-step targets, if another breakpoint happens to be inserted
where a single-step breakpoint is also inserted, and gdb removes the
single-step breakpoint, while intenting to leave the other breakpoint inserted,
GDB actually really removes the breakpoint from the target, while it thinks it
hasn't, leading to all sort of nasty issues related to the breakpoint being
missed.

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

[Bug breakpoints/17000] sss breakpoint on top of a regular breakpoint; gdb loses control

[palves at redhat dot com]

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

Pedro Alves <palves at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|gdb                         |breakpoints

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

[Bug breakpoints/17000] user breakpoint not inserted if software-single-step at same location

[palves at redhat dot com]

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

Pedro Alves <palves at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|sss breakpoint on top of a  |user breakpoint not
                   |regular breakpoint; gdb     |inserted if
                   |loses control               |software-single-step at
                   |                            |same location

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

[Bug breakpoints/17000] user breakpoint not inserted if software-single-step at same location

[cvs-commit at gcc dot gnu.org]

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

--- Comment #1 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "gdb and binutils".

The branch, master has been updated
       via  9ba6657a6b81a02dca9071ec14cbcef970f0ca07 (commit)
      from  522c09bf63a4b235e6fde07a5e389f2a533cfe0f (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

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

commit 9ba6657a6b81a02dca9071ec14cbcef970f0ca07
Author: Pedro Alves <palves@redhat.com>
Date:   Fri May 30 17:21:02 2014 +0100

    PR breakpoints/17000: user breakpoint not inserted if software-single-step
at same location - test

    GDB gets confused when removing a software single-step breakpoint that
    is at the same address as another breakpoint.  Add a kfailed test.

    gdb/testsuite/
    2014-05-30  Pedro Alves  <palves@redhat.com>

        PR breakpoints/17000
        * gdb.base/sss-bp-on-user-bp.c: New file.
        * gdb.base/sss-bp-on-user-bp.exp: New file.

-----------------------------------------------------------------------

Summary of changes:
 gdb/testsuite/ChangeLog                      |    6 +++
 gdb/testsuite/gdb.base/sss-bp-on-user-bp.c   |   30 +++++++++++++++
 gdb/testsuite/gdb.base/sss-bp-on-user-bp.exp |   52 ++++++++++++++++++++++++++
 3 files changed, 88 insertions(+), 0 deletions(-)
 create mode 100644 gdb/testsuite/gdb.base/sss-bp-on-user-bp.c
 create mode 100644 gdb/testsuite/gdb.base/sss-bp-on-user-bp.exp

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

[Bug breakpoints/17000] user breakpoint not inserted if software-single-step at same location

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "gdb and binutils".

The branch, master has been updated
       via  835c559fd59d4ebb3b04d046c1f9f36183db0fe6 (commit)
      from  06eb158633faa8746dd39f19ce784448bb7ece00 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

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

commit 835c559fd59d4ebb3b04d046c1f9f36183db0fe6
Author: Pedro Alves <palves@redhat.com>
Date:   Tue Jun 3 12:46:46 2014 +0100

    PR breakpoints/17000: user breakpoint not inserted if software-single-step
at same location - test

    GDB gets confused when removing a software single-step breakpoint that
    is at the same address as another breakpoint.  Add another kfailed
    test.

    gdb/testsuite/
    2014-06-03  Pedro Alves  <palves@redhat.com>

        PR breakpoints/17000
        * gdb.base/sss-bp-on-user-bp-2.c: New file.
        * gdb.base/sss-bp-on-user-bp-2.exp: New file.

-----------------------------------------------------------------------

Summary of changes:
 gdb/testsuite/ChangeLog                        |    6 ++
 gdb/testsuite/gdb.base/sss-bp-on-user-bp-2.c   |   29 ++++++
 gdb/testsuite/gdb.base/sss-bp-on-user-bp-2.exp |  109 ++++++++++++++++++++++++
 3 files changed, 144 insertions(+), 0 deletions(-)
 create mode 100644 gdb/testsuite/gdb.base/sss-bp-on-user-bp-2.c
 create mode 100644 gdb/testsuite/gdb.base/sss-bp-on-user-bp-2.exp

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

[Bug breakpoints/17000] user breakpoint not inserted if software-single-step at same location

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "gdb and binutils".

The branch, master has been updated
       via  ef370185fcf955b1273c2c6bcbe0b406ec1cbd83 (commit)
      from  c32abae8456a2cb959862626b5ff9ebdd1543514 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

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

commit ef370185fcf955b1273c2c6bcbe0b406ec1cbd83
Author: Joel Brobecker <brobecker@adacore.com>
Date:   Tue Jun 3 17:42:19 2014 +0100

    User breakpoint ignored if software-single-step at same location

    with the following code...

        12    Nested;   -- break #1
        13    return I; -- break #2
        14  end;

    (line 12 is a call to function Nested)

    ... we have noticed the following errorneous behavior on ppc-aix,
    where, after having inserted a breakpoint at line 12 and line 13,
    and continuing from the breakpoint at line 12, the program never
    stops at line 13, running away until the program terminates:

        % gdb -q func
        (gdb) b func.adb:12
        Breakpoint 1 at 0x10000a24: file func.adb, line 12.
        (gdb) b func.adb:13
        Breakpoint 2 at 0x10000a28: file func.adb, line 13.
        (gdb) run
        Starting program: /[...]/func

        Breakpoint 1, func () at func.adb:12
        12        Nested;   -- break #1
        (gdb) c
        Continuing.
        [Inferior 1 (process 4128872) exited with code 02]

    When resuming from the first breakpoint, GDB first tries to step out
    of that first breakpoint.  We rely on software single-stepping on this
    platform, and it just so happens that the address of the first
    software single-step breakpoint is the same as the user's breakpoint
    #2 (0x10000a28).  So, with infrun and target traces turned on (but
    uninteresting traces snip'ed off), the "continue" operation looks like
    this:

        (gdb) c
        ### First, we insert the user breakpoints (the second one is an
internal
        ### breakpoint on __pthread_init). The first user breakpoint is not
        ### inserted as we need to step out of it first.
        target_insert_breakpoint (0x0000000010000a28, xxx) = 0
        target_insert_breakpoint (0x00000000d03f3800, xxx) = 0
        ### Then we proceed with the step-out-of-breakpoint...
        infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=1, current
thread [process 15335610] at 0x10000a24
        ### That's when we insert the SSS breakpoints...
        target_insert_breakpoint (0x0000000010000a28, xxx) = 0
        target_insert_breakpoint (0x00000000100009ac, xxx) = 0
        ### ... then let the inferior resume...
        target_resume (15335610, continue, 0)
        infrun: wait_for_inferior ()
        target_wait (-1, status, options={}) = 15335610,   status->kind =
stopped, signal = GDB_SIGNAL_TRAP
        infrun: target_wait (-1, status) =
        infrun:   15335610 [process 15335610],
        infrun:   status->kind = stopped, signal = GDB_SIGNAL_TRAP
        infrun: infwait_normal_state
        infrun: TARGET_WAITKIND_STOPPED
        infrun: stop_pc = 0x100009ac
        ### At this point, we stopped at the second SSS breakpoint...
        target_stopped_by_watchpoint () = 0
        ### We remove the SSS breakpoints...
        target_remove_breakpoint (0x0000000010000a28, xxx) = 0
        target_remove_breakpoint (0x00000000100009ac, xxx) = 0
        target_stopped_by_watchpoint () = 0
        ### We find that we're not done, so we resume....
        infrun: no stepping, continue
        ### And thus insert the user breakpoints again, except we're not
        ### inserting the second breakpoint?!?
        target_insert_breakpoint (0x0000000010000a24, xxx) = 0
        infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current
thread [process 15335610] at 0x100009ac
        target_resume (-1, continue, 0)
        infrun: prepare_to_wait
        target_wait (-1, status, options={}) = 15335610,   status->kind =
exited, status = 2

    What happens is that the removal of the software single-step
    breakpoints effectively removed the breakpoint instruction from
    inferior memory.  But because such breakpoints are inserted directly
    as raw breakpoints rather than through the normal chain of
    breakpoints, we fail to notice that one of the user breakpoints points
    to the same address and that this user breakpoint is therefore
    effectively un-inserted.  When resuming after the single-step, GDB
    thinks that the user breakpoint is still inserted and therefore does
    not need to insert it again.

    This patch teaches the insert and remove routines of both regular and
    raw breakpoints to be aware of each other.  Special care needs to be
    applied in case the target supports evaluation of breakpoint
    conditions or commands.

    gdb/ChangeLog:

        PR breakpoints/17000
        * breakpoint.c (find_non_raw_software_breakpoint_inserted_here):
        New function, extracted from software_breakpoint_inserted_here_p.
        (software_breakpoint_inserted_here_p): Replace factored out code
        by call to find_non_raw_software_breakpoint_inserted_here.
        (bp_target_info_copy_insertion_state): New function.
        (bkpt_insert_location): Handle the case of a single-step
        breakpoint already inserted at the same address.
        (bkpt_remove_location): Handle the case of a single-step
        breakpoint still inserted at the same address.
        (deprecated_insert_raw_breakpoint): Handle the case of non-raw
        breakpoint already inserted at the same address.
        (deprecated_remove_raw_breakpoint): Handle the case of a
        non-raw breakpoint still inserted at the same address.
        (find_single_step_breakpoint): New function, extracted from
        single_step_breakpoint_inserted_here_p.
        (find_single_step_breakpoint): New function,
        factored out from single_step_breakpoint_inserted_here_p.
        (single_step_breakpoint_inserted_here_p): Reimplement.

    gdb/testsuite/ChangeLog:

        PR breakpoints/17000
        * gdb.base/sss-bp-on-user-bp.exp: Remove kfail.
        * gdb.base/sss-bp-on-user-bp-2.exp: Remove kfail.

    Tested on ppc-aix with AdaCore's testsuite.  Tested on x86_64-linux,
    (native and gdbserver) with the official testsuite.  Also tested on
    x86_64-linux through Pedro's branch enabling software single-stepping
    on that platform (native and gdbserver).

-----------------------------------------------------------------------

Summary of changes:
 gdb/ChangeLog                                  |   23 ++++
 gdb/breakpoint.c                               |  141 +++++++++++++++++++++---
 gdb/testsuite/ChangeLog                        |    7 +
 gdb/testsuite/gdb.base/sss-bp-on-user-bp-2.exp |    1 -
 gdb/testsuite/gdb.base/sss-bp-on-user-bp.exp   |    3 +-
 5 files changed, 155 insertions(+), 20 deletions(-)

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

[Bug breakpoints/17000] user breakpoint not inserted if software-single-step at same location

[palves at redhat dot com]

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

Pedro Alves <palves at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED
   Target Milestone|---                         |7.8

--- Comment #4 from Pedro Alves <palves at redhat dot com> ---
Fixed.

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

[Bug breakpoints/17000] user breakpoint not inserted if software-single-step at same location

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "gdb and binutils".

The branch, master has been updated
       via  03388bb71c1a1d1c613bb963f3d9287cfd100138 (commit)
      from  ac21917f6bef764c73323c8117d293b5f6c70228 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

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

commit 03388bb71c1a1d1c613bb963f3d9287cfd100138
Author: Yao Qi <yao@codesourcery.com>
Date:   Wed Jun 4 13:03:19 2014 +0800

    Tweak sss-bp-on-user-bp.exp

    sss-bp-on-user-bp.c has an assumption that write to integer can be
    compiled to a single instruction, which isn't true on some arch, such
    as arm.  This test requires setting two breakpoints on two consecutive
    instructions, so this patch is to get the address of the next
    instruction via disassemble and set the 2nd breakpoint there.  This
    approach is portable.

    This patch fixes the fails in sss-bp-on-user-bp.exp on arm-none-abi
    target.  There is no change in x86 test results.  I also revert the
    patch to PR breakpoints/17000, and verified that the patched
    sss-bp-on-user-bp.exp still trigger the fail on
    x86-with-software-single-step.

    gdb/testsuite:

    2014-06-04  Yao Qi  <yao@codesourcery.com>

        * gdb.base/sss-bp-on-user-bp.c (main): Remove comments.
        * gdb.base/sss-bp-on-user-bp.exp: Don't set breakpoint on
        "set bar break here".  Get the next instruction address and
        set breakpoint there.  Remove "bar break" from the regexp
        patterns.

-----------------------------------------------------------------------

Summary of changes:
 gdb/testsuite/gdb.base/sss-bp-on-user-bp.c   |    4 ++--
 gdb/testsuite/gdb.base/sss-bp-on-user-bp.exp |   20 +++++++++++++++++---
 2 files changed, 19 insertions(+), 5 deletions(-)

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