[Bug breakpoints/17431] follow-exec, "always-inserted on", breakpoints inserted too soon

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

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

--- 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  13fd3ff34329b882503c7c1ef44b3656d6ebb022 (commit)
      from  32990adaadc1b119700cd0dfd2dd8849114e0135 (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=13fd3ff34329b882503c7c1ef44b3656d6ebb022

commit 13fd3ff34329b882503c7c1ef44b3656d6ebb022
Author: Pedro Alves <palves@redhat.com>
Date:   Thu Oct 2 09:55:38 2014 +0100

    PR17431: following execs with "breakpoint always-inserted on"

    Following an exec with "breakpoint always-inserted on" tries to insert
    breakpoints in the new image at the addresses the symbols had in the
    old image.

    With "always-inserted off", we see:

     gdb gdb.multi/multi-arch-exec -ex "set breakpoint always-inserted off"
     GNU gdb (GDB) 7.8.50.20140924-cvs
     ...
     (gdb) b main
     Breakpoint 1 at 0x400664: file gdb.multi/multi-arch-exec.c, line 24.
             ^^^^^^^^
     (gdb) c
     The program is not being run.
     (gdb) r
     Starting program: testsuite/gdb.multi/multi-arch-exec

     Breakpoint 1, main () at gdb/testsuite/gdb.multi/multi-arch-exec.c:24
     24        execl (BASEDIR "/multi-arch-exec-hello",
     (gdb) c
     Continuing.
     process 9212 is executing new program:
gdb/testsuite/gdb.multi/multi-arch-exec-hello

     Breakpoint 1, main () at gdb/testsuite/gdb.multi/hello.c:40
     40        bar();
     (gdb) info breakpoints
     Num     Type           Disp Enb Address    What
     1       breakpoint     keep y   0x080484e4 in main at
gdb/testsuite/gdb.multi/hello.c:40
                     ^^^^^^^^^^
         breakpoint already hit 2 times
     (gdb)

    Note how main was 0x400664 in multi-arch-exec, and 0x080484e4 in
    gdb.multi/hello.

    With "always-inserted on", we get:

     Breakpoint 1, main () at gdb/testsuite/gdb.multi/multi-arch-exec.c:24
     24        execl (BASEDIR "/multi-arch-exec-hello",
     (gdb) c
     Continuing.
     infrun: target_wait (-1, status) =
     infrun:   9444 [process 9444],
     infrun:   status->kind = execd
     infrun: infwait_normal_state
     infrun: TARGET_WAITKIND_EXECD
     Warning:
     Cannot insert breakpoint 1.
     Cannot access memory at address 0x400664

    (gdb)

    That is, GDB is trying to insert a breakpoint at 0x400664, after the
    exec, and then that address happens to not be mapped at all in the new
    image.

    The problem is that update_breakpoints_after_exec is creating
    breakpoints, which ends up in update_global_location_list immediately
    inserting breakpoints if "breakpoints always-inserted" is "on".
    update_breakpoints_after_exec is called very early when we see an exec
    event.  At that point, we haven't loaded the symbols of the new
    post-exec image yet, and thus haven't reset breakpoint's addresses to
    whatever they may be in the new image.  All we should be doing in
    update_breakpoints_after_exec is deleting breakpoints that no longer
    make sense after an exec.  So the fix removes those breakpoint
    creations.

    The question is then, if not here, where are those breakpoints
    re-created?  Turns out we don't need to do anything else, because at
    the end of follow_exec, we call breakpoint_re_set, whose tail is also
    creating exactly the same breakpoints update_breakpoints_after_exec is
    currently creating:

      breakpoint_re_set (void)
      {
      ...
        create_overlay_event_breakpoint ();
        create_longjmp_master_breakpoint ();
        create_std_terminate_master_breakpoint ();
        create_exception_master_breakpoint ();
      }

    A new test is added to exercise this.

    Tested on x86_64 Fedora 20.

    gdb/
    2014-10-02  Pedro Alves  <palves@redhat.com>

        PR breakpoints/17431
        * breakpoint.c (update_breakpoints_after_exec): Don't create
        overlay, longjmp, std terminate nor exception breakpoints here.

    gdb/testsuite/
    2014-10-02  Pedro Alves  <palves@redhat.com>

        PR breakpoints/17431
        * gdb.base/execl-update-breakpoints.c: New file.
        * gdb.base/execl-update-breakpoints.exp: New file.

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

Summary of changes:
 gdb/ChangeLog                                      |    6 +
 gdb/breakpoint.c                                   |    5 -
 gdb/testsuite/ChangeLog                            |    6 +
 gdb/testsuite/gdb.base/execl-update-breakpoints.c  |   38 +++++++
 .../gdb.base/execl-update-breakpoints.exp          |  114 ++++++++++++++++++++
 5 files changed, 164 insertions(+), 5 deletions(-)
 create mode 100644 gdb/testsuite/gdb.base/execl-update-breakpoints.c
 create mode 100644 gdb/testsuite/gdb.base/execl-update-breakpoints.exp

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