public inbox for gdb-prs@sourceware.org
help / color / mirror / Atom feed
* [Bug breakpoints/17431] New: follow-exec, "always-inserted on", breakpoints inserted too soon
@ 2014-09-24 14:57 palves at redhat dot com
  2014-09-24 14:58 ` [Bug breakpoints/17431] " palves at redhat dot com
                   ` (3 more replies)
  0 siblings, 4 replies; 5+ messages in thread
From: palves at redhat dot com @ 2014-09-24 14:57 UTC (permalink / raw)
  To: gdb-prs

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

            Bug ID: 17431
           Summary: follow-exec, "always-inserted on", breakpoints
                    inserted too soon
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: breakpoints
          Assignee: unassigned at sourceware dot org
          Reporter: palves at redhat dot com

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

With "always-inserted off", we see:

gdb testsuite/gdb.multi/multi-arch-exec -ex "set breakpoint always-inserted
off" -ex "cd testsuite"
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, but is 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)

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


^ permalink raw reply	[flat|nested] 5+ messages in thread

* [Bug breakpoints/17431] follow-exec, "always-inserted on", breakpoints inserted too soon
  2014-09-24 14:57 [Bug breakpoints/17431] New: follow-exec, "always-inserted on", breakpoints inserted too soon palves at redhat dot com
@ 2014-09-24 14:58 ` palves at redhat dot com
  2014-09-25 16:32 ` palves at redhat dot com
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 5+ messages in thread
From: palves at redhat dot com @ 2014-09-24 14:58 UTC (permalink / raw)
  To: gdb-prs

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

Pedro Alves <palves at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at sourceware dot org   |palves at redhat dot com

--- Comment #1 from Pedro Alves <palves at redhat dot com> ---
I've got a patch.

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


^ permalink raw reply	[flat|nested] 5+ messages in thread

* [Bug breakpoints/17431] follow-exec, "always-inserted on", breakpoints inserted too soon
  2014-09-24 14:57 [Bug breakpoints/17431] New: follow-exec, "always-inserted on", breakpoints inserted too soon palves at redhat dot com
  2014-09-24 14:58 ` [Bug breakpoints/17431] " palves at redhat dot com
@ 2014-09-25 16:32 ` palves at redhat dot com
  2014-10-02  9:08 ` cvs-commit at gcc dot gnu.org
  2014-10-02 16:14 ` palves at redhat dot com
  3 siblings, 0 replies; 5+ messages in thread
From: palves at redhat dot com @ 2014-09-25 16:32 UTC (permalink / raw)
  To: gdb-prs

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

Pedro Alves <palves at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED

--- Comment #2 from Pedro Alves <palves at redhat dot com> ---
https://sourceware.org/ml/gdb-patches/2014-09/msg00733.html

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


^ permalink raw reply	[flat|nested] 5+ messages in thread

* [Bug breakpoints/17431] follow-exec, "always-inserted on", breakpoints inserted too soon
  2014-09-24 14:57 [Bug breakpoints/17431] New: follow-exec, "always-inserted on", breakpoints inserted too soon palves at redhat dot com
  2014-09-24 14:58 ` [Bug breakpoints/17431] " palves at redhat dot com
  2014-09-25 16:32 ` palves at redhat dot com
@ 2014-10-02  9:08 ` cvs-commit at gcc dot gnu.org
  2014-10-02 16:14 ` palves at redhat dot com
  3 siblings, 0 replies; 5+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2014-10-02  9:08 UTC (permalink / raw)
  To: gdb-prs

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.


^ permalink raw reply	[flat|nested] 5+ messages in thread

* [Bug breakpoints/17431] follow-exec, "always-inserted on", breakpoints inserted too soon
  2014-09-24 14:57 [Bug breakpoints/17431] New: follow-exec, "always-inserted on", breakpoints inserted too soon palves at redhat dot com
                   ` (2 preceding siblings ...)
  2014-10-02  9:08 ` cvs-commit at gcc dot gnu.org
@ 2014-10-02 16:14 ` palves at redhat dot com
  3 siblings, 0 replies; 5+ messages in thread
From: palves at redhat dot com @ 2014-10-02 16:14 UTC (permalink / raw)
  To: gdb-prs

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

Pedro Alves <palves at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |7.9

--- 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.


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2014-10-02 16:14 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-09-24 14:57 [Bug breakpoints/17431] New: follow-exec, "always-inserted on", breakpoints inserted too soon palves at redhat dot com
2014-09-24 14:58 ` [Bug breakpoints/17431] " palves at redhat dot com
2014-09-25 16:32 ` palves at redhat dot com
2014-10-02  9:08 ` cvs-commit at gcc dot gnu.org
2014-10-02 16:14 ` palves at redhat dot com

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).