aboutsummaryrefslogtreecommitdiff
path: root/gdb/ChangeLog
AgeCommit message (Collapse)AuthorFilesLines
2015-04-10PPC64: Fix step-over-trips-on-watchpoint.exp with displaced stepping onPedro Alves1-0/+9
PPC64 currently fails this test like: FAIL: gdb.threads/step-over-trips-on-watchpoint.exp: displaced=on: no thread-specific bp: step: step FAIL: gdb.threads/step-over-trips-on-watchpoint.exp: displaced=on: no thread-specific bp: next: next FAIL: gdb.threads/step-over-trips-on-watchpoint.exp: displaced=on: no thread-specific bp: continue: continue (the program exited) FAIL: gdb.threads/step-over-trips-on-watchpoint.exp: displaced=on: with thread-specific bp: step: step FAIL: gdb.threads/step-over-trips-on-watchpoint.exp: displaced=on: with thread-specific bp: next: next FAIL: gdb.threads/step-over-trips-on-watchpoint.exp: displaced=on: with thread-specific bp: continue: continue (the program exited) The problem is that PPC is a non-continuable watchpoints architecture and the displaced stepping code isn't coping with that correctly. On such targets/architectures, a watchpoint traps _before_ the instruction executes/completes. On a watchpoint trap, the PC points at the instruction that triggers the watchpoint (side effects haven't happened yet). In order to move past the watchpoint, GDB needs to remove the watchpoint, single-step, and reinsert the watchpoint, just like when stepping past a breakpoint. The trouble is that if GDB is stepping over a breakpoint with displaced stepping, and the instruction under the breakpoint triggers a watchpoint, we get the watchpoint SIGTRAP, expecting a finished (hard or software) step trap. Even though the thread's PC hasn't advanced yet (must remove watchpoint for that), since we get a SIGTRAP, displaced_step_fixup thinks the single-step finished successfuly anyway, and calls gdbarch_displaced_step_fixup, which then adjusts the thread's registers incorrectly. The fix is to cancel the displaced step if we trip on a watchpoint. handle_inferior_event then processes the watchpoint event, and starts a new step-over, here: ... /* At this point, we are stopped at an instruction which has attempted to write to a piece of memory under control of a watchpoint. The instruction hasn't actually executed yet. If we were to evaluate the watchpoint expression now, we would get the old value, and therefore no change would seem to have occurred. ... ecs->event_thread->stepping_over_watchpoint = 1; keep_going (ecs); return; ... but this time, since we have a watchpoint to step over, watchpoints are removed from the target, so the step-over succeeds. The keep_going/resume changes are necessary because if we're stepping over a watchpoint, we need to remove it from the target - displaced stepping doesn't help, the copy of the instruction in the scratch pad reads/writes to the same addresses, thus triggers the watchpoint too... So without those changes we keep triggering the watchpoint forever, never making progress. With non-stop that means we'll need to pause all threads momentarily, which we can't today. We could avoid that by removing the watchpoint _only_ from the thread that is moving past the watchpoint, but GDB is not prepared for that today either. For remote targets, that would need new packets, so good to be able to step over it in-line as fallback anyway. gdb/ChangeLog: 2015-04-10 Pedro Alves <palves@redhat.com> * infrun.c (displaced_step_fixup): Switch to the event ptid earlier. If the thread stopped for a watchpoint and the target/arch has non-continuable watchpoints, cancel the displaced step. (resume): Don't start a displaced step if in-line step-over info is valid.
2015-04-10Fix gdb.base/sigstep.exp with displaced stepping on software single-step targetsPedro Alves1-0/+6
TL;DR: When stepping over a breakpoint with displaced stepping, the core must be notified of all signals, otherwise the displaced step fixup code confuses a breakpoint trap in the signal handler for the expected trap indicating the displaced instruction was single-stepped normally/successfully. Detailed version: Running sigstep.exp with displaced stepping on, against my x86 software single-step branch, I got: FAIL: gdb.base/sigstep.exp: step on breakpoint, to handler: performing step FAIL: gdb.base/sigstep.exp: next on breakpoint, to handler: performing next FAIL: gdb.base/sigstep.exp: continue on breakpoint, to handler: performing continue Turning on debug logs, we see: (gdb) step infrun: clear_proceed_status_thread (process 32147) infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT) infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=1, current thread [process 32147] at 0x400842 displaced: stepping process 32147 now displaced: saved 0x400622: 49 89 d1 5e 48 89 e2 48 83 e4 f0 50 54 49 c7 c0 displaced: %rip-relative addressing used. displaced: using temp reg 2, old value 0x3615eafd37, new value 0x40084c displaced: copy 0x400842->0x400622: c7 81 1c 08 20 00 00 00 00 00 displaced: displaced pc to 0x400622 displaced: run 0x400622: c7 81 1c 08 LLR: Preparing to resume process 32147, 0, inferior_ptid process 32147 LLR: PTRACE_CONT process 32147, 0 (resume event thread) linux_nat_wait: [process -1], [TARGET_WNOHANG] LLW: enter LNW: waitpid(-1, ...) returned 32147, No child processes LLW: waitpid 32147 received Alarm clock (stopped) LLW: PTRACE_CONT process 32147, Alarm clock (preempt 'handle') LNW: waitpid(-1, ...) returned 0, No child processes LLW: exit (ignore) sigchld infrun: target_wait (-1.0.0, status) = infrun: -1.0.0 [process -1], infrun: status->kind = ignore infrun: TARGET_WAITKIND_IGNORE infrun: prepare_to_wait linux_nat_wait: [process -1], [TARGET_WNOHANG] LLW: enter LNW: waitpid(-1, ...) returned 32147, No child processes LLW: waitpid 32147 received Trace/breakpoint trap (stopped) CSBB: process 32147 stopped by software breakpoint LNW: waitpid(-1, ...) returned 0, No child processes LLW: trap ptid is process 32147. LLW: exit infrun: target_wait (-1.0.0, status) = infrun: 32147.32147.0 [process 32147], infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP infrun: TARGET_WAITKIND_STOPPED displaced: restored process 32147 0x400622 displaced: fixup (0x400842, 0x400622), insn = 0xc7 0x81 ... displaced: restoring reg 2 to 0x3615eafd37 displaced: relocated %rip from 0x400717 to 0x400937 infrun: stop_pc = 0x400937 infrun: delayed software breakpoint trap, ignoring infrun: no line number info infrun: stop_waiting 0x0000000000400937 in __dso_handle () 1: x/i $pc => 0x400937: and %ah,0xa0d64(%rip) # 0x4a16a1 (gdb) FAIL: gdb.base/sigstep.exp: displaced=on: step on breakpoint, to handler: performing step What should have happened is that the breakpoint hit in the signal handler should have been presented to the user. But note that "preempt 'handle'" -- what happened instead is that displaced_step_fixup confused the breakpoint in the signal handler for the expected SIGTRAP indicating the displaced instruction was single-stepped normally/successfully. This should be affecting all software single-step targets in the same way. The fix is to make sure the core sees all signals when displaced stepping, just like we already must see all signals when doing an stepping over a breakpoint in-line. We now get: infrun: target_wait (-1.0.0, status) = infrun: 570.570.0 [process 570], infrun: status->kind = stopped, signal = GDB_SIGNAL_ALRM infrun: TARGET_WAITKIND_STOPPED displaced: restored process 570 0x400622 infrun: stop_pc = 0x400842 infrun: random signal (GDB_SIGNAL_ALRM) infrun: signal arrived while stepping over breakpoint infrun: inserting step-resume breakpoint at 0x400842 infrun: resume (step=0, signal=GDB_SIGNAL_ALRM), trap_expected=0, current thread [process 570] at 0x400842 LLR: Preparing to resume process 570, Alarm clock, inferior_ptid process 570 LLR: PTRACE_CONT process 570, Alarm clock (resume event thread) infrun: prepare_to_wait linux_nat_wait: [process -1], [TARGET_WNOHANG] LLW: enter LNW: waitpid(-1, ...) returned 0, No child processes LLW: exit (ignore) infrun: target_wait (-1.0.0, status) = infrun: -1.0.0 [process -1], infrun: status->kind = ignore sigchld infrun: TARGET_WAITKIND_IGNORE infrun: prepare_to_wait linux_nat_wait: [process -1], [TARGET_WNOHANG] LLW: enter LNW: waitpid(-1, ...) returned 570, No child processes LLW: waitpid 570 received Trace/breakpoint trap (stopped) CSBB: process 570 stopped by software breakpoint LNW: waitpid(-1, ...) returned 0, No child processes LLW: trap ptid is process 570. LLW: exit infrun: target_wait (-1.0.0, status) = infrun: 570.570.0 [process 570], infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP infrun: TARGET_WAITKIND_STOPPED infrun: stop_pc = 0x400717 infrun: BPSTAT_WHAT_STOP_NOISY infrun: stop_waiting Breakpoint 3, handler (sig=14) at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/sigstep.c:35 35 done = 1; Hardware single-step targets already behave this way, because the Linux backends (both native and gdbserver) always report signals to the core if the thread was single-stepping. As mentioned in the new comment in do_target_resume, we can't fix this by instead making the displaced_step_fixup phase skip fixing up the PC if the single step stopped somewhere we didn't expect. Here's what the backtrace would look like if we did that: Breakpoint 3, handler (sig=14) at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/sigstep.c:35 35 done = 1; 1: x/i $pc => 0x400717 <handler+7>: movl $0x1,0x200943(%rip) # 0x601064 <done> (gdb) bt #0 handler (sig=14) at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/sigstep.c:35 #1 <signal handler called> #2 0x0000000000400622 in _start () (gdb) FAIL: gdb.base/sigstep.exp: displaced=on: step on breakpoint, to handler: backtrace gdb/ChangeLog: 2015-04-10 Pedro Alves <palves@redhat.com> * infrun.c (displaced_step_in_progress): New function. (do_target_resume): Advise target to report all signals if displaced stepping. gdb/testsuite/ChangeLog: 2015-04-10 Pedro Alves <palves@redhat.com> * gdb.base/sigstep.exp (breakpoint_to_handler) (breakpoint_to_handler_entry): New parameter 'displaced'. Use it. Test "backtrace" in handler. (breakpoint_over_handler): New parameter 'displaced'. Use it. (top level): Add new "displaced" test axis to breakpoint_to_handler, breakpoint_to_handler_entry and breakpoint_over_handler.
2015-04-10gdb/18216: displaced step+deliver signal, a thread needs step-over, crashPedro Alves1-0/+6
The problem is that with hardware step targets and displaced stepping, "signal FOO" when stopped at a breakpoint steps the breakpoint instruction at the same time it delivers a signal. This results in tp->stepped_breakpoint set, but no step-resume breakpoint set. When the next stop event arrives, GDB crashes. Irrespective of whether we should do something more/different to step past the breakpoint in this scenario (e.g., PR 18225), it's just wrong to assume there'll be a step-resume breakpoint set (and was not the original intention). gdb/ChangeLog: 2015-04-10 Pedro Alves <palves@redhat.com> PR gdb/18216 * infrun.c (process_event_stop_test): Don't assume a step-resume is set if tp->stepped_breakpoint is true. gdb/testsuite/ChangeLog: 2015-04-10 Pedro Alves <palves@redhat.com> PR gdb/18216 * gdb.threads/multiple-step-overs.exp: Remove expected eof.
2015-04-10[arm] Fix displaced stepping for thumb alu reg instructionYao Qi1-0/+7
Recent patch series "V2 All-stop on top of non-stop" causes a SIGSEGV in the test case, > -PASS: gdb.base/info-shared.exp: continue to breakpoint: library function #4 > +FAIL: gdb.base/info-shared.exp: continue to breakpoint: library function #4 > > continue^M > Continuing.^M > ^M > Program received signal SIGSEGV, Segmentation fault.^M > 0x40021564 in ?? () gdb/testsuite/gdb.base/info-shared-solib1.so^M > (gdb) FAIL: gdb.base/info-shared.exp: continue to breakpoint: library function #4 and an ARM displaced stepping bug is exposed. It can be reproduced by the modified gdb.arch/arm-disp-step.exp as below, continue^M Continuing.^M ^M Program received signal SIGSEGV, Segmentation fault.^M 0xa713cfcc in ?? ()^M (gdb) FAIL: gdb.arch/arm-disp-step.exp: continue to breakpoint: continue to test_add_rn_pc_end This patch is to fix it. gdb: 2015-04-10 Yao Qi <yao.qi@linaro.org> * arm-tdep.c (install_alu_reg): Update comment. (thumb_copy_alu_reg): Remove local variable rn. Update debugging message. Use r2 instead of r1 in the modified instruction. gdb/testsuite: 2015-04-10 Yao Qi <yao.qi@linaro.org> * gdb.arch/arm-disp-step.S (main): Call test_add_rn_pc. (test_add_rn_pc): New function. * gdb.arch/arm-disp-step.exp (test_add_rn_pc): New proc. (top level): Invoke test_add_rn_pc.
2015-04-10PR13858 - Can't do displaced stepping with no symbolsPedro Alves1-0/+22
Running break-interp.exp with the target always in non-stop mode trips on PR13858, as enabling non-stop also enables displaced stepping. The problem is that when GDB doesn't know where the entry point is, it doesn't know where to put the displaced stepping scratch pad. The test added by this commit exercises this. Without the fix, we get: (gdb) PASS: gdb.base/step-over-no-symbols.exp: displaced=on: break *$pc set displaced-stepping on (gdb) PASS: gdb.base/step-over-no-symbols.exp: displaced=on: set displaced-stepping on stepi 0x00000000004005be in ?? () Entry point address is not known. (gdb) PASS: gdb.base/step-over-no-symbols.exp: displaced=on: stepi p /x $pc $2 = 0x4005be (gdb) PASS: gdb.base/step-over-no-symbols.exp: displaced=on: get after PC FAIL: gdb.base/step-over-no-symbols.exp: displaced=on: advanced The fix switches all GNU/Linux ports to get the entry point from AT_ENTRY in the target auxiliary vector instead of from symbols. This is currently only done by PPC when Cell debugging is enabled, but I think all archs should be able to do the same. Note that ppc_linux_displaced_step_location cached the result, I'm guessing to avoid constantly re-fetching the auxv out of remote targets, but that's no longer necessary nowadays, as the auxv blob is itself cached in the inferior object. The ppc_linux_entry_point_addr global is obviously bad for multi-process too nowadays. Tested on x86-64 (-m64/-m32), PPC64 (-m64/-m32) and S/390 GNU/Linux. Yao tested the new test on ARM as well. gdb/ChangeLog: 2015-04-10 Pedro Alves <palves@redhat.com> PR gdb/13858 * amd64-linux-tdep.c (amd64_linux_init_abi_common): Install linux_displaced_step_location as gdbarch_displaced_step_location hook. * arm-linux-tdep.c (arm_linux_init_abi): Likewise. * i386-linux-tdep.c (i386_linux_init_abi): Likewise. * linux-tdep.c (linux_displaced_step_location): New function, based on ppc_linux_displaced_step_location. * linux-tdep.h (linux_displaced_step_location): New declaration. * ppc-linux-tdep.c (ppc_linux_entry_point_addr): Delete. (ppc_linux_inferior_created, ppc_linux_displaced_step_location): Delete. (ppc_linux_init_abi): Install linux_displaced_step_location as gdbarch_displaced_step_location hook, even without Cell/B.E.. (_initialize_ppc_linux_tdep): Don't install ppc_linux_inferior_created as inferior_created observer. * s390-linux-tdep.c (s390_gdbarch_init): Install linux_displaced_step_location as gdbarch_displaced_step_location hook. gdb/testsuite/ 2015-04-10 Pedro Alves <palves@redhat.com> PR gdb/13858 * gdb.base/step-over-no-symbols.exp: New file.
2015-04-09Rename common-remote-fileio.[ch] as fileio.[ch]Gary Benson1-0/+28
This commit renames common-remote-fileio.[ch] as fileio.[ch] and renames all functions in these files. gdb/ChangeLog: * common/common-remote-fileio.h: Rename to... * common/fileio.h: ...this. Update all references. (remote_fileio_to_fio_error): Rename to... (host_to_fileio_error): ...this. (remote_fileio_to_be): Rename to... (host_to_bigendian): ...this. Update all callers. (remote_fileio_to_fio_uint): Rename to... (host_to_fileio_uint): ...this. Update all callers. (remote_fileio_to_fio_time): Rename to... (host_to_fileio_time): ...this. Update all callers. (remote_fileio_to_fio_stat): Rename to... (host_to_fileio_stat): ...this. Update all references. * common/common-remote-fileio.c: Rename to... * common/fileio.c: ...this. Update all references. (remote_fileio_to_fio_error): Rename to... (host_to_fileio_error): ...this. Update all callers. (remote_fileio_mode_to_target): Rename to... (fileio_mode_pack): ...this. Update all callers. (remote_fileio_to_fio_mode): Rename to... (host_to_fileio_mode): ...this. Update all callers. (remote_fileio_to_fio_ulong): Rename to... (host_to_fileio_ulong): ...this. Update all callers. (remote_fileio_to_fio_stat): Rename to... (host_to_fileio_stat): ...this. Update all callers.
2015-04-09Add Guile frame-read-register commandAndy Wingo1-0/+7
gdb/ChangeLog: * guile/scm-frame.c (gdbscm_frame_read_register): New function. (frame_functions): Bind gdbscm_frame_read_register to frame-read-register. * guile/lib/gdb.scm (frame-read-register): Export. gdb/doc/ChangeLog: * guile.texi (Frames In Guile): Describe frame-read-register. gdb/testsuite/ChangeLog: * gdb.guile/scm-frame.exp: Add frame-read-register tests, modelled after the Python tests.
2015-04-09Introduce new shared function remote_fileio_to_fio_errorGary Benson1-0/+12
This commit introduces a new shared function to replace three identical functions in various places in the codebase. gdb/ChangeLog: * common/common-remote-fileio.h (remote_fileio_to_fio_error): New declaration. * common/common-remote-fileio.c (remote_fileio_to_fio_error): New function, factored out the named functions below. * inf-child.c (gdb/fileio.h): Remove include. (common-remote-fileio.h): New include. (inf_child_errno_to_fileio_error): Remove function. Update all callers to use remote_fileio_to_fio_error. * remote-fileio.c (remote_fileio_errno_to_target): Likewise. gdb/gdbserver/ChangeLog: * hostio-errno.c (errno_to_fileio_error): Remove function. Update caller to use remote_fileio_to_fio_error.
2015-04-09Add myself to Write After Approval list.Andy Wingo1-0/+4
gdb/ChangeLog: * MAINTAINERS (Write After Approval): Add Andy Wingo.
2015-04-09Replace $zlibdir with $ZLIBDIR in LDFLAGSH.J. Lu1-0/+6
* acinclude.m4: (GDB_AC_CHECK_BFD): Set ZLIBDIR with $zlibdir. Replace $zlibdir with $ZLIBDIR in LDFLAGS. * configure: Regenerated.
2015-04-09Import strtok_r gnulib modulePedro Alves1-0/+12
gdb/linux-tdep.c recently gained a strtok_r use. That broke --enable-targets=all with some versions of mingw64, which don't have strtok_r: https://sourceware.org/ml/gdb-patches/2015-04/msg00266.html Fix that by importing the strtok_r gnulib module. gdb/ChangeLog: 2015-04-09 Pedro Alves <palves@redhat.com> * gnulib/update-gnulib.sh (IMPORTED_GNULIB_MODULES): Add strtok_r. * gnulib/Makefile.in (aclocal_m4_deps): Add import/m4/strtok_r.m4. * gnulib/configure, gnulib/config.in, gnulib/aclocal.m4: Regenerate. * gnulib/import/Makefile.am: Update. * gnulib/import/Makefile.in: Update. * gnulib/import/m4/gnulib-cache.m4: Update. * gnulib/import/m4/gnulib-comp.m4: Update. * gnulib/import/m4/strtok_r.m4: New file. * gnulib/import/strtok_r.c: New file.
2015-04-09update-gnulib.sh: work around aclocal warning with Perl >= 5.16Pedro Alves1-0/+5
gdb/ChangeLog: 2015-04-09 Pedro Alves <palves@redhat.com> * gnulib/update-gnulib.sh (aclocal version check): Filter out "called too early to check prototype".
2015-04-08Fix Python completion when using the "complete" commandSergio Durigan Junior1-0/+10
This patch is related to PR python/16699, and is an improvement over the patch posted here: <https://sourceware.org/ml/gdb-patches/2014-03/msg00301.html> Keith noticed that, when using the "complete" command on GDB to complete a Python command, some strange things could happen. In order to understand what can go wrong, I need to explain how the Python completion mechanism works. When the user requests a completion of a Python command by using TAB, GDB will first try to determine the right set of "brkchars" that will be used when doing the completion. This is done by actually calling the "complete" method of the Python class. Then, when we already know the "brkchars" that will be used, we call the "complete" method again, for the same values. If you read the thread mentioned above, you will see that one of the design decisions was to make the "cmdpy_completer_helper" (which is the function the does the actual calling of the "complete" method) cache the first result of the completion, since this result will be used in the second call, to do the actual completion. The problem is that the "complete" command does not process the brkchars, and the current Python completion mechanism (improved by the patch mentioned above) relies on GDB trying to determine the brkchars, and then doing the completion itself. Therefore, when we use the "complete" command instead of doing a TAB-completion on GDB, there is a scenario where we can use the invalid cache of a previous Python command that was completed before. For example: (gdb) A <TAB> (gdb) complete B B value1 B value10 B value2 B value3 B value4 B value5 B value6 B value7 B value8 B value9 (gdb) B <TAB> comp1 comp2 comp4 comp6 comp8 comp10 comp3 comp5 comp7 comp9 Here, we see that "complete B " gave a different result than "B <TAB>". The reason for that is because "A <TAB>" was called before, and its completion results were "value*", so when GDB tried to "complete B " it wrongly answered with the results for A. The problem here is using a wrong cache (A's cache) for completing B. We tried to come up with a solution that would preserve the caching mechanism, but it wasn't really possible. So I decided to completely remove the cache, and doing the method calling twice for every completion. This is not optimal, but I do not think it will impact users noticeably. It is worth mentioning another small issue that I found. The code was doing: wordobj = PyUnicode_Decode (word, sizeof (word), host_charset (), NULL); which is totally wrong, because using "sizeof" here will lead to always the same result. So I changed this to use "strlen". The testcase also catches this problem. Keith kindly expanded the existing testcase to cover the problem described above, and everything is passing. gdb/ChangeLog: 2015-04-08 Sergio Durigan Junior <sergiodj@redhat.com> PR python/16699 * python/py-cmd.c (cmdpy_completer_helper): Adjust function to not use a caching mechanism. Adjust comments and code to reflect that. Replace 'sizeof' by 'strlen' when fetching 'wordobj'. (cmdpy_completer_handle_brkchars): Adjust call to cmdpy_completer_helper. Call Py_XDECREF for 'resultobj'. (cmdpy_completer): Likewise. gdb/testsuite/ChangeLog: 2015-04-08 Keith Seitz <keiths@redhat.com> PR python/16699 * gdb.python/py-completion.exp: New tests for completion. * gdb.python/py-completion.py (CompleteLimit1): New class. (CompleteLimit2): Likewise. (CompleteLimit3): Likewise. (CompleteLimit4): Likewise. (CompleteLimit5): Likewise. (CompleteLimit6): Likewise. (CompleteLimit7): Likewise.
2015-04-08[spu] Don't call set_gdbarch_cannot_step_breakpoint in spu_gdbarch_initYao Qi1-0/+5
Nowadays, in infrun.c:resume, the setting to 'step' variable is like: if (use_displaced_stepping (gdbarch) && tp->control.trap_expected && sig == GDB_SIGNAL_0 && !current_inferior ()->waiting_for_vfork_done) { } /* Do we need to do it the hard way, w/temp breakpoints? */ else if (step) step = maybe_software_singlestep (gdbarch, pc); <-- [1] ... if (execution_direction != EXEC_REVERSE && step && breakpoint_inserted_here_p (aspace, pc)) { ... if (gdbarch_cannot_step_breakpoint (gdbarch)) <-- [2] step = 0; } spu doesn't have displaced stepping and uses software single step, so 'step' is set to zero in [1], and [2] becomes unreachable as a result. So don't have to call set_gdbarch_cannot_step_breakpoint in spu_gdbarch_init. gdb: 2015-04-08 Yao Qi <yao.qi@linaro.org> * spu-tdep.c (spu_gdbarch_init): Don't call set_gdbarch_cannot_step_breakpoint.
2015-04-07Initialize variable on gdb/linux-tdep.c:decode_vmflagsSergio Durigan Junior1-0/+4
This obvious commit initializes the 'saveptr' variable on gdb/linux-tdep.c:decode_vmflags. This was causing a build failure on Fedora 21 x86_64, caught by the BuildBot here: <https://sourceware.org/ml/gdb-testers/2015-q2/msg00450.html>
2015-04-07update thread list, delete exited threadsPedro Alves1-0/+12
On GNU/Linux, if the running kernel supports clone events, then linux-thread-db.c defers thread listing to the target beneath: static void thread_db_update_thread_list (struct target_ops *ops) { ... if (target_has_execution && !thread_db_use_events ()) ops->beneath->to_update_thread_list (ops->beneath); else thread_db_update_thread_list_td_ta_thr_iter (ops); ... } However, when live debugging, the target beneath, linux-nat.c, does not implement the to_update_thread_list method. The result is that if a thread is marked exited (because it can't be deleted right now, e.g., it was the selected thread), then it won't ever be deleted, until the process exits or is killed/detached. A similar thing happens with the remote.c target. Because its target_update_thread_list implementation skips exited threads when it walks the current thread list looking for threads that no longer exits on the target side, using ALL_NON_EXITED_THREADS_SAFE, stale exited threads are never deleted. This is not a big deal -- I can't think of any way this might be user visible, other than gdb's memory growing a tiny bit whenever a thread gets stuck in exited state. Still, might as well clean things up properly. All other targets use prune_threads, so are unaffected. The fix adds a ALL_THREADS_SAFE macro, that like ALL_NON_EXITED_THREADS_SAFE, walks the thread list and allows deleting the iterated thread, and uses that in places that are walking the thread list in order to delete threads. Actually, after converting linux-nat.c and remote.c to use this, we find the only other user of ALL_NON_EXITED_THREADS_SAFE is also walking the list to delete threads. So we convert that too, and end up deleting ALL_NON_EXITED_THREADS_SAFE. Tested on x86_64 Fedora 20, native and gdbserver. gdb/ChangeLog 2015-04-07 Pedro Alves <palves@redhat.com> * gdbthread.h (ALL_NON_EXITED_THREADS_SAFE): Rename to ... (ALL_THREADS_SAFE): ... this, and don't skip exited threads. (delete_exited_threads): New declaration. * infrun.c (follow_exec): Use ALL_THREADS_SAFE. * linux-nat.c (linux_nat_update_thread_list): New function. (linux_nat_add_target): Install it. * remote.c (remote_update_thread_list): Use ALL_THREADS_SAFE. * thread.c (prune_threads): Use ALL_THREADS_SAFE. (delete_exited_threads): New function.
2015-04-07Displaced stepping debug: fetch the right regcachePedro Alves1-0/+5
Although not currently possible in practice when we get here, 'resume_ptid' can also be a wildcard throughout this function. It's clearer to fetch the regcache using the thread's ptid. gdb/ChangeLog: 2015-04-07 Pedro Alves <pedro@codesourcery.com> * infrun.c (resume) <displaced stepping debug output>: Get the leader thread's regcache, not resume_ptid's.
2015-04-06symtab.c (hash_symbol_entry): Hash STRUCT_DOMAIN symbols as VAR_DOMAIN.Doug Evans1-0/+7
gdb/ChangeLog: * symtab.c (hash_symbol_entry): Hash STRUCT_DOMAIN symbols as VAR_DOMAIN. (symbol_cache_lookup): Clarify use of bsc_ptr, slot_ptr parameters. Include symbol domain in debugging output.
2015-04-06Fallback to stub-termcap.c on all hostsPedro Alves1-0/+9
Currently building gdb is impossible without an installed termcap or curses library. But, GDB already has a very minimal termcap in the tree to handle this situation for Windows -- gdb/stub-termcap.c. This patch makes that the fallback for all hosts. Testing this on GNU/Linux (by simply hacking away the termcap/curses detection in gdb/configure.ac), we trip on: ../readline/libreadline.a(terminal.o): In function `_rl_init_terminal_io': /home/pedro/gdb/mygit/src/readline/terminal.c:527: undefined reference to `PC' /home/pedro/gdb/mygit/src/readline/terminal.c:528: undefined reference to `BC' /home/pedro/gdb/mygit/src/readline/terminal.c:529: undefined reference to `UP' /home/pedro/gdb/mygit/src/readline/terminal.c:538: undefined reference to `PC' /home/pedro/gdb/mygit/src/readline/terminal.c:539: undefined reference to `BC' /home/pedro/gdb/mygit/src/readline/terminal.c:540: undefined reference to `UP' These are globals that are normally defined by termcap (or ncurses' termcap emulation). Now, we could just define replacements in stub-termcap.c, but readline/terminal.c (at least the copy in our tree) has this: #if !defined (__linux__) && !defined (NCURSES_VERSION) # if defined (__EMX__) || defined (NEED_EXTERN_PC) extern # endif /* __EMX__ || NEED_EXTERN_PC */ char PC, *BC, *UP; #endif /* !__linux__ && !NCURSES_VERSION */ which can result in readline defining the globals too. That will usually work out in C, given that "-fcommon" is usually the default for C compilers, but that won't work for C++, or C with -fno-common (link fails with "multiple definition" errors)... Mirroring those #ifdef conditions in the stub termcap screams "brittle" to me -- I can see them changing in latter readline versions. Work around that by simply using __attribute__((weak)). Windows/PE/COFF's do support weak, but not on gcc 3.4 based toolchains (4.8.x does work). Given the file never needed the variables while it was Windows-only, just continue not defining them there. All other supported hosts should support this. gdb/ChangeLog: 2015-04-06 Pedro Alves <palves@redhat.com> Bernd Edlinger <bernd.edlinger@hotmail.de> * configure.ac: Remove the mingw32-specific stub-termcap.o fallback, and instead fallback to the stub termcap on all hosts. * configure: Regenerate. * stub-termcap.c [!__MINGW32__] (PC, BC, UP): Define as weak symbols.
2015-04-03gdbtypes.c: remove the usuned "top_level" parameterPierre-Marie de Rodat1-0/+13
This paramater is no longer useful after the previous commit, so remove it as a cleanup. gdb/ChangeLog: * gdbtypes.c (is_dynamic_type_internal): Remove the unused "top_level" parameter. (resolve_dynamic_type_internal): Remove the unused "top_level" parameter. Update call to is_dynamic_type_internal. (is_dynamic_type): Update call to is_dynamic_type_internal. (resolve_dynamic_range): Update call to resolve_dynamic_type_internal. (resolve_dynamic_union): Likewise. (resolve_dynamic_struct): Likewise. (resolve_dynamic_type): Likewise.
2015-04-03Do not consider reference types as dynamicPierre-Marie de Rodat1-0/+7
Even when referenced types are dynamic, the corresponding referencing type should not be considered as dynamic: it's only a pointer. This prevents reference type for values not in memory to be resolved. gdb/ChangeLog: * gdbtypes.c (is_dynamic_type_internal): Remove special handling of TYPE_CODE_REF types so that they are not considered as dynamic depending on the referenced type. (resolve_dynamic_type_internal): Likewise. gdb/testsuite/ChangeLog: * gdb.ada/funcall_ref.exp: New file. * gdb.ada/funcall_ref/foo.adb: New file.
2015-04-02Regenerate configure in bfd/binutils/gas/gdb/goldH.J. Lu1-0/+5
bfd/ * configure: Regenerated. binutils/ * configure: Regenerated. gas/ * configure: Regenerated. gdb/ * Makefile.in (top_srcdir): New. * configure: Regenerated. gold/ * configure: Regenerated.
2015-04-02Document "target:" sysroot changesGary Benson1-0/+4
This commit documents the newly added "target:" sysroot feature. gdb/ChangeLog: * NEWS: Announce the new default sysroot of "target:". gdb/doc/ChangeLog: * gdb.texinfo (set sysroot): Document "target:".
2015-04-02Make the default sysroot be "target:"Gary Benson1-0/+5
This commit makes GDB default to a sysroot of "target:". One testcase needed updating as a result of this change. gdb/ChangeLog: * main.c (captured_main): Set gdb_sysroot to "target:" if not otherwise set. gdb/testsuite/ChangeLog: * gdb.base/break-probes.exp: Cope with "target:" sysroot.
2015-04-02Update exec_file_attach to cope with "target:" filenamesGary Benson1-0/+4
This commit adds support for filenames prefixed with "target:" to exec_file_attach. This is required to correctly follow inferior exec* calls when a gdb_sysroot prefixed with "target:" is set. gdb/ChangeLog: * exec.c (exec_file_attach): Support "target:" filenames.
2015-04-02Strip "target:" prefix in solib_find if accessing local filesGary Benson1-0/+5
This commit updates solib_find to strip the "target:" prefix from gdb_sysroot when accessing local files. This ensures that the same search algorithm is used for local files regardless of whether a "target:" prefix was used or not. It also avoids cluttering GDB's output with unnecessary "target:" prefixes on paths. gdb/ChangeLog: * solib.c (solib_find): Strip "target:" prefix from sysroot if accessing local files.
2015-04-02Rearrange symfile_bfd_openGary Benson1-0/+5
symfile_bfd_open handled what were remote files as a special case. Converting from "remote:" files to "target:" made symfile_bfd_open look like this: if remote: open bfd, check format, etc return local-specific stuff open bfd, check format, etc return This commit rearranges symfile_bfd_open to remove the duplicated code, like this: if local: local-specific stuff open bfd, check format, etc return gdb/ChangeLog: * symfile.c (symfile_bfd_open): Reorder to remove duplicated checks and error messages.
2015-04-02Convert "remote:" sysroots to "target:" and remove "remote:"Gary Benson1-0/+30
The functionality of "target:" sysroots is a superset of the functionality of "remote:" sysroots. This commit causes the "set sysroot" command to rewrite "remote:" sysroots as "target:" sysroots and replaces "remote:" specific code with "target:" specific code where still necessary. gdb/ChangeLog: * remote.h (REMOTE_SYSROOT_PREFIX): Remove definition. (remote_filename_p): Remove declaration. (remote_bfd_open): Likewise. * remote.c (remote_bfd_iovec_open): Remove function. (remote_bfd_iovec_close): Likewise. (remote_bfd_iovec_pread): Likewise. (remote_bfd_iovec_stat): Likewise. (remote_filename_p): Likewise. (remote_bfd_open): Likewise. * symfile.h (gdb_bfd_open_maybe_remote): Remove declaration. * symfile.c (separate_debug_file_exists): Use gdb_bfd_open. (gdb_bfd_open_maybe_remote): Remove function. (symfile_bfd_open): Replace remote filename check with target filename check. (reread_symbols): Use gdb_bfd_open. * build-id.c (gdbcore.h): New include. (build_id_to_debug_bfd): Use gdb_bfd_open. * infcmd.c (attach_command_post_wait): Remove remote filename check. * solib.c (solib_find): Replace remote-specific handling with target-specific handling. Update comments where necessary. (solib_bfd_open): Replace remote-specific handling with target-specific handling. (gdb_sysroot_changed): New function. (_initialize_solib): Call the above when gdb_sysroot changes. * windows-tdep.c (gdbcore.h): New include. (windows_xfer_shared_library): Use gdb_bfd_open.
2015-04-02Make gdb_bfd_open able to open BFDs using target fileioGary Benson1-0/+18
This commit updates gdb_bfd_open to access files using target fileio functions if the supplied path starts with "target:" and if the local and target filesystems are not the same. This allows users to specify "set sysroot target:" and have GDB access files locally or from the remote as appropriate. The new functions in gdb_bfd.c are copies of functions from remote.c. This duplication is intentional and will be removed by the next commit in this series. gdb/ChangeLog: * gdb/gdb_bfd.h (TARGET_SYSROOT_PREFIX): New definition. (is_target_filename): New declaration. (gdb_bfd_has_target_filename): Likewise. (gdb_bfd_open): Update documentation comment. * gdb_bfd.c (target.h): New include. (gdb/fileio.h): Likewise. (is_target_filename): New function. (gdb_bfd_has_target_filename): Likewise. (fileio_errno_to_host): Likewise. (gdb_bfd_iovec_fileio_open): Likewise. (gdb_bfd_iovec_fileio_pread): Likewise. (gdb_bfd_iovec_fileio_close): Likewise. (gdb_bfd_iovec_fileio_fstat): Likewise. (gdb_bfd_open): Use target fileio to access paths prefixed with "target:" where necessary.
2015-04-02Introduce target_filesystem_is_localGary Benson1-0/+9
This commit introduces a new target method target_filesystem_is_local which can be used to determine whether or not the filesystem accessed by the target_fileio_* methods is the local filesystem. gdb/ChangeLog: * target.h (struct target_ops) <to_filesystem_is_local>: New field. (target_filesystem_is_local): New macro. * target-delegates.c: Regenerate. * remote.c (remote_filesystem_is_local): New function. (init_remote_ops): Initialize to_filesystem_is_local.
2015-04-02Introduce target_fileio_fstatGary Benson1-0/+9
This commit introduces a new target method target_fileio_fstat which can be used to retrieve information about files opened with target_fileio_open. gdb/ChangeLog: * target.h (struct target_ops) <to_fileio_fstat>: New field. (target_fileio_fstat): New declaration. * target.c (target_fileio_fstat): New function. * inf-child.c (inf_child_fileio_fstat): Likewise. (inf_child_target): Initialize to_fileio_fstat. * remote.c (init_remote_ops): Likewise.
2015-04-01Add support for writing unwinders in Python.Sasha Smundak1-0/+32
gdb/ChangeLog: * Makefile.in (SUBDIR_PYTHON_OBJS): Add py-unwind.o. (SUBDIR_PYTHON_SRCS): Add py-unwind.c. (py-unwind.o): New recipe. * NEWS: mention Python frame unwinding. * data-directory/Makefile.in (PYTHON_FILE_LIST): Add gdb/unwinder.py and gdb/command/unwinder.py * python/lib/gdb/__init__.py (packages): Add frame_unwinders list. (execute_unwinders): New function. * python/lib/gdb/command/unwinders.py: New file. * python/lib/gdb/unwinder.py: New file. * python/py-objfile.c (objfile_object): Add frame_unwinders field. (objfpy_dealloc): Decrement frame_unwinders reference count. (objfpy_initialize): Create frame_unwinders list. (objfpy_get_frame_unwinders): New function. (objfpy_set_frame_unwinders): Ditto. (objfile_getset): Add frame_unwinders attribute to Objfile. * python/py-progspace.c (pspace_object): Add frame_unwinders field. (pspy_dealloc): Decrement frame_unwinders reference count. (pspy_initialize): Create frame_unwinders list. (pspy_get_frame_unwinders): New function. (pspy_set_frame_unwinders): Ditto. (pspy_getset): Add frame_unwinders attribute to gdb.Progspace. * python/py-unwind.c: New file. * python/python-internal.h (pspy_get_name_unwinders): New prototype. (objpy_get_frame_unwinders): New prototype. (gdbpy_initialize_unwind): New prototype. * python/python.c (gdbpy_apply_type_printers): Call gdbpy_initialize_unwind. gdb/doc/ChangeLog: * doc/python.texi (Writing a Frame Unwinder in Python): Add section. gdb/testsuite/ChangeLog: * gdb.python/py-unwind-maint.c: New file. * gdb.python/py-unwind-maint.exp: New test. * gdb.python/py-unwind-maint.py: New file. * gdb.python/py-unwind.c: New file. * gdb.python/py-unwind.exp: New test. * gdb.python/py-unwind.py: New test.
2015-04-01infrun.c:resume: currently_stepping after clearing stepped_breakpointPedro Alves1-0/+5
My all-stop-on-top-of-non-stop series manages to shows regressions due to this latent bug. currently_stepping returns true if stepped_breakpoint is set. Obviously we should clear it before checking currently_stepping, not after. Tested on x86_64 Fedora 20. gdb/ChangeLog: 2015-04-01 Pedro Alves <palves@redhat.com> * infrun.c (resume): Check currently_stepping after clearing stepped_breakpoint, not before.
2015-04-01Make print_target_wait_results print the whole ptidPedro Alves1-0/+5
Makes "set debug infrun 1" a bit clearer. Before: infrun: target_wait (-1, status) = infrun: 6299 [Thread 0x7ffff7fc1700 (LWP 6340)], after: infrun: target_wait (-1.0.0, status) = infrun: 7233.7237.0 [Thread 0x7ffff7fc1700 (LWP 7237)], gdb/ChangeLog: 2015-04-01 Pedro Alves <palves@redhat.com> * infrun.c (print_target_wait_results): Print all the ptid elements.
2015-04-01keep_going: Add missing discard_cleanups callPedro Alves1-0/+5
By inspection, I noticed a path where we return without discarding the cleanups. gdb/ChangeLog: 2015-04-01 Pedro Alves <palves@redhat.com> * infrun.c (keep_going): Also discard cleanups if inserting breakpoints fails.
2015-04-01wait_for_inferior and errors thrown from target_waitPedro Alves1-0/+6
Noticed that if an error is thrown out of target_wait, we miss running finish_thread_state_cleanup. Tested on x86_64 Fedora 20, with "maint set target-async off". gdb/ChangeLog: 2015-04-01 Pedro Alves <palves@redhat.com> * infrun.c (wait_for_inferior): Install the finish_thread_state_cleanup cleanup across the whole function, not just around handle_inferior_event.
2015-04-01Use do_target_resume when stepping past permanent breakpoint tooPedro Alves1-0/+5
We can use the recently added do_target_resume do simplify the code a bit here. Tested on x86_64 Fedora 20. gdb/ChangeLog: 2015-04-01 Pedro Alves <palves@redhat.com> * infrun.c (resume) <step past permanent breakpoint>: Use do_target_resume.
2015-04-01linux_nat.c: Mark new thread running even if momentarily pausingPedro Alves1-0/+4
My all-stop-on-top-of-non-stop series manages to trip on a bug in the linux-nat.c backend while running the testsuite. If a thread is discovered while threads are being momentarily paused (without the core's intervention), the thread ends up stuck in THREAD_STOPPED state, even though from the user's perspective, the thread is running even while it is paused. From inspection, in the current sources, this can happen if we call stop_and_resume_callback, though there's no way to test that with current Linux kernels. (While trying to come up with test to exercise this, I stumbled on: https://sourceware.org/ml/gdb-patches/2015-03/msg00850.html ... which does include a non-trivial test, so I think I can still claim I come out net positive. :-) ) Tested on x86_64 Fedora 20. gdb/ChangeLog: 2015-04-01 Pedro Alves <palves@redhat.com> * linux-nat.c (linux_handle_extended_wait): Always call set_running.
2015-04-01Add myself as a write-after-approval GDB maintainerPierre-Marie de Rodat1-0/+4
gdb/ChangeLog: * MAINTAINERS (Write After Approval): Add "Pierre-Marie de Rodat".
2015-04-01Crash on thread id wrap aroundPedro Alves1-0/+5
On GNU/Linux, if the target reuses the TID of a thread that GDB still has in its list marked as THREAD_EXITED, GDB crashes, like: (gdb) continue Continuing. src/gdb/thread.c:789: internal-error: set_running: Assertion `tp->state != THREAD_EXITED' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) FAIL: gdb.threads/tid-reuse.exp: continue to breakpoint: after_reuse_time (GDB internal error) Here: (top-gdb) bt #0 internal_error (file=0x953dd8 "src/gdb/thread.c", line=789, fmt=0x953da0 "%s: Assertion `%s' failed.") at src/gdb/common/errors.c:54 #1 0x0000000000638514 in set_running (ptid=..., running=1) at src/gdb/thread.c:789 #2 0x00000000004bda42 in linux_handle_extended_wait (lp=0x16f5760, status=0, stopping=0) at src/gdb/linux-nat.c:2114 #3 0x00000000004bfa24 in linux_nat_filter_event (lwpid=20570, status=198015) at src/gdb/linux-nat.c:3127 #4 0x00000000004c070e in linux_nat_wait_1 (ops=0xe193d0, ptid=..., ourstatus=0x7fffffffd2c0, target_options=1) at src/gdb/linux-nat.c:3478 #5 0x00000000004c1015 in linux_nat_wait (ops=0xe193d0, ptid=..., ourstatus=0x7fffffffd2c0, target_options=1) at src/gdb/linux-nat.c:3722 #6 0x00000000004c92d2 in thread_db_wait (ops=0xd80b60 <thread_db_ops>, ptid=..., ourstatus=0x7fffffffd2c0, options=1) at src/gdb/linux-thread-db.c:1525 #7 0x000000000066db43 in delegate_wait (self=0xd80b60 <thread_db_ops>, arg1=..., arg2=0x7fffffffd2c0, arg3=1) at src/gdb/target-delegates.c:116 #8 0x000000000067e54b in target_wait (ptid=..., status=0x7fffffffd2c0, options=1) at src/gdb/target.c:2206 #9 0x0000000000625111 in fetch_inferior_event (client_data=0x0) at src/gdb/infrun.c:3275 #10 0x0000000000648a3b in inferior_event_handler (event_type=INF_REG_EVENT, client_data=0x0) at src/gdb/inf-loop.c:56 #11 0x00000000004c2ecb in handle_target_event (error=0, client_data=0x0) at src/gdb/linux-nat.c:4655 I managed to come up with a test that reliably reproduces this. It spawns enough threads for the pid number space to wrap around, so could potentially take a while. On my box that's 4 seconds; on gcc110, a PPC box which has max_pid set to 65536, it's over 10 seconds. So I made the test compute how long that would take, and cap the time waited if it would be unreasonably long. Tested on x86_64 Fedora 20. gdb/ChangeLog: 2015-04-01 Pedro Alves <palves@redhat.com> * linux-thread-db.c (record_thread): Readd the thread to gdb's list if it was marked exited. gdb/testsuite/ChangeLog: 2015-04-01 Pedro Alves <palves@redhat.com> * gdb.threads/tid-reuse.c: New file. * gdb.threads/tid-reuse.exp: New file.
2015-04-01Regenerate configure in bfd/binutils/gas/gdbH.J. Lu1-0/+4
bfd/ 2015-04-01 H.J. Lu <hongjiu.lu@intel.com> * configure: Regenerated. binutils/ 2015-04-01 H.J. Lu <hongjiu.lu@intel.com> * configure: Regenerated. gas/ 2015-04-01 H.J. Lu <hongjiu.lu@intel.com> * configure: Regenerated. gdb/ 2015-04-01 H.J. Lu <hongjiu.lu@intel.com> * configure: Regenerated.
2015-03-31Implement support for checking /proc/PID/coredump_filterSergio Durigan Junior1-0/+24
This patch, as the subject says, extends GDB so that it is able to use the contents of the file /proc/PID/coredump_filter when generating a corefile. This file contains a bit mask that is a representation of the different types of memory mappings in the Linux kernel; the user can choose to dump or not dump a certain type of memory mapping by enabling/disabling the respective bit in the bit mask. Currently, here is what is supported: bit 0 Dump anonymous private mappings. bit 1 Dump anonymous shared mappings. bit 2 Dump file-backed private mappings. bit 3 Dump file-backed shared mappings. bit 4 (since Linux 2.6.24) Dump ELF headers. bit 5 (since Linux 2.6.28) Dump private huge pages. bit 6 (since Linux 2.6.28) Dump shared huge pages. (This table has been taken from core(5), but you can also read about it on Documentation/filesystems/proc.txt inside the Linux kernel source tree). The default value for this file, used by the Linux kernel, is 0x33, which means that bits 0, 1, 4 and 5 are enabled. This is also the default for GDB implemented in this patch, FWIW. Well, reading the file is obviously trivial. The hard part, mind you, is how to determine the types of the memory mappings. For that, I extended the code of gdb/linux-tdep.c:linux_find_memory_regions_full and made it rely *much more* on the information gathered from /proc/<PID>/smaps. This file contains a "verbose dump" of the inferior's memory mappings, and we were not using as much information as we could from it. If you want to read more about this file, take a look at the proc(5) manpage (I will also write a blog post soon about everything I had to learn to get this patch done, and when I it is ready I will post it here). With Oleg Nesterov's help, we could improve the current algorithm for determining whether a memory mapping is anonymous/file-backed, private/shared. GDB now also respects the MADV_DONTDUMP flag and does not dump the memory mapping marked as so, and will always dump "[vsyscall]" or "[vdso]" mappings (just like the Linux kernel). In a nutshell, what the new code is doing is: - If the mapping is associated to a file whose name ends with " (deleted)", or if the file is "/dev/zero", or if it is "/SYSV%08x" (shared memory), or if there is no file associated with it, or if the AnonHugePages: or the Anonymous: fields in the /proc/PID/smaps have contents, then GDB considers this mapping to be anonymous. There is a special case in this, though: if the memory mapping is a file-backed one, but *also* contains "Anonymous:" or "AnonHugePages:" pages, then GDB considers this mapping to be *both* anonymous and file-backed, just like the Linux kernel does. What that means is simple: this mapping will be dumped if the user requested anonymous mappings *or* if the user requested file-backed mappings to be present in the corefile. It is worth mentioning that, from all those checks described above, the most fragile is the one to see if the file name ends with " (deleted)". This does not necessarily mean that the mapping is anonymous, because the deleted file associated with the mapping may have been a hard link to another file, for example. The Linux kernel checks to see if "i_nlink == 0", but GDB cannot easily do this check (as it has been discussed, GDB would need to run as root, and would need to check the contents of the /proc/PID/map_files/ directory in order to determine whether the deleted was a hardlink or not). Therefore, we made a compromise here, and we assume that if the file name ends with " (deleted)", then the mapping is indeed anonymous. FWIW, this is something the Linux kernel could do better: expose this information in a more direct way. - If we see the flag "sh" in the VmFlags: field (in /proc/PID/smaps), then certainly the memory mapping is shared (VM_SHARED). If we have access to the VmFlags, and we don't see the "sh" there, then certainly the mapping is private. However, older Linux kernels (see the code for more details) do not have the VmFlags field; in that case, we use another heuristic: if we see 'p' in the permission flags, then we assume that the mapping is private, even though the presence of the 's' flag there would mean VM_MAYSHARE, which means the mapping could still be private. This should work OK enough, however. Finally, it is worth mentioning that I added a new command, 'set use-coredump-filter on/off'. When it is 'on', it will read the coredump_filter' file (if it exists) and use its value; otherwise, it will use the default value mentioned above (0x33) to decide which memory mappings to dump. gdb/ChangeLog: 2015-03-31 Sergio Durigan Junior <sergiodj@redhat.com> Jan Kratochvil <jan.kratochvil@redhat.com> Oleg Nesterov <oleg@redhat.com> PR corefiles/16092 * linux-tdep.c: Include 'gdbcmd.h' and 'gdb_regex.h'. New enum identifying the various options of the coredump_filter file. (struct smaps_vmflags): New struct. (use_coredump_filter): New variable. (decode_vmflags): New function. (mapping_is_anonymous_p): Likewise. (dump_mapping_p): Likewise. (linux_find_memory_regions_full): New variables 'coredumpfilter_name', 'coredumpfilterdata', 'pid', 'filterflags'. Removed variable 'modified'. Read /proc/<PID>/smaps file; improve parsing of its information. Implement memory mapping filtering based on its contents. (show_use_coredump_filter): New function. (_initialize_linux_tdep): New command 'set use-coredump-filter'. * NEWS: Mention the possibility of using the '/proc/PID/coredump_filter' file when generating a corefile. Mention new command 'set use-coredump-filter'. gdb/doc/ChangeLog: 2015-03-31 Sergio Durigan Junior <sergiodj@redhat.com> PR corefiles/16092 * gdb.texinfo (gcore): Mention new command 'set use-coredump-filter'. (set use-coredump-filter): Document new command. gdb/testsuite/ChangeLog: 2015-03-31 Sergio Durigan Junior <sergiodj@redhat.com> PR corefiles/16092 * gdb.base/coredump-filter.c: New file. * gdb.base/coredump-filter.exp: Likewise.
2015-03-31Catch exception on solib_svr4_r_ldsomapSergio Durigan Junior1-0/+5
When loading a corefile that has some inaccessible memory region(s), GDB complains about it: (gdb) core /my/corefile [New LWP 28468] Cannot access memory at address 0x355fc21148 Cannot access memory at address 0x355fc21140 (gdb) However, despite not seeing the message "Core was generated by...", it is still possible to inspect the corefile using regular GDB commands. The reason for that is because read_memory_unsigned_integer throws an exception when it cannot read the memory region, but solib_svr4_r_ldsomap was not catching it. The fix is to catch the exception and act accordingly. Tested on Fedora 20 x86_64, no regressions found. gdb/ChangeLog: 2015-03-31 Sergio Durigan Junior <sergiodj@redhat.com> * solib-svr4.c (solib_svr4_r_ldsomap): Catch possible exception by read_memory_unsigned_integer.
2015-03-31Add --with-system-zlib in gdbH.J. Lu1-0/+14
This patch adds --with-system-zlib and removes --with-zlib in gdb. * Makefile.in (ZLIB): New. (ZLIBINC): Likewise. (INTERNAL_CFLAGS_BASE): Add $(ZLIBINC). (CLIBS): Add $(ZLIB). * acinclude.m4: (GDB_AC_CHECK_BFD): Add $zlibdir to LDFLAGS. Add -lz to LIBS. * gdb_bfd.c: Don't check HAVE_ZLIB_H to include <zlib.h>. * top.c (print_gdb_configuration): Remove --with-zlib and --without-zlib. * config.in: Regenerated. * configure: Likewise.
2015-03-31Add cpu information to the info os command on linux.Antoine Tremblay1-0/+7
This patch adds cpu information on linux based on /proc/cpuinfo as : cpus Listing of all cpus/cores on the system This patch also reorders the info os commands so that they are listed in alphabetical order. gdb/ChangeLog: * NEWS: Mention info os cpus support. * gdb/nat/linux-osdata.c (linux_xfer_osdata_cpus): New function. (struct osdata_type): Add cpus entry, reorder the entries in alphabetical order. gdb/doc/ChangeLog: * gdb.texinfo (Operating System Auxiliary Information): Add info os cpus documentation, reorder the info os entries in alphabetical order.
2015-03-31Fix the triplet regexp to recognize triplets, not only quadrupletsMatthias Klose1-0/+5
This allows triplets where the vendor is not set. gdb/ChangeLog: 2015-03-31 Matthias Klose <doko@ubuntu.com> * compile/compile.c (compile_to_object): Allow triplets with or without vendor set.
2015-03-30PR c++/18141Doug Evans1-0/+6
gdb/ChangeLog: PR c++/18141 * cp-namespace.c (cp_search_static_and_baseclasses): Always look for klass in VAR_DOMAIN.
2015-03-30Remove three redundant wrapper functions in remote.cGary Benson1-0/+9
gdb/ChangeLog: * remote.c (remote_mourn_1): Remove function. Update all callers to use remote_mourn. (extended_remote_mourn_1): Remove function. Update all callers to use extended_remote_mourn. (extended_remote_attach_1): Remove function. Update all callers to use extended_remote_attach.
2015-03-28gdb: ft32: new portJames Bowman1-0/+9
FT32 is a new high performance 32-bit RISC core developed by FTDI for embedded applications.
2015-03-27Revert: Code cleanup: Move print_command_1 expr variable scopeJan Kratochvil1-0/+7
Simon Marchi: I think this patch is wrong. Starting with that commit (f30d5c7), some tests (e.g. mi-break.exp) started to fail for me, because of gdb segfaulting. The address of expr is passed to the cleanup. When the cleanup is ran, expr is no longer in scope, so what is at that address is probably not safe to use anymore. That's my guess. gdb/ChangeLog 2015-03-27 Jan Kratochvil <jan.kratochvil@redhat.com> Revert: 2015-03-26 Jan Kratochvil <jan.kratochvil@redhat.com> Code cleanup. * printcmd.c (print_command_1): Move expr variable scope.
generated by cgit v1.1 at 2025-01-04 20:17:10 +0000