old-cross-binutils/gdb/testsuite/gdb.base/execl-update-breakpoints.c

45 lines
1.1 KiB
C
Raw Normal View History

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.
2014-10-02 08:55:38 +00:00
/* This testcase is part of GDB, the GNU debugger.
Copyright 2014-2016 Free Software Foundation, Inc.
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.
2014-10-02 08:55:38 +00:00
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 3 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program. If not, see <http://www.gnu.org/licenses/>. */
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
Fix PR19548: Breakpoint re-set inserts breakpoints when it shouldn't PR19548 shows that we still have problems related to 13fd3ff34329: [PR17431: following execs with "breakpoint always-inserted on"] https://sourceware.org/ml/gdb-patches/2014-09/msg00733.html The problem this time is that we currently update the global location list and try to insert breakpoint locations after re-setting _each_ breakpoint in turn. Say: - We have _more_ than one breakpoint set. Let's assume 2. - There's a breakpoint with a pre-exec address that ends up being an unmapped address after the exec. - That breakpoint is NOT the first in the breakpoint list. Then when handling an exec, and we re-set the first breakpoint in the breakpoint list, we mistakently try to install the old pre-exec / un-re-set locations of the other breakpoint, which fails: (gdb) continue Continuing. process 28295 is executing new program: (...)/execl-update-breakpoints2 Error in re-setting breakpoint 1: Warning: Cannot insert breakpoint 2. Cannot access memory at address 0x1000764 Breakpoint 1, main (argc=1, argv=0x7fffffffd368) at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/execl-update-breakpoints.c:34 34 len = strlen (argv[0]); (gdb) Fix this by deferring the global location list update till after all breakpoints are re-set. Tested on x86_64 Fedora 20, native and gdbserver. gdb/ChangeLog: 2016-02-09 Pedro Alves <palves@redhat.com> PR breakpoints/19548 * breakpoint.c (create_overlay_event_breakpoint): Don't update global location list here. (create_longjmp_master_breakpoint) (create_std_terminate_master_breakpoint) (create_exception_master_breakpoint, create_jit_event_breakpoint) (update_breakpoint_locations): (breakpoint_re_set): Update global location list after all breakpoints are re-set. gdb/testsuite/ChangeLog: 2016-02-09 Pedro Alves <palves@redhat.com> PR breakpoints/19548 * gdb.base/execl-update-breakpoints.c (some_function): New function. (main): Call it. * gdb.base/execl-update-breakpoints.exp: Add a second breakpoint. Tighten expected GDB output.
2016-02-09 12:12:17 +00:00
void
some_function (void)
{
}
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.
2014-10-02 08:55:38 +00:00
int
main (int argc, char **argv)
{
size_t len;
char *bin;
len = strlen (argv[0]);
bin = malloc (len + 1);
memcpy (bin, argv[0], len + 1);
if (bin[len - 1] == '1')
bin[len - 1] = '2';
execl (bin, bin, (char *) NULL);
perror ("execl failed");
Fix PR19548: Breakpoint re-set inserts breakpoints when it shouldn't PR19548 shows that we still have problems related to 13fd3ff34329: [PR17431: following execs with "breakpoint always-inserted on"] https://sourceware.org/ml/gdb-patches/2014-09/msg00733.html The problem this time is that we currently update the global location list and try to insert breakpoint locations after re-setting _each_ breakpoint in turn. Say: - We have _more_ than one breakpoint set. Let's assume 2. - There's a breakpoint with a pre-exec address that ends up being an unmapped address after the exec. - That breakpoint is NOT the first in the breakpoint list. Then when handling an exec, and we re-set the first breakpoint in the breakpoint list, we mistakently try to install the old pre-exec / un-re-set locations of the other breakpoint, which fails: (gdb) continue Continuing. process 28295 is executing new program: (...)/execl-update-breakpoints2 Error in re-setting breakpoint 1: Warning: Cannot insert breakpoint 2. Cannot access memory at address 0x1000764 Breakpoint 1, main (argc=1, argv=0x7fffffffd368) at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/execl-update-breakpoints.c:34 34 len = strlen (argv[0]); (gdb) Fix this by deferring the global location list update till after all breakpoints are re-set. Tested on x86_64 Fedora 20, native and gdbserver. gdb/ChangeLog: 2016-02-09 Pedro Alves <palves@redhat.com> PR breakpoints/19548 * breakpoint.c (create_overlay_event_breakpoint): Don't update global location list here. (create_longjmp_master_breakpoint) (create_std_terminate_master_breakpoint) (create_exception_master_breakpoint, create_jit_event_breakpoint) (update_breakpoint_locations): (breakpoint_re_set): Update global location list after all breakpoints are re-set. gdb/testsuite/ChangeLog: 2016-02-09 Pedro Alves <palves@redhat.com> PR breakpoints/19548 * gdb.base/execl-update-breakpoints.c (some_function): New function. (main): Call it. * gdb.base/execl-update-breakpoints.exp: Add a second breakpoint. Tighten expected GDB output.
2016-02-09 12:12:17 +00:00
some_function ();
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.
2014-10-02 08:55:38 +00:00
exit (1);
}