aboutsummaryrefslogtreecommitdiff
path: root/gdb
AgeCommit message (Collapse)AuthorFilesLines
2016-08-25Sync proc_service definition with GLIBCgdb-7.11-branchAdhemerval Zanella22-20/+49
GLIBC BZ#20311 [1] proc_service.h install patch also remove 'const' attributes from ps_get_thread_area and comment #15 discuss why to remove the const attribute (basically since it a callback with the struct ps_prochandle owned by the client it should be able to modify it if it the case). On default build this is not the issue and current g++ does not trigger any issue with this mismatch declaration. However, on some bootstrap build configuration where gdbserver is build with gcc instead this triggers: error: conflicting types for 'ps_get_thread_area' This patch fixes it by syncing the declaration with GLIBC. [1] https://sourceware.org/bugzilla/show_bug.cgi?id=20311 gdb/ChangeLog: 2016-08-25 Adhemerval Zanella <adhemerval.zanella@linaro.org> * aarch64-linux-nat.c (ps_get_thread_area): Remove const from struct ps_prochandle. * amd64-linux-nat.c (ps_get_thread_area): Likewise. * arm-linux-nat.c (ps_get_thread_area): Likewise. * gdb_proc_service.h (ps_get_thread_area): Likewise. * i386-linux-nat.c (ps_get_thread_area): Likewise. * m68klinux-nat.c (ps_get_thread_area): Likewise. * mips-linux-nat.c (ps_get_thread_area): Likewise. * nat/aarch64-linux.c (aarch64_ps_get_thread_area): Likewise. * nat/aarch64-linux.h (aarch64_ps_get_thread_area): Likewise. * xtensa-linux-nat.c (ps_get_thread_area): Likewise. gdb/gdbserver/ChangeLog: 2016-08-25 Adhemerval Zanella <adhemerval.zanella@linaro.org> PR server/20491 * gdb_proc_service.h (ps_get_thread_area): Remove const from struct ps_prochandle. * linux-aarch64-low.c (ps_get_thread_area): Likewise. * linux-arm-low.c (ps_get_thread_area): Likewise. * linux-crisv32-low.c (ps_get_thread_area): Likewise. * linux-m68k-low.c (ps_get_thread_area): Likewise. * linux-mips-low.c (ps_get_thread_area): Likewise. * linux-nios2-low.c (ps_get_thread_area): Likewise. * linux-tic6x-low.c (ps_get_thread_area): Likewise. * linux-x86-low.c (ps_get_thread_area): Likewise. * linux-xtensa-low.c (ps_get_thread_area): Likewise.
2016-05-31Bump GDB version number to 7.11.1.DATE-git.Joel Brobecker2-1/+5
gdb/ChangeLog: * version.in: Set GDB version number to 7.11.1.DATE-git.
2016-05-31Document the GDB 7.11.1 release in gdb/ChangeLogJoel Brobecker1-0/+4
gdb/ChangeLog: GDB 7.11.1 released.
2016-05-31Set GDB version number to 7.11.1.gdb-7.11.1-releaseJoel Brobecker2-1/+5
gdb/ChangeLog: * version.in: Set GDB version number to 7.11.1.
2016-05-25Fix PR gdb/19828: gdb -p <process from a container>: internal errorPedro Alves6-0/+191
When GDB attaches to a process, it looks at the /proc/PID/task/ dir for all clone threads of that process, and attaches to each of them. Usually, if there is more than one clone thread, it means the program is multi threaded and linked with pthreads. Thus when GDB soon after attaching finds and loads a libthread_db matching the process, it'll add a thread to the thread list for each of the initially found lower-level LWPs. If, however, GDB fails to find/load a matching libthread_db, nothing is adding the LWPs to the thread list. And because of that, "detach" hits an internal error: (gdb) PASS: gdb.threads/clone-attach-detach.exp: fg attach 1: attach info threads Id Target Id Frame * 1 LWP 6891 "clone-attach-de" 0x00007f87e5fd0790 in __nanosleep_nocancel () at ../sysdeps/unix/syscall-template.S:84 (gdb) FAIL: gdb.threads/clone-attach-detach.exp: fg attach 1: info threads shows two LWPs detach .../src/gdb/thread.c:1010: internal-error: is_executing: Assertion `tp' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) FAIL: gdb.threads/clone-attach-detach.exp: fg attach 1: detach (GDB internal error) From here: ... #8 0x00000000007ba7cc in internal_error (file=0x98ea68 ".../src/gdb/thread.c", line=1010, fmt=0x98ea30 "%s: Assertion `%s' failed.") at .../src/gdb/common/errors.c:55 #9 0x000000000064bb83 in is_executing (ptid=...) at .../src/gdb/thread.c:1010 #10 0x00000000004c23bb in get_pending_status (lp=0x12c5cc0, status=0x7fffffffdc0c) at .../src/gdb/linux-nat.c:1235 #11 0x00000000004c2738 in detach_callback (lp=0x12c5cc0, data=0x0) at .../src/gdb/linux-nat.c:1317 #12 0x00000000004c1a2a in iterate_over_lwps (filter=..., callback=0x4c2599 <detach_callback>, data=0x0) at .../src/gdb/linux-nat.c:899 #13 0x00000000004c295c in linux_nat_detach (ops=0xe7bd30, args=0x0, from_tty=1) at .../src/gdb/linux-nat.c:1358 #14 0x000000000068284d in delegate_detach (self=0xe7bd30, arg1=0x0, arg2=1) at .../src/gdb/target-delegates.c:34 #15 0x0000000000694141 in target_detach (args=0x0, from_tty=1) at .../src/gdb/target.c:2241 #16 0x0000000000630582 in detach_command (args=0x0, from_tty=1) at .../src/gdb/infcmd.c:2975 ... Tested on x86-64 Fedora 23. Also confirmed the test passes against gdbserver with "maint set target-non-stop". Unfortunately, making GDB add LWPs to the thread list sooner exposes inefficiencies that in turn result in gdb.threads/attach-many-short-lived-threads.exp timing out frequently. Since that testcase is really a contrived use case designed to stress some aspects of attach/detach and thread listing, not really representative of real programs, this commit disables the test. gdb/ChangeLog: 2016-05-25 Pedro Alves <palves@redhat.com> PR gdb/19828 * linux-nat.c (attach_proc_task_lwp_callback): Mark the lwp resumed, and add the thread to GDB's thread list. testsuite/ChangeLog: 2016-05-25 Pedro Alves <palves@redhat.com> PR gdb/19828 * gdb.threads/clone-attach-detach.c: New file. * gdb.threads/clone-attach-detach.exp: New file. * gdb.threads/attach-many-short-lived-threads.exp: Skip.
2016-05-25Make gdb/linux-nat.c consider a waitstatus pending on the infrun sidePedro Alves2-1/+11
Working on the fix for gdb/19828, I saw gdb.threads/attach-many-short-lived-threads.exp fail once in an unusual way. Unfortunately I didn't keep debug logs, but it's an issue similar to what's been fixed in remote.c a while ago -- linux-nat.c was not fetching the pending status from the right place. gdb/ChangeLog: 2016-05-25 Pedro Alves <palves@redhat.com> PR gdb/19828 * linux-nat.c (get_pending_status): If the thread reported the event to the core and it's pending, use the pending status signal number.
2016-05-18Add mi-threads-interrupt.exp test (PR 20039)Simon Marchi3-0/+135
Add a new test for PR 20039. The test spawns new threads, then tries to interrupt, continue, and interrupt again. This use case was fixed by commit 5fe966540d6b748f825774868463003700f0c878 in master, but gdb 7.11 is affected (so if you try it on the gdb-7.11-branch right now, the test will fail). New in v2, the test now handles mi-async on mode properly. The failure was specific to mi-async off, but I don't think it's bad to test the same thing under async on mode. I added a little hack when running in async mode to work around bug 20045. I also removed one continue/interrupt pair, as a single one was enough to trigger the problem. gdb/testsuite/ChangeLog: * gdb.mi/mi-threads-interrupt.c: New file. * gdb.mi/mi-threads-interrupt.exp: New file.
2016-05-18Fix double prompt output after run control MI commands with mi-async on (PR ↵Simon Marchi2-1/+7
20045) When you use a run control command (-exec-run, -exec-continue, -exec-next, ...) with mi-async on, an extra (gdb) prompt is displayed: -exec-continue ^running *running,thread-id="all" (gdb) (gdb) It doesn't seem to be a big problem for front-ends, since this behavior started in gdb 7.9 and we haven't heard anything about that. However, it caused me some trouble while writing a test for PR 20039 [1]. The problem comes from an extra (gdb) prompt that we write when running in mi-async off mode to emulate a past buggy behavior. When executing a run control command synchronously, previous gdbs always printed a prompt right away, even though they are not ready to accept new MI commands until the target stops. Only at this time should they display a prompt. But to keep backwards compatibility apparently, we print it anyway. Since commit 198297aaf, the condition that decides whether we should print that "bogus" prompt or not has become true, even when running with mi-async on. Since we already print a prompt at the end of the asynchronous command execution, it results in two prompts for one command. The proposed fix is to call target_can_async_p instead of target_is_async_p, to make the condition: if (!target_can_async_p () || sync_execution) ... show prompt ... That shows the prompt if we are emulating a synchronous command on top of an asynchronous target (sync_execution) or if the target simply can't run asynchronously (!target_can_async_p ()). Note that this code is changed and this bug fixed by Pedro's separate console series, but I think it would be nice to have it fixed in the mean time. I ran the gdb.mi directory of the testsuite with mi-async on and off, I didn't see any regressions. gdb/ChangeLog: * mi/mi-main.c (mi_on_resume): Call target_can_async_p instead of target_is_async_p. [1] https://sourceware.org/ml/gdb-patches/2016-05/msg00075.html
2016-05-17Fix -exec-run not running asynchronously with mi-async on (PR gdb/18077)Simon Marchi5-4/+102
When doing -exec-run on a freshly started GDB, the only target on the target stack at the time the dummy one. When mi_async_p is called to know whether the run should be async, it queries whether the current target (dummy) supports async, and the answer is no. The fix is to make the code query the target that will be used for the run, which is not necessarily the current target. No regressions in the gdb.mi directory using the unix, native-gdbserver and native-extended-gdbserver boards. The test doesn't pass when forcing maint set target-async off, obviously, since it makes mi-async have no effect. It doesn't seem like other tests are checking for that eventuality, so I didn't in the new test. gdb/ChangeLog: * mi/mi-main.c (run_one_inferior): Use run target to determine whether to run async or not. (mi_cmd_exec_run): Likewise. gdb/testsuite/ChangeLog: * gdb.mi/mi-async-run.exp: New file. * gdb.mi/mi-async-run.c: New file.
2016-05-16Use target_terminal_ours_for_output in MIPedro Alves3-21/+130
The MI code only does output, so leave raw/cooked mode alone, as well as the SIGINT handler. Restore terminal settings after output, while at it. Also, a couple events missed calling target_terminal_ours before output, even. [Backported to the 7.11 branch by Simon Marchi, as it fixes PR 20039.] gdb/ChangeLog: YYYY-MM-DD Pedro Alves <palves@redhat.com> * mi/mi-interp.c (mi_new_thread): Put target_terminal_ours_for_output in effect while outputting. (mi_thread_exit): Use target_terminal_ours_for_output instead of target_terminal_ours. (mi_record_changed, mi_inferior_added, mi_inferior_appeared) (mi_inferior_exit, mi_inferior_removed, mi_traceframe_changed) (mi_tsv_created, mi_tsv_deleted, mi_tsv_modified) (mi_breakpoint_created, mi_breakpoint_deleted) (mi_breakpoint_modified, mi_solib_loaded, mi_solib_unloaded) (mi_command_param_changed, mi_memory_changed) (report_initial_inferior): Use target_terminal_ours_for_output instead of target_terminal_ours. Restore terminal settings. * mi/mi-main.c (mi_execute_command): Use target_terminal_ours_for_output instead of target_terminal_ours. Restore terminal settings.
2016-05-03Fix gdb/python/python.c use-after-freePedro Alves2-1/+10
Valgrind shows: ==26964== Invalid read of size 1 ==26964== at 0x6E14100: __GI_strcmp (strcmp.S:180) ==26964== by 0x6DB55AA: setlocale (setlocale.c:238) ==26964== by 0x4E0455: _initialize_python() (python.c:1731) ==26964== by 0x786731: initialize_all_files() (init.c:319) ==26964== by 0x72EF0A: gdb_init(char*) (top.c:1929) ==26964== by 0x60BCAC: captured_main(void*) (main.c:863) ==26964== by 0x606AD5: catch_errors(int (*)(void*), void*, char*, return_mask) (exceptions.c:234) ==26964== by 0x60C608: gdb_main(captured_main_args*) (main.c:1165) ==26964== by 0x40CAEC: main (gdb.c:32) ==26964== Address 0x81d30a0 is 0 bytes inside a block of size 181 free'd ==26964== at 0x4C29CF0: free (vg_replace_malloc.c:530) ==26964== by 0x6DB5B65: setname (setlocale.c:201) ==26964== by 0x6DB5B65: setlocale (setlocale.c:388) ==26964== by 0x4E037F: _initialize_python() (python.c:1712) ==26964== by 0x786731: initialize_all_files() (init.c:319) ==26964== by 0x72EF0A: gdb_init(char*) (top.c:1929) ==26964== by 0x60BCAC: captured_main(void*) (main.c:863) ==26964== by 0x606AD5: catch_errors(int (*)(void*), void*, char*, return_mask) (exceptions.c:234) ==26964== by 0x60C608: gdb_main(captured_main_args*) (main.c:1165) ==26964== by 0x40CAEC: main (gdb.c:32) The problem is doing this: oldloc = setlocale (LC_ALL, NULL); setlocale (LC_ALL, ""); ... setlocale (LC_ALL, oldloc); I.e., the second setlocale call frees 'oldloc'. From http://pubs.opengroup.org/onlinepubs/9699919799/functions/setlocale.html : "The returned string pointer might be invalidated or the string content might be overwritten by a subsequent call to setlocale()." gdb/ChangeLog: 2016-05-03 Pedro Alves <palves@redhat.com> PR python/20037 * python/python.c (_initialize_python) [IS_PY3K]: xstrdup/xfree oldloc.
2016-05-03Remove gdb/python/python.c code that handles strlen failing with -1Pedro Alves2-5/+5
This makes no sense -- strlen doesn't really ever fail with -1. gdb/ChangeLog: 2016-05-03 Pedro Alves <palves@redhat.com> * python/python.c (_initialize_python) [IS_PY3K]: Remove dead code.
2016-05-03[gdb] Fix -Wparentheses warningsKyrylo Tkachov2-37/+50
2016-05-03 Kyrylo Tkachov <kyrylo.tkachov@arm.com> * symfile.c (find_pc_overlay): Add braces to avoid -Wparentheses warning. (find_pc_mapped_section): Likewise. (list_overlays_command): Likewise.
2016-04-27Workaround gdbserver<7.7 for setfsJan Kratochvil2-0/+23
With current FSF GDB HEAD and old FSF gdbserver I expected I could do: gdb -ex 'file target:/root/redhat/threadit' -ex 'target remote :1234' (supplying that unsupported qXfer:exec-file:read by "file") But that does not work because: Sending packet: $vFile:setfs:0#bf...Packet received: OK Packet vFile:setfs (hostio-setfs) is supported ... Sending packet: $vFile:setfs:104#24...Packet received: OK "target:/root/redhat/threadit": could not open as an executable file: Invalid argument GDB documentation says: The valid responses to Host I/O packets are: An empty response indicates that this operation is not recognized. This "empty response" vs. "OK" was a bug in gdbserver < 7.7. It was fixed by: commit e7f0d979dd5cc4f8b658df892e93db69d6d660b7 Author: Yao Qi <yao@codesourcery.com> Date: Tue Dec 10 21:59:20 2013 +0800 Fix a bug in matching notifications. Message-ID: <1386684626-11415-1-git-send-email-yao@codesourcery.com> https://sourceware.org/ml/gdb-patches/2013-12/msg00373.html 2013-12-10 Yao Qi <yao@codesourcery.com> * notif.c (handle_notif_ack): Return 0 if no notification matches. with unpatched old FSF gdbserver and patched FSF GDB HEAD: gdb -ex 'file target:/root/redhat/threadit' -ex 'target remote :1234' Sending packet: $vFile:setfs:0#bf...Packet received: OK Packet vFile:setfs (hostio-setfs) is NOT supported ... (gdb) info sharedlibrary From To Syms Read Shared Object Library 0x00007ffff7ddbae0 0x00007ffff7df627a Yes (*) target:/lib64/ld-linux-x86-64.so.2 0x00007ffff7bc48a0 0x00007ffff7bcf514 Yes (*) target:/lib64/libpthread.so.0 gdb/ChangeLog 2016-04-27 Jan Kratochvil <jan.kratochvil@redhat.com> * remote.c (remote_start_remote): Detect PACKET_vFile_setfs.support.
2016-04-16MIPS/Linux: Also recognize TRAP_BRKPT and TRAP_HWBKPTPedro Alves2-4/+13
This makes the MIPS Linux backends recognize TRAP_BRKPT and TRAP_HWBKPT in siginfo.si_code in addition to SI_KERNEL, since Linux 4.6 now reports the finer-grained si_code values too. Refs: https://sourceware.org/ml/gdb-patches/2016-02/msg00756.html https://sourceware.org/ml/gdb-patches/2016-04/msg00090.html On kernels that report SI_KERNEL (<= 4.5), we'll enter the "ambiguous" path of save_stop_reason: if (GDB_ARCH_IS_TRAP_BRKPT (siginfo.si_code) && GDB_ARCH_IS_TRAP_HWBKPT (siginfo.si_code)) { /* The si_code is ambiguous on this arch -- check debug registers. */ if (!check_stopped_by_watchpoint (lp)) lp->stop_reason = TARGET_STOPPED_BY_SW_BREAKPOINT; } while on kernels that report the finer-grained si_code values (>= 4.6), we'll enter the corresponding branches: else if (GDB_ARCH_IS_TRAP_BRKPT (siginfo.si_code)) { } else if (GDB_ARCH_IS_TRAP_HWBKPT (siginfo.si_code)) { ... gdb/ChangeLog: 2016-04-15 Pedro Alves <palves@redhat.com> * nat/linux-ptrace.h [__mips__] (GDB_ARCH_IS_TRAP_BRKPT): Also accept TRAP_BRKPT. [__mips__] (GDB_ARCH_IS_TRAP_HWBKPT): Also accept TRAP_HWBKPT.
2016-04-16Handle MIPS Linux SIGTRAP siginfo.si_code valuesPedro Alves5-185/+203
This unbreaks pending/delayed breakpoints handling, as well as hardware watchpoints, on MIPS. Ref: https://sourceware.org/ml/gdb-patches/2016-02/msg00681.html The MIPS kernel reports SI_KERNEL for all kernel generated traps, instead of TRAP_BRKPT / TRAP_HWBKPT, but GDB isn't aware of this. Basically, this commit: - Folds watchpoints logic into check_stopped_by_breakpoint, and renames it to save_stop_reason. - Adds GDB_ARCH_IS_TRAP_HWBKPT. - Makes MIPS set both GDB_ARCH_IS_TRAP_BRPT and GDB_ARCH_IS_TRAP_HWBKPT to SI_KERNEL. In save_stop_reason, we handle the case of the same si_code returning true for both TRAP_BRPT and TRAP_HWBKPT by looking at what the debug registers say. Tested on x86-64 Fedora 20, native and gdbserver. gdb/ChangeLog: 2016-04-15 Pedro Alves <palves@redhat.com> * linux-nat.c (save_sigtrap) Delete. (stop_wait_callback): Call save_stop_reason instead of save_sigtrap. (check_stopped_by_breakpoint): Rename to ... (save_stop_reason): ... this. Bits of save_sigtrap folded here. Use GDB_ARCH_IS_TRAP_HWBKPT and handle ambiguous GDB_ARCH_IS_TRAP_BRKPT / GDB_ARCH_IS_TRAP_HWBKPT. Factor out common code between the USE_SIGTRAP_SIGINFO and !USE_SIGTRAP_SIGINFO blocks. (linux_nat_filter_event): Call save_stop_reason instead of save_sigtrap. * nat/linux-ptrace.h: Check for both SI_KERNEL and TRAP_BRKPT si_code for MIPS. * nat/linux-ptrace.h: Fix "TRAP_HWBPT" typo in x86 table. Add comments on MIPS behavior. (GDB_ARCH_IS_TRAP_HWBKPT): Define for all archs. gdb/gdbserver/ChangeLog: 2016-04-15 Pedro Alves <palves@redhat.com> * linux-low.c (check_stopped_by_breakpoint): Rename to ... (save_stop_reason): ... this. Use GDB_ARCH_IS_TRAP_HWBKPT and handle ambiguous GDB_ARCH_IS_TRAP_BRKPT / GDB_ARCH_IS_TRAP_HWBKPT. Factor out common code between the USE_SIGTRAP_SIGINFO and !USE_SIGTRAP_SIGINFO blocks. (linux_low_filter_event): Call save_stop_reason instead of check_stopped_by_breakpoint and check_stopped_by_watchpoint. Update comments. (linux_wait_1): Update comments.
2016-04-13Fix PR remote/19840: gdb crashes on reverse-stepiPedro Alves2-0/+32
Reverse debugging against a remote target that does reverse debugging itself (with the bs/bc packets) always trips on: (gdb) target remote localhost:... (gdb) reverse-stepi ../../gdb/target.c:602: internal-error: default_execution_direction: to_execution_direction must be implemented for reverse async I missed adding a to_execution_direction method to remote.c in commit 3223143295b5 (Adds target_execution_direction to make record targets support async mode), GDB 7.4 time. Later, GDB 7.8 switched to target-async on by default, making the regression user-visible by default too. Fix is simply to add the missing to_execution_direction implementation to target remote. Tested by Andi Kleen against Simics. gdb/ChangeLog: 2016-04-13 Pedro Alves <palves@redhat.com> PR remote/19840 * remote.c (struct remote_state) <last_resume_exec_dir>: New field. (new_remote_state): Default last_resume_exec_dir to EXEC_FORWARD. (remote_open_1): Reset last_resume_exec_dir to EXEC_FORWARD. (remote_resume): Store the last execution direction. (remote_execution_direction): New function. (init_remote_ops): Install it as to_execution_direction target_ops method.
2016-03-31Add regression test for PR gdb/19858 (JIT code registration on attach)Pedro Alves3-10/+97
This test would fail without the previous gdb/jit.c fix: (gdb) attach 23031 Attaching to program: .../build/gdb/testsuite/outputs/gdb.base/jit/jit-main, process 23031 [...] 207 WAIT_FOR_GDB; i = 0; /* gdb break here 1 */ (gdb) PASS: gdb.base/jit.exp: attach: one_jit_test-2: attach set var wait_for_gdb = 0 (gdb) PASS: gdb.base/jit.exp: attach: one_jit_test-2: set var wait_for_gdb = 0 info function ^jit_function All functions matching regular expression "^jit_function": (gdb) FAIL: gdb.base/jit.exp: attach: one_jit_test-2: info function ^jit_function gdb/testsuite/ChangeLog: 2016-03-31 Pedro Alves <palves@redhat.com> PR gdb/19858 * gdb.base/jit-main.c: Include unistd.h. (ATTACH): Define to 0 if not already defined. (wait_for_gdb, mypid): New globals. (WAIT_FOR_GDB): New macro. (MAIN): Set an alarm. Store the process's pid. Wait for GDB at some breakpoint locations. * gdb.base/jit.exp (clean_reattach, continue_to_test_location): New procedures. (one_jit_test): Add REATTACH parameter, and handle it. Use continue_to_test_location. (top level): Test attach, and adjusts calls to one_jit_test.
2016-03-31Make gdb.base/jit.exp binaries uniquePedro Alves2-9/+17
This testcase compiles the same program and library differently multiple times using the same file names. Make them unique, to make it easier to debug test problems. gdb/testsuite/ChangeLog: 2016-03-31 Pedro Alves <palves@redhat.com> PR gdb/19858 * gdb.base/jit.exp (compile_jit_test): Add intro comment. Add BINSUFFIX parameter, and handle it. (top level): Adjust calls compile_jit_test.
2016-03-31Fix PR gdb/19858: GDB doesn't register the JIT libraries on attachYichao Yu2-2/+20
Ref: https://sourceware.org/ml/gdb/2016-03/msg00023.html GDB currently fails to fetch the list of already-registered JIT modules on attach. Nothing is calling jit_inferior_init, which is what is responsible for walking the JIT object list at init time. Despite the misleading naming, jit_inferior_created_hook -> jit_inferior_init is only called when the inferior execs. This regressed with the fix for PR gdb/13431 (03bef283c2d3): https://sourceware.org/ml/gdb-patches/2012-02/msg00023.html which removed the inferior_created (jit_inferior_created_observer) observer. Adding an inferior_created observer back fixes the issue. In turn, this exposes a bug in jit_breakpoint_re_set_internal as well, which is returning the wrong result when we already have the breakpoint at the right address. gdb/ChangeLog: 2016-03-31 Yichao Yu <yyc1992@gmail.com> PR gdb/19858 * jit.c (jit_breakpoint_re_set_internal): Return 0 if we already got the breakpoint at the right address. (jit_inferior_created): New function. (_initialize_jit): Install jit_inferior_created as inferior_created observer. Signed-off-by: Pedro Alves <palves@redhat.com>
2016-03-17btrace: fix PR gdb/19829Markus Metzger10-32/+1155
This is a backport of 33b4777ca1b7 btrace, frame: fix crash in get_frame_type a038fa3e14a4 stack: check frame_unwind_caller_id 2f3ef606b912 frame: add skip_tailcall_frames In skip_artificial_frames we repeatedly call get_prev_frame_always until we get a non-inline and non-tailcall frame assuming that there must be such a frame eventually. For record targets, however, we may have a frame chain that consists only of artificial frames. This leads to a crash in get_frame_type when dereferencing a NULL frame pointer. Change skip_artificial_frames and skip_tailcall_frames to return NULL in such a case and modify each caller to cope with a NULL return. In frame_unwind_caller_pc and frame_unwind_caller_arch, we simply assert that the returned value is not NULL. Their caller was supposed to check frame_unwind_caller_id before calling those functions. In other cases, we thrown an error. In infcmd further move the skip_tailcall_frames call to the forward-stepping case since we don't need a frame for reverse execution and we don't want to fail because of that. Reverse-finish does make sense for a tailcall frame. gdb/ * frame.h (skip_tailcall_frames): New. * infcmd.c (finish_command): Call skip_tailcall_frames. * frame.c (skip_artificial_frames): Return NULL if only artificial frames are found. Update comment. (frame_pop): Call skip_tailcall_frames. (frame_unwind_caller_id): Handle NULL return. (frame_unwind_caller_pc, frame_unwind_caller_arch): Assert that skip_artificial_frames does not return NULL. (frame_pop): Add an error if only tailcall frames are found. * infcmd.c (finish_command): Move skip_tailcall_frames call into forward- execution case. Add an error if only tailcall frames are found. * stack.c (frame_info): Check frame_unwind_caller_id. testsuite/ * gdb.btrace/tailcall-only.exp: New. * gdb.btrace/tailcall-only.c: New. * gdb.btrace/x86_64-tailcall-only.S: New. * gdb.btrace/i686-tailcall-only.S: New.
2016-03-15Fix PR gdb/19676: Internal error in linux-thread.db.c if /proc not mountedPedro Alves2-6/+20
If /proc is not mounted, GDB fails an assertion in find_new_threads_once: Continuing. .../src/gdb/linux-thread-db.c:1249: internal-error: find_new_threads_once: Assertion `!target_has_execution' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) That was supposed to catch misuses of td_ta_thr_iter, which is unsafe for live debugging. However, if /proc is not mounted, we still fallback to using it. I didn't bother with a warning, because GDB already prints several others related to failing to open /proc files. gdb/ChangeLog: 2016-03-15 Pedro Alves <palves@redhat.com> PR gdb/19676 * linux-thread-db.c (try_thread_db_load_1): Leave info->td_ta_thr_iter_p NULL iff debugging a live process and we have /proc access. (find_new_threads_once): Assert that we have a non-NULL info->td_ta_thr_iter_p instead of checking whether the target has execution.
2016-03-15Fix PR gdb/19676: Disable displaced stepping if /proc not mountedPedro Alves3-2/+12
On GNU/Linux archs that support displaced stepping, if /proc is not mounted, GDB gets stuck not able to step past breakpoints: (gdb) c Continuing. dl_main (phdr=<optimized out>, phnum=<optimized out>, user_entry=<optimized out>, auxv=<optimized out>) at rtld.c:2163 2163 LIBC_PROBE (init_complete, 2, LM_ID_BASE, r); Cannot find AT_ENTRY auxiliary vector entry. (gdb) c Continuing. dl_main (phdr=<optimized out>, phnum=<optimized out>, user_entry=<optimized out>, auxv=<optimized out>) at rtld.c:2163 2163 LIBC_PROBE (init_complete, 2, LM_ID_BASE, r); Cannot find AT_ENTRY auxiliary vector entry. (gdb) That's because GDB can't figure out where the scratch pad is. This is a regression introduced by the earlier changes to make the Linux native target always work in non-stop mode. This commit makes GDB detect the case and fallback to stepping over breakpoints in-line. gdb/ChangeLog: 2016-03-15 Pedro Alves <palves@redhat.com> PR gdb/19676 * infrun.c (displaced_step_prepare): Also disable displaced stepping on NOT_SUPPORTED_ERROR. * linux-tdep.c (linux_displaced_step_location): If reading auxv fails, throw NOT_SUPPORTED_ERROR instead of generic error.
2016-02-24Bump GDB version number to 7.11.0.DATE-git.Joel Brobecker2-1/+5
gdb/ChangeLog: * version.in: Set GDB version number to 7.11.0.DATE-git.
2016-02-24Document the GDB 7.11 release in gdb/ChangeLogJoel Brobecker1-0/+4
gdb/ChangeLog: GDB 7.11 released.
2016-02-24Set GDB version number to 7.11.gdb-7.11-releaseJoel Brobecker2-1/+5
gdb/ChangeLog: * version.in: Set GDB version number to 7.11.
2016-02-22gdb-gdb.py: SyntaxError: Missing parentheses in call to 'print'Jan Kratochvil2-4/+8
After building GDB --with-python=/usr/bin/python3 and for example stripping ./gdb and running: ./gdb -data-directory data-directory/ -iex "add-auto-load-safe-path $PWD/gdb-gdb.gdb" -iex "add-auto-load-safe-path $PWD/gdb-gdb. py" ./gdb I get: Make breakpoint pending on future shared library load? (y or [n]) [answered N; input not from terminal] File "/home/jkratoch/redhat/gdb-test-python3/gdb/gdb-gdb.py", line 91 print "Warning: Cannot find enum type_flag_value type." ^ SyntaxError: Missing parentheses in call to 'print' (top-gdb) q gdb/ChangeLog 2016-02-22 Jan Kratochvil <jan.kratochvil@redhat.com> * gdb-gdb.py (class TypeFlagsPrinter): Use parentheses for print.
2016-02-16PR remote/19496, internal err forking-threads-plus-bkptDon Breazeal4-7/+18
This patch fixes an internal error that occurs in gdb.threads/forking-threads-plus-breakpoint.exp: /blah/binutils-gdb/gdb/target.c:2723: internal-error: Can't determine the current address space of thread Thread 3170.3170 In default_thread_address_space, find_inferior_ptid couldn't find 3170.3170 because it had been overwritten in inferior_appeared, called as follows: inferior_appeared remote_add_inferior remote_notice_new_inferior remote_update_thread_list The cause of the problem was the following sequence of events: * GDB knows only about the main thread * the first fork event is reported to GDB, saved as pending_event * qXfer:threads:read gets the threads from the remote. remove_new_fork_children id's the fork child from the pending event and removes it from the list reported to GDB. All the rest of the threads, including the fork parent, are added to the GDB thread list. * GDB stops all the threads. All the stop events are pushed onto the stop reply queue behind the pending fork event. The fork waitstatus is saved in the fork parent thread's pending status field thread_info.suspend. * remote_wait_ns calls queued_stop_reply and process_stop_reply to remove the fork event from the front of the stop reply queue and save event information in the thread_info structure for the fork parent thread. Unfortunately, none of the information saved in this way is the fork-specific information. * A subsequent qXfer:threads:read packet gets the thread list including the fork parent and fork child. remove_new_fork_children checks the thread list to see if there is a fork parent, doesn't find one, checks the stop reply queue for a pending fork event, doesn't find one, and allows the fork child thread to be reported to GDB before the fork event has been handled. remote_update_thread_list calls remote_notice_new_thread and overwrites the current (main) thread in inferior_appeared. So the fork event has been reported out of target_wait but it was left pending on the infrun side (infrun.c:save_waitstatus). IOW, the fork event hasn't been processed by handle_inferior_event yet, so it hasn't made it to tp->pending_follow yet. The fix is to check thread_info.suspend along with the thread_info.pending_follow in remote.c:remove_new_fork_children, to prevent premature reporting of the fork child thread creation. gdb/ChangeLog: PR remote/19496 * remote.c (remove_new_fork_children): Check for pending fork status in thread_info.suspend. gdb/testsuite/ChangeLog: PR remote/19496 * gdb.threads/forking-threads-plus-breakpoint.exp (do_test): Remove kfail for PR remote/19496.
2016-02-16Fix cleanup in arm_linux_software_single_stepYao Qi2-1/+8
I see the following error in testing aarch64 GDB debugging arm program. (gdb) PASS: gdb.reverse/readv-reverse.exp: set breakpoint at marker2 continue Continuing. ================================================================= ==32273==ERROR: AddressSanitizer: attempting free on address which was not malloc()-ed: 0x000000ce4c00 in thread T0 #0 0x2ba5615645c7 in __interceptor_free (/usr/lib/x86_64-linux-gnu/libasan.so.1+0x545c7)^M #1 0x4be8b5 in VEC_CORE_ADDR_cleanup /home/yao/SourceCode/gnu/gdb/git/gdb/common/gdb_vecs.h:34^M #2 0x5e6d95 in do_my_cleanups /home/yao/SourceCode/gnu/gdb/git/gdb/common/cleanups.c:154^M #3 0x64c99a in fetch_inferior_event /home/yao/SourceCode/gnu/gdb/git/gdb/infrun.c:3975^M #4 0x678437 in inferior_event_handler /home/yao/SourceCode/gnu/gdb/git/gdb/inf-loop.c:44^M #5 0x5078f6 in remote_async_serial_handler /home/yao/SourceCode/gnu/gdb/git/gdb/remote.c:13223^M #6 0x4cecfd in run_async_handler_and_reschedule /home/yao/SourceCode/gnu/gdb/git/gdb/ser-base.c:137^M #7 0x676864 in gdb_wait_for_event /home/yao/SourceCode/gnu/gdb/git/gdb/event-loop.c:834^M #8 0x676a27 in gdb_do_one_event /home/yao/SourceCode/gnu/gdb/git/gdb/event-loop.c:323^M #9 0x676aed in start_event_loop /home/yao/SourceCode/gnu/gdb/git/gdb/event-loop.c:347^M #10 0x6706d2 in captured_command_loop /home/yao/SourceCode/gnu/gdb/git/gdb/main.c:318^M #11 0x66db8c in catch_errors /home/yao/SourceCode/gnu/gdb/git/gdb/exceptions.c:240^M #12 0x6716dd in captured_main /home/yao/SourceCode/gnu/gdb/git/gdb/main.c:1157^M #13 0x66db8c in catch_errors /home/yao/SourceCode/gnu/gdb/git/gdb/exceptions.c:240^M #14 0x671b7a in gdb_main /home/yao/SourceCode/gnu/gdb/git/gdb/main.c:1165^M #15 0x467684 in main /home/yao/SourceCode/gnu/gdb/git/gdb/gdb.c:32^M #16 0x2ba563ed7ec4 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21ec4)^M #17 0x4676b2 (/scratch/yao/gdb/build-git/aarch64-linux-gnu/gdb/gdb+0x4676b2) looks we should discard cleanup if function arm_linux_software_single_step returns early, or create cleanup when it is needed. gdb: 2016-02-16 Yao Qi <yao.qi@linaro.org> * arm-linux-tdep.c (arm_linux_software_single_step): Assign 'old_chain' later.
2016-02-15Add missing gdb.arch/i386-prologue.c prototypesJan Kratochvil2-0/+8
The testfile has not ran because: gdb.arch/i386-prologue.c:34:3: warning: implicit declaration of function 'standard' [-Wimplicit-function-declaration] standard (); ^ gdb.arch/i386-prologue.c:35:3: warning: implicit declaration of function 'stack_align_ecx' [-Wimplicit-function-declaration] stack_align_ecx (); ^ gdb.arch/i386-prologue.c:36:3: warning: implicit declaration of function 'stack_align_edx' [-Wimplicit-function-declaration] stack_align_edx (); ^ gdb.arch/i386-prologue.c:37:3: warning: implicit declaration of function 'stack_align_eax' [-Wimplicit-function-declaration] stack_align_eax (); ^ gdb/testsuite/ChangeLog 2016-02-15 Jan Kratochvil <jan.kratochvil@redhat.com> * gdb.arch/i386-prologue.c: Add missing prototypes.
2016-02-15Fix more testcases with standard_output_file.Jan Kratochvil4-3/+9
Since commit 2151ccc56c74b55a8f0debf0724a495368f92591 Author: Simon Marchi <simon.marchi@ericsson.com> Date: Mon Feb 8 14:02:36 2016 -0500 Always organize test artifacts in a directory hierarchy these testfiles could not build. gdb/testsuite/ChangeLog 2016-02-15 Jan Kratochvil <jan.kratochvil@redhat.com> * gdb.arch/i386-gnu-cfi.exp: Use standard_output_file. * gdb.arch/i386-prologue.exp: Likewise. * gdb.arch/i386-size.exp: Likewise.
2016-02-15i386-biarch-core.exp: Use standard_output_fileSimon Marchi2-1/+6
Fix the core file path to use the standard output directory. gdb/testsuite/ChangeLog: * i386-biarch-core.exp: Define corefile using standard_output_file.
2016-02-14testsuite: Fix false Fortran regressions with recent gccJan Kratochvil3-12/+18
gcc-4.9.2-6.fc21.x86_64 -> gcc-5.3.1-2.fc23.x86_64 -PASS: gdb.fortran/vla-ptype.exp: ptype pvla not initialized +FAIL: gdb.fortran/vla-ptype.exp: ptype pvla not initialized -PASS: gdb.fortran/vla-history.exp: print vla1 allocated +FAIL: gdb.fortran/vla-history.exp: print vla1 allocated -PASS: gdb.fortran/vla-history.exp: print $2 +FAIL: gdb.fortran/vla-history.exp: print $2 -PASS: gdb.fortran/vla-value.exp: print undefined pvla +FAIL: gdb.fortran/vla-value.exp: print undefined pvla -PASS: gdb.fortran/vla-value.exp: print non-associated &pvla +FAIL: gdb.fortran/vla-value.exp: print non-associated &pvla -PASS: gdb.fortran/vla-value.exp: print undefined pvla(1,3,8) +FAIL: gdb.fortran/vla-value.exp: print undefined pvla(1,3,8) These issues get fixed (or removed if no longer applicable) by attached patch. It is based on Googled: http://www.cs.rpi.edu/~szymansk/OOF90/bugs.html#5 When a pointer is declared its status is undefined, and cannot be safely queried with the associated intrinsic. -> nullify(VARNAME) + https://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/268786 ALLOCATE is not supposed to initialize the array. -> Remove checks like an initial print is: \\( *0, *0, *0...\\) These regressions remain: -PASS: gdb.fortran/library-module.exp: print var_i in lib +FAIL: gdb.fortran/library-module.exp: print var_i in lib -PASS: gdb.fortran/library-module.exp: print var_i in main +FAIL: gdb.fortran/library-module.exp: print var_i in main I believe it is more a GDB bug (in a code contributed by me), filed: gdb.fortran/library-module.exp false regression on GCC upgrade https://sourceware.org/bugzilla/show_bug.cgi?id=19635 gdb/testsuite/ChangeLog 2016-02-14 Jan Kratochvil <jan.kratochvil@redhat.com> Fix compatibility with recent gfortran-5.3.1. * gdb.fortran/vla-history.exp (print vla1 allocated) (print vla2 allocated, print $2, print $3): Remove (print $4): Rename to ... (print $2): ... here. (print $9): Rename to ... (print $5): ... here. (print $10): Rename to ... (print $6): ... here. * gdb.fortran/vla.f90: Add pvla initialization.
2016-02-14testsuite regression: gdb.fortran/vla-value-sub.exp ↵Jan Kratochvil3-0/+10
gdb.fortran/vla-value-sub-finish.exp > +static int max_value_size = 65536; /* 64k bytes */ FAIL: gdb.fortran/vla-value-sub.exp: print array2 in foo after it was filled (passed fixed array) FAIL: gdb.fortran/vla-value-sub.exp: print array2 in foo after it was mofified in debugger (passed fixed array) FAIL: gdb.fortran/vla-value-sub-finish.exp: print array2 in foo after it was filled FAIL: gdb.fortran/vla-value-sub-finish.exp: print array2 in foo after it was mofified in debugger print array2 value requires 296352 bytes, which is more than max-value-size (gdb) FAIL: gdb.fortran/vla-value-sub.exp: print array2 in foo after it was filled (passed fixed array) gdb/testsuite/ChangeLog 2016-02-14 Jan Kratochvil <jan.kratochvil@redhat.com> * gdb.fortran/vla-value-sub-finish.exp (set max-value-size 1024*1024): New test. * gdb.fortran/vla-value-sub.exp: Likewise.
2016-02-10Clear *VAL in regcache_raw_read_unsignedYao Qi2-0/+5
We have function regcache_raw_read_unsigned defined in both GDB and GDBserver, so that it is used in common like this, ULONGEST value; status = regcache_raw_read_unsigned (regcache, regnum, &value); 'value' is correctly set in GDB side, but may not be correctly set in GDBserver, because &value is passed in regcache_raw_read_unsigned but collect_register may only set part of the whole variable. In my test, I see the top half of 'value' is garbage. This patch fixes this problem by clearing *VAL before calling collect_register. gdb/gdbserver: 2016-02-10 Yao Qi <yao.qi@linaro.org> * regcache.c (regcache_raw_read_unsigned): Clear *VAL.
2016-02-10gdb/version.in: Replace -cvs suffix by -git suffixJoel Brobecker2-1/+5
gdb/ChangeLog: * version.in: Replace -cvs suffix by -git suffix.
2016-02-10Bump GDB version number to 7.10.90.DATE-cvs.Joel Brobecker2-1/+5
gdb/ChangeLog: * version.in: Set GDB version number to 7.10.90.DATE-cvs.
2016-02-10Document the GDB 7.10.90 release in gdb/ChangeLogJoel Brobecker1-0/+4
gdb/ChangeLog: GDB 7.10.90 released.
2016-02-10Set GDB version number to 7.10.90.Joel Brobecker2-1/+5
gdb/ChangeLog: * version.in: Set GDB version number to 7.10.90.
2016-02-10gdb/NEWS: Change "since GDB 7.10" -> "in GDB 7.11".Joel Brobecker2-1/+6
gdb/ChangeLog: * NEWS: Change "Changes since GDB version 7.10" into "Changes in GDB version 7.11".
2016-02-10Bump version to 7.10.90.DATE-git.Joel Brobecker2-1/+6
Now that the GDB 7.11 branch has been created, we can bump the version number. gdb/ChangeLog: GDB 7.11 branch created (9ef9e6a6a0dd8f948708cb67c9afcfd0be40cb0a): * version.in: Bump version to 7.10.90.DATE-git.
2016-02-09breakpoints/19546: Fix crash after updating breakpointsgdb-7.11-branchpointKeith Seitz6-2/+122
One of the last checks update_breakpoints_after_exec does while looping over the list of breakpoints is check that the breakpoint has a valid location spec. It uses event_location_empty_p to check if the location spec is "empty", and if it is, the breakpoint is deleted. momentary_breakpoint types rely on setting the breakpoint structure's location spec to NULL, thereby causing an update to delete the breakpoint. However, event_location_empty_p assumed that locations were never NULL. As a result, GDB would crash dereferencing a NULL pointer whenever update_breakpoints_after_exec would encounter a momentary_breakpoint. This patch creates a new wrapper/helper function which tests that the given breakpoint's location spec is non-NULL and if it is not "empty" or "unspecified." gdb/ChangeLog PR breakpoints/19546 * breakpoint.c (breakpoint_event_location_empty_p): New function. (update_breakpoints_after_exec, bkpt_re_set): Use this new function instead of event_location_empty_p. gdb/testsuite/ChangeLog PR breakpoints/19546 * gdb.base/infcall-exec.c: New file. * gdb.base/infcall-exec2.c: New file. * gdb.base/infcall-exec.exp: New file.
2016-02-09Enable/update legacy linespecs in MI.Keith Seitz2-1/+6
MI is currently using string_to_event_location to enable the use of legacy linespecs, but using this function (until this patchset) had the (as yet unnoticed) side effect of allowing both MI and CLI representation for explicit locations. This patch simply changes MI to use the same legacy linespec functions that the python and guile interpreters use. This eliminates the CLI syntax for explicit locations (in MI). gdb/ChangeLog * mi/mi-cmd-break.c (mi_cmd_break_insert_1): Use string_to_event_location_basic instead of string_to_event_location.
2016-02-09Use string_to_event_location_basic in guile.Keith Seitz4-2/+26
This patch, analogous to the previous python patch, implements proper legacy linespec support in guile code using the newly introduced string_to_event_location_basic. gdb/ChangeLog * guile/scm-breakpoint.c (gdbscm_register_breakpoint_x): Skip leading whitespace and use string_to_event_location_basic instead of new_linespec_location. gdb/testsuite/ChangeLog * gdb.guile/scm-breakpoint.exp (test_bkpt_address): New procedure. (toplevel): Call test_bkpt_address.
2016-02-09python/19506 -- gdb.Breakpoint address location regressionKeith Seitz4-2/+48
Now that "legacy" linespecs benefit from consolidated support in string_to_event_location_basic, python's Breakpoint command should use this function to turn strings into event locations. As a result, this patch fixes python/19506. Before: (gdb) python gdb.Breakpoint("*main") Traceback (most recent call last): File "<string>", line 1, in <module> RuntimeError: Function "*main" not defined. Error while executing Python code. After: (gdb) python gdb.Breakpoint("*main") Breakpoint 1 at 0x4005fb: file ../../../src/gdb/testsuite/gdb.python/py-breakpoint.c, line 32. gdb/ChangeLog PR python/19506 * python/py-breakpoint.c (bppy_init): Use string_to_event_location_basic instead of new_linespec_location. gdb/testsuite/ChangeLog PR python/19506 * gdb.python/py-breakpoint.exp (test_bkpt_address): New procedure. (toplevel): Call test_bkpt_address.
2016-02-09Refactor string_to_event_location for legacy linespec support.Keith Seitz3-37/+74
This patch refactors string_to_event_location, breaking it into two separate functions: 1) string_to_event_location_basic A "basic" string parser that implements support for "legacy" linespecs (linespec, address, and probe locations). This function is intended to be used by any UI wishing/needing to support this legacy behavior. 2) string_to_event_location This is now intended as a CLI-only function which adds explicit location parsing in a CLI-appropriate manner (in the form of traditional option/value pairs). Together these patches serve to simplify string-to-event location parsing for all existing non-CLI interfaces (MI, guile, and python). gdb/ChangeLog * location.c (string_to_explicit_location): Note that "-p" is reserved for probe locations and return NULL for any input that starts with that. (string_to_event_location): Move "legacy" linespec code to ... (string_to_event_location_basic): ... here. * location.h (string_to_event_location): Update comment. (string_to_event_location_basic): New function.
2016-02-09Modernize configure.ac'sSimon Marchi9-15/+46
Using AC_OUTPUT with arguments has been deprecated for some time in autoconf, even in version 2.64, which we are using. This change should not affect functionality. I also removed the "exit 0"'s, they shouldn't be necessary. gdb/ChangeLog: * configure.ac: Use AC_CONFIG_FILES instead of passing arguments to AC_OUTPUT. Remove "exit 0" at the end. * configure: Regenerate. gdb/testsuite/ChangeLog: * configure.ac: Use AC_CONFIG_FILES instead of passing arguments to AC_OUTPUT. * configure: Regenerate. gdb/gdbserver/ChangeLog: * configure.ac: Use AC_CONFIG_FILES instead of passing arguments to AC_OUTPUT. * configure: Regenerate.
2016-02-09Fix PR19548: Breakpoint re-set inserts breakpoints when it shouldn'tPedro Alves5-17/+66
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-09Fix siginfo C++ build errorSimon Marchi5-5/+15
Change the signature of gdbserver's siginfo_fixup functions so that it's in line with gdb's. This gets rid of the following build error in C++: /home/emaisin/src/binutils-gdb/gdb/gdbserver/linux-x86-low.c: In function ‘int x86_siginfo_fixup(siginfo_t*, void*, int)’: /home/emaisin/src/binutils-gdb/gdb/gdbserver/linux-x86-low.c:694:21: error: invalid conversion from ‘void*’ to ‘gdb_byte* {aka unsigned char*}’ [-fpermissive] FIXUP_32); ^ In file included from /home/emaisin/src/binutils-gdb/gdb/gdbserver/linux-x86-low.c:31:0: /home/emaisin/src/binutils-gdb/gdb/gdbserver/../nat/amd64-linux-siginfo.h:52:5: error: initializing argument 2 of ‘int amd64_linux_siginfo_fixup_common(siginfo_t*, gdb_byte*, int, amd64_siginfo_fixup_mode)’ [-fpermissive] int amd64_linux_siginfo_fixup_common (siginfo_t *native, gdb_byte *inf, ^ /home/emaisin/src/binutils-gdb/gdb/gdbserver/linux-x86-low.c:698:20: error: invalid conversion from ‘void*’ to ‘gdb_byte* {aka unsigned char*}’ [-fpermissive] FIXUP_X32); ^ In file included from /home/emaisin/src/binutils-gdb/gdb/gdbserver/linux-x86-low.c:31:0: /home/emaisin/src/binutils-gdb/gdb/gdbserver/../nat/amd64-linux-siginfo.h:52:5: error: initializing argument 2 of ‘int amd64_linux_siginfo_fixup_common(siginfo_t*, gdb_byte*, int, amd64_siginfo_fixup_mode)’ [-fpermissive] int amd64_linux_siginfo_fixup_common (siginfo_t *native, gdb_byte *inf, ^ gdb/gdbserver/ChangeLog: * linux-aarch64-low.c (aarch64_linux_siginfo_fixup): Change void * to gdb_byte *. * linux-low.c (siginfo_fixup): Likewise. (linux_xfer_siginfo): Likewise. * linux-low.h (struct linux_target_ops) <siginfo_fixup>: Likewise. * linux-x86-low.c (x86_siginfo_fixup): Likewise.
2016-02-09Revert "Fix build breakage"Walfred Tedeschi2-8/+4
This reverts commit 222cab58b7ed37df6e01dacb0932f400a2588137.
generated by cgit v1.1 at 2025-09-20 22:27:29 +0000