This applies the second part of GDB's End of Year Procedure, which
updates the copyright year range in all of GDB's files.
gdb/ChangeLog:
Update copyright year range in all GDB files.
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.
This patch updates tests for fork and exec events in target remote mode.
In the majority of cases this was a simple matter of removing some code
that disabled the test for target remote. In a few cases the test needed
to be disabled; in those cases the gdb_protocol was checked instead of
using the [is_remote target] etc.
In a couple of cases we needed to use clean_restart, since target remote
doesn't support the run command, and in one case we had to modify an expect
expression to allow for a "multiprocess-style" ptid.
Tested with the patch that implemented target remote mode fork and exec
event support.
gdb/testsuite/ChangeLog:
* gdb.base/execl-update-breakpoints.exp (main): Enable for target
remote.
* gdb.base/foll-exec-mode.exp (main): Disable for target remote.
* gdb.base/foll-exec.exp (main): Enable for target remote.
* gdb.base/foll-fork.exp (main): Likewise.
* gdb.base/foll-vfork.exp (main): Likewise.
* gdb.base/multi-forks.exp (main): Likewise, and use clean_restart.
(proc continue_to_exit_bp_loc): Use clean_restart.
* gdb.base/pie-execl.exp (main): Disable for target remote.
* gdb.base/watch-vfork.exp (main): Enable for target remote.
* gdb.mi/mi-nsthrexec.exp (main): Likewise.
* gdb.threads/execl.exp (main): Likewise.
* gdb.threads/fork-child-threads.exp (main): Likewise.
* gdb.threads/fork-plus-threads.exp (main): Disable for target
remote.
* gdb.threads/fork-thread-pending.exp (main): Enable for target
remote.
* gdb.threads/linux-dp.exp (check_philosopher_stack): Allow
pid.tid style ptids, instead of just tid.
* gdb.threads/thread-execl.exp (main): Enable for target remote.
* gdb.threads/watchpoint-fork.exp (main): Likewise.
* gdb.trace/report.exp (use_collected_data): Allow pid.tid style
ptids, instead of just tid.
The test case builds two copies of the program, one with the compile
option "ldflags=-Wl,-Ttext=0x1000000" and the other with the address
changed to 0x2000000. However, when linking with ld.bfd, the
resulting executables crash early in ld.so on S390 and i386.
Analysis of the crash: The default linker script establishes a certain
order of loadable sections, and the option "-Ttext" effectively splits
these into an "unaffected" lot (everything before .text) and an
"affected" lot. The affected lot is placed at the given address,
whereas the unaffected lot stays at its default address. The
unaffected lot starts at an aligned address plus Elf header sizes,
which is good if it is the first LOAD segment (like on AMD64). But if
the affected lot comes first instead (like on S390 and i386), the PHDR
doesn't fit there and is placed *outside* any LOAD segments. Then the
PHDR is not mapped when the loader gets control, and the loader runs
into a segmentation fault while trying to access it.
Since we are lucky about the order of segments on AMD64, the test
succeeds there, but the resulting binaries are unusually large -- 2.1M
each, with lots of padding within.
When replacing '-Ttext' by '-Ttext-segment', the linker moves all
segments consistently, the binaries have normal sizes, and the test
case succeeds on all mentioned platforms.
Since old versions of the gold linker don't support '-Ttext-segment',
the patch also adds logic for falling back to '-Ttext'.
gdb/testsuite/ChangeLog:
* gdb.base/execl-update-breakpoints.exp: Specify the link address
with '-Ttext-segment' instead of '-Ttext'. Fall back to '-Ttext'
if the linker doesn't understand this.
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.
Joel Brobecker
Luis Machado
Pedro Alves
Don Breazeal
Andreas Arnez