aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2014-03-11Automatic date update in version.inGDB Administrator1-1/+1
2014-03-10Automatic date update in version.inGDB Administrator1-1/+1
2014-03-09Automatic date update in version.inGDB Administrator1-1/+1
2014-03-08Automatic date update in version.inGDB Administrator1-1/+1
2014-03-07Automatic date update in version.inGDB Administrator1-1/+1
2014-03-06Automatic date update in version.inGDB Administrator1-1/+1
2014-03-05PR gdb/16575: stale breakpoint instructions in the code cachePedro Alves6-98/+114
In non-stop mode, or rather, breakpoints always-inserted mode, the code cache can easily end up with stale breakpoint instructions: All it takes is filling a cache line when breakpoints already exist in that memory region, and then delete the breakpoint. Vis. (from the new test): (gdb) set breakpoint always-inserted on (gdb) b 23 Breakpoint 2 at 0x400540: file ../../../src/gdb/testsuite/gdb.base/breakpoint-shadow.c, line 23. (gdb) b 24 Breakpoint 3 at 0x400547: file ../../../src/gdb/testsuite/gdb.base/breakpoint-shadow.c, line 24. disass main Dump of assembler code for function main: 0x000000000040053c <+0>: push %rbp 0x000000000040053d <+1>: mov %rsp,%rbp => 0x0000000000400540 <+4>: movl $0x1,-0x4(%rbp) 0x0000000000400547 <+11>: movl $0x2,-0x4(%rbp) 0x000000000040054e <+18>: mov $0x0,%eax 0x0000000000400553 <+23>: pop %rbp 0x0000000000400554 <+24>: retq End of assembler dump. So far so good. Now flush the code cache: (gdb) set code-cache off (gdb) set code-cache on Requesting a disassembly works as expected, breakpoint shadowing is applied: (gdb) disass main Dump of assembler code for function main: 0x000000000040053c <+0>: push %rbp 0x000000000040053d <+1>: mov %rsp,%rbp => 0x0000000000400540 <+4>: movl $0x1,-0x4(%rbp) 0x0000000000400547 <+11>: movl $0x2,-0x4(%rbp) 0x000000000040054e <+18>: mov $0x0,%eax 0x0000000000400553 <+23>: pop %rbp 0x0000000000400554 <+24>: retq End of assembler dump. However, now delete the breakpoints: (gdb) delete Delete all breakpoints? (y or n) y And disassembly shows the old breakpoint instructions: (gdb) disass main Dump of assembler code for function main: 0x000000000040053c <+0>: push %rbp 0x000000000040053d <+1>: mov %rsp,%rbp => 0x0000000000400540 <+4>: int3 0x0000000000400541 <+5>: rex.RB cld 0x0000000000400543 <+7>: add %eax,(%rax) 0x0000000000400545 <+9>: add %al,(%rax) 0x0000000000400547 <+11>: int3 0x0000000000400548 <+12>: rex.RB cld 0x000000000040054a <+14>: add (%rax),%al 0x000000000040054c <+16>: add %al,(%rax) 0x000000000040054e <+18>: mov $0x0,%eax 0x0000000000400553 <+23>: pop %rbp 0x0000000000400554 <+24>: retq End of assembler dump. Those breakpoint instructions are no longer installed in target memory they're stale in the code cache. Easily confirmed by just disabling the code cache: (gdb) set code-cache off (gdb) disass main Dump of assembler code for function main: 0x000000000040053c <+0>: push %rbp 0x000000000040053d <+1>: mov %rsp,%rbp => 0x0000000000400540 <+4>: movl $0x1,-0x4(%rbp) 0x0000000000400547 <+11>: movl $0x2,-0x4(%rbp) 0x000000000040054e <+18>: mov $0x0,%eax 0x0000000000400553 <+23>: pop %rbp 0x0000000000400554 <+24>: retq End of assembler dump. I stumbled upon this when writing a patch to infrun.c, that made handle_inferior_event & co fill in the cache before breakpoints were removed from the target. Recall that wait_for_inferior flushes the dcache for every event. So in that case, always-inserted mode was not necessary to trigger this. It's just a convenient way to expose the issue. The dcache works at the raw memory level. We need to update it whenever memory is written, no matter what kind of target memory object was originally passed down by the caller. The issue is that the dcache update code isn't reached when a caller explicitly writes raw memory. Breakpoint insertion/removal is one such case -- mem-break.c uses target_write_read_memory/target_write_raw_memory. The fix is to move the dcache update code from memory_xfer_partial_1 to raw_memory_xfer_partial so that it's always reachable. When we do that, we can actually simplify a series of things. memory_xfer_partial_1 no longer needs to handle writes for any kind of memory object, and therefore dcache_xfer_memory no longer needs to handle writes either. So the latter (dcache_xfer_memory) and its callees can be simplified to only care about reads. While we're touching dcache_xfer_memory's prototype, might as well rename it to reflect that fact that it only handles reads. Currently dcache_xfer_memory handles the case of a write failing. The whole cache line is invalidated when that happens. However, dcache_update, the sole mechanism for handling writes that will remain after the patch, does not presently handle that scenario. That's a bug. The patch makes it handle that, by passing down the to_xfer_partial result from the caller, so that it can better decide what to do itself. While I was changing the function's prototype, I constified the myaddr parameter, getting rid of the need for the cast as seen in its existing caller. Tested on x86_64 Fedora 17, native and gdbserver. gdb/ 2014-03-05 Pedro Alves <palves@redhat.com> PR gdb/16575 * dcache.c (dcache_poke_byte): Constify ptr parameter. Return void. Update comment. (dcache_xfer_memory): Delete. (dcache_read_memory_partial): New, based on the read bits of dcache_xfer_memory. (dcache_update): Add status parameter. Use ULONGEST for len, and adjust. Discard cache lines if the reason for the update was error. * dcache.h (dcache_xfer_memory): Delete declaration. (dcache_read_memory_partial): New declaration. (dcache_update): Update prototype. * target.c (raw_memory_xfer_partial): Update the dcache here. (memory_xfer_partial_1): Don't handle dcache writes here. gdb/testsuite/ 2014-03-05 Pedro Alves <palves@redhat.com> PR gdb/16575 * gdb.base/breakpoint-shadow.exp (compare_disassembly): New procedure. (top level): Adjust to use it. Add tests that exercise breakpoint interaction with the code-cache.
2014-03-05Automatic date update in version.inGDB Administrator1-1/+1
2014-03-04Automatic date update in version.inGDB Administrator1-1/+1
2014-03-03Automatic date update in version.inGDB Administrator1-1/+1
2014-03-02Automatic date update in version.inGDB Administrator1-1/+1
2014-03-01Automatic date update in version.inGDB Administrator1-1/+1
2014-02-28Automatic date update in version.inGDB Administrator1-1/+1
2014-02-27Automatic date update in version.inGDB Administrator1-1/+1
2014-02-26Make sure we don't resume the stepped thread by accident.Pedro Alves5-1/+285
Say: <stopped at a breakpoint in thread 2> (gdb) thread 3 (gdb) step The above triggers the prepare_to_proceed/deferred_step_ptid process, which switches back to thread 2, to step over its breakpoint before getting back to thread 3 and "step" it. If while stepping over the breakpoint in thread 2, a signal arrives, and it is set to pass/nostop, we'll set a step-resume breakpoint at the supposed signal-handler resume address, and call keep_going. The problem is that we were supposedly stepping thread 3, and that keep_going delivers a signal to thread 2, and due to scheduler-locking off, resumes everything else, _including_ thread 3, the thread we want stepping. This means that we lose control of thread 3 until the next event, when we stop everything. The end result for the user, is that GDB lost control of the "step". Here's the current infrun debug output of the above, with the testcase in the patch below: infrun: clear_proceed_status_thread (Thread 0x2aaaab8f5700 (LWP 11663)) infrun: clear_proceed_status_thread (Thread 0x2aaaab6f4700 (LWP 11662)) infrun: clear_proceed_status_thread (Thread 0x2aaaab4f2b20 (LWP 11659)) infrun: proceed (addr=0xffffffffffffffff, signal=144, step=1) infrun: prepare_to_proceed (step=1), switched to [Thread 0x2aaaab6f4700 (LWP 11662)] infrun: resume (step=1, signal=0), trap_expected=1, current thread [Thread 0x2aaaab6f4700 (LWP 11662)] at 0x40098f infrun: wait_for_inferior () infrun: target_wait (-1, status) = infrun: 11659 [Thread 0x2aaaab6f4700 (LWP 11662)], infrun: status->kind = stopped, signal = SIGUSR1 infrun: infwait_normal_state infrun: TARGET_WAITKIND_STOPPED infrun: stop_pc = 0x40098f infrun: random signal 30 Program received signal SIGUSR1, User defined signal 1. infrun: signal arrived while stepping over breakpoint infrun: inserting step-resume breakpoint at 0x40098f infrun: resume (step=0, signal=30), trap_expected=0, current thread [Thread 0x2aaaab6f4700 (LWP 11662)] at 0x40098f ^^^ this is a wildcard resume. infrun: prepare_to_wait infrun: target_wait (-1, status) = infrun: 11659 [Thread 0x2aaaab6f4700 (LWP 11662)], infrun: status->kind = stopped, signal = SIGTRAP infrun: infwait_normal_state infrun: TARGET_WAITKIND_STOPPED infrun: stop_pc = 0x40098f infrun: BPSTAT_WHAT_STEP_RESUME infrun: resume (step=1, signal=0), trap_expected=1, current thread [Thread 0x2aaaab6f4700 (LWP 11662)] at 0x40098f ^^^ step-resume hit, meaning the handler returned, so we go back to stepping thread 3. infrun: prepare_to_wait infrun: target_wait (-1, status) = infrun: 11659 [Thread 0x2aaaab6f4700 (LWP 11662)], infrun: status->kind = stopped, signal = SIGTRAP infrun: infwait_normal_state infrun: TARGET_WAITKIND_STOPPED infrun: stop_pc = 0x40088b infrun: switching back to stepped thread infrun: Switching context from Thread 0x2aaaab6f4700 (LWP 11662) to Thread 0x2aaaab8f5700 (LWP 11663) infrun: resume (step=1, signal=0), trap_expected=0, current thread [Thread 0x2aaaab8f5700 (LWP 11663)] at 0x400938 infrun: prepare_to_wait infrun: target_wait (-1, status) = infrun: 11659 [Thread 0x2aaaab8f5700 (LWP 11663)], infrun: status->kind = stopped, signal = SIGTRAP infrun: infwait_normal_state infrun: TARGET_WAITKIND_STOPPED infrun: stop_pc = 0x40093a infrun: keep going infrun: resume (step=1, signal=0), trap_expected=0, current thread [Thread 0x2aaaab8f5700 (LWP 11663)] at 0x40093a infrun: prepare_to_wait infrun: target_wait (-1, status) = infrun: 11659 [Thread 0x2aaaab8f5700 (LWP 11663)], infrun: status->kind = stopped, signal = SIGTRAP infrun: infwait_normal_state infrun: TARGET_WAITKIND_STOPPED infrun: stop_pc = 0x40091e infrun: stepped to a different line infrun: stop_stepping [Switching to Thread 0x2aaaab8f5700 (LWP 11663)] 69 (*myp) ++; /* set breakpoint child_two here */ ^^^ we stopped at the wrong line. We still stepped a bit because the test is running in a loop, and when we got back to stepping thread 3, it happened to be in the stepping range. (The loop increments a counter, and the test makes sure it increments exactly once. Without the fix, the counter increments a bunch, since the user-stepped thread runs free without GDB noticing.) The fix is to switch to the stepping thread before continuing for the step-resume breakpoint. gdb/ 2014-02-26 Pedro Alves <palves@redhat.com> PR breakpoints/16292 * infrun.c (handle_signal_stop) <signal arrives while stepping over a breakpoint>: Switch back to the stepping thread. gdb/testsuite/ 2014-02-26 Pedro Alves <pedro@codesourcery.com> Pedro Alves <palves@redhat.com> PR breakpoints/16292 * gdb.threads/signal-while-stepping-over-bp-other-thread.c: New file. * gdb.threads/signal-while-stepping-over-bp-other-threadexp: New file.
2014-02-26Automatic date update in version.inGDB Administrator1-1/+1
2014-02-25PR gdb/16626Jan Kratochvil2-2/+5
gdb/testsuite/ 2014-02-25 Jan Kratochvil <jan.kratochvil@redhat.com> PR gdb/16626 * gdb.base/auto-load.exp: Fix out-of-srctree run. Message-ID: <87k3cjt3jl.fsf@fleche.redhat.com>
2014-02-25PR gdb/16626Jan Kratochvil6-3/+96
Fix auto-load 7.7 regression, the regression affects any loading from /usr/share/gdb/auto-load . 5b2bf9471f1499bee578fcd60c05afe85794e280 is the first bad commit commit 5b2bf9471f1499bee578fcd60c05afe85794e280 Author: Doug Evans <xdje42@gmail.com> Date: Fri Nov 29 21:29:26 2013 -0800 Move .debug_gdb_script processing to auto-load.c. Simplify handling of auto-loaded objfile scripts. Fedora 20 x86_64 $ gdb -q /usr/lib64/libgobject-2.0.so Reading symbols from /usr/lib64/libglib-2.0.so.0.3800.2...Reading symbols from /usr/lib/debug/usr/lib64/libglib-2.0.so.0.3800.2.debug...done. done. (gdb) _ Fedora Rawhide x86_64 $ gdb -q /usr/lib64/libgobject-2.0.so Reading symbols from /usr/lib64/libglib-2.0.so...Reading symbols from /usr/lib/debug/usr/lib64/libglib-2.0.so.0.3990.0.debug...done. done. warning: File "/usr/lib64/libglib-2.0.so.0.3990.0-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load:/usr/bin/mono-gdb.py". To enable execution of this file add add-auto-load-safe-path /usr/lib64/libglib-2.0.so.0.3990.0-gdb.py line to your configuration file "/home/jkratoch/.gdbinit". To completely disable this security protection add set auto-load safe-path / line to your configuration file "/home/jkratoch/.gdbinit". For more information about this security protection see the "Auto-loading safe path" section in the GDB manual. E.g., run from the shell: info "(gdb)Auto-loading safe path" (gdb) _ That is it tries to load "forbidden" /usr/lib64/libglib-2.0.so.0.3990.0-gdb.py but it should load instead /usr/share/gdb/auto-load/usr/lib64/libglib-2.0.so.0.3990.0-gdb.py* Although that is also not exactly this way, there does not exist any /usr/lib64/libglib-2.0.so.0.3990.0-gdb.py despite regressed GDB says so. gdb/ 2014-02-24 Jan Kratochvil <jan.kratochvil@redhat.com> PR gdb/16626 * auto-load.c (auto_load_objfile_script_1): Change filename to debugfile. gdb/testsuite/ 2014-02-24 Jan Kratochvil <jan.kratochvil@redhat.com> PR gdb/16626 * gdb.base/auto-load-script: New file. * gdb.base/auto-load.c: New file. * gdb.base/auto-load.exp: New file. Message-ID: <20140223212400.GA8831@host2.jankratochvil.net>
2014-02-25Automatic date update in version.inGDB Administrator1-1/+1
2014-02-24Automatic date update in version.inGDB Administrator1-1/+1
2014-02-23Automatic date update in version.inGDB Administrator1-1/+1
2014-02-22Automatic date update in version.inGDB Administrator1-1/+1
2014-02-21Automatic date update in version.inGDB Administrator1-1/+1
2014-02-20Automatic date update in version.inGDB Administrator1-1/+1
2014-02-19Automatic date update in version.inGDB Administrator1-1/+1
2014-02-18Automatic date update in version.inGDB Administrator1-1/+1
2014-02-17Automatic date update in version.inGDB Administrator1-1/+1
2014-02-16Automatic date update in version.inGDB Administrator1-1/+1
2014-02-15Automatic date update in version.inGDB Administrator1-1/+1
2014-02-14Automatic date update in version.inGDB Administrator1-1/+1
2014-02-13Automatic date update in version.inGDB Administrator1-1/+1
2014-02-12Automatic date update in version.inGDB Administrator1-1/+1
2014-02-11Automatic date update in version.inGDB Administrator1-1/+1
2014-02-10 PR build/16550Rainer Orth2-1/+6
* cache.c (bfd_cache_max_open): Cast RLIM_INFINITY to rlim_t.
2014-02-10Automatic date update in version.inGDB Administrator1-1/+1
2014-02-09Fix Python stack corruptionJan Kratochvil2-2/+8
The fix is obvious. gdb/ 2014-02-09 Jan Kratochvil <jan.kratochvil@redhat.com> Fix Python stack corruption. * python/py-linetable.c (ltpy_get_pcs_for_line, ltpy_has_line): Use gdb_py_longest. Message-ID: <20140207171701.GA25187@host2.jankratochvil.net>
2014-02-09Automatic date update in version.inGDB Administrator1-1/+1
2014-02-08Automatic date update in version.inGDB Administrator1-1/+1
2014-02-07Automatic date update in version.inGDB Administrator1-1/+1
2014-02-06Bump GDB version number to 7.7.0.DATE-cvs.Joel Brobecker2-1/+5
gdb/ChangeLog: * version.in: Set GDB version number to 7.7.0.DATE-cvs.
2014-02-06Document the GDB 7.7 release in gdb/ChangeLogJoel Brobecker1-0/+4
gdb/ChangeLog: GDB 7.7 released.
2014-02-06Set GDB version number to 7.7.gdb-7.7-releaseJoel Brobecker2-1/+5
gdb/ChangeLog: * version.in: Set GDB version number to 7.7.
2014-02-06NEWS: Rename "Changes since GDB 7.6" into "Changes in GDB 7.7"Joel Brobecker2-1/+5
gdb/ChangeLog: * NEWS: Change "Changes since GDB 7.6" to "Changes in GDB 7.7".
2014-02-06Automatic date update in version.inGDB Administrator1-1/+1
2014-02-05Create inferior for ctf target.Yao Qi4-1/+44
This patch creates inferior when GDB opens a ctf trace data, to be consistent with tfile target. A test case is added to test for live target, tfile and ctf target. gdb: 2014-02-05 Yao Qi <yao@codesourcery.com> * ctf.c: Include "inferior.h" and "gdbthread.h". (CTF_PID): A new macro. (ctf_open): Call inferior_appeared and add_thread_silent. (ctf_close): Call exit_inferior_silent and set inferior_ptid. (ctf_thread_alive): New function. (init_ctf_ops): Install ctf_thread_alive to to_thread_alive. gdb/testsuite: 2014-02-05 Yao Qi <yao@codesourcery.com> * gdb.trace/report.exp (use_collected_data): Test the output of "info threads" and "info inferiors".
2014-02-05Create inferior for tfile targetYao Qi4-3/+41
When a trace file is loaded in Eclipse, it is expected to see thread and process (=thread-group-started and =thread-created). Create an inferior and add a thread for this purpose. This patch just reverts my previous patch. gdb/testsuite: 2014-02-05 Yao Qi <yao@codesourcery.com> Revert this patch: 2013-05-24 Yao Qi <yao@codesourcery.com> * gdb.trace/tfile.exp: Test inferior and thread. gdb: 2014-02-05 Yao Qi <yao@codesourcery.com> Revert this patch: 2013-05-24 Yao Qi <yao@codesourcery.com> * tracepoint.c (TFILE_PID): Remove. (tfile_open): Don't add thread and inferior. (tfile_close): Don't set 'inferior_ptid'. Don't call exit_inferior_silent. (tfile_thread_alive): Remove. (init_tfile_ops): Don't set field 'to_thread_alive' of tfile_ops.
2014-02-05Automatic date update in version.inGDB Administrator1-1/+1
2014-02-04Automatic date update in version.inGDB Administrator1-1/+1
2014-02-03Automatic date update in version.inGDB Administrator1-1/+1
2014-02-02Fix shift for AVX512F gather/scatter instructionsMichael Zolotukhin7-35/+49
opcodes/ 2014-01-30 Michael Zolotukhin <michael.v.zolotukhin@gmail.com> Jan Beulich <jbeulich@suse.com> PR binutils/16490 * i386-dis.c (OP_E_memory): Fix shift computation for vex_vsib_q_w_dq_mode. gas/testsuite/ 2014-01-30 Michael Zolotukhin <michael.v.zolotukhin@gmail.com> Jan Beulich <jbeulich@suse.com> PR binutils/16490 * gas/i386/avx512f.d: Fix test output. * gas/i386/avx512f-intel.d: Likewise. * gas/i386/x86-64-avx512f.d: Likewise. * gas/i386/x86-64-avx512f-intel.d: Likewise. Conflicts: gas/testsuite/ChangeLog
generated by cgit v1.1 at 2025-09-19 21:28:14 +0000