mirror of
https://sourceware.org/git/binutils-gdb.git
synced 2024-12-01 05:55:23 +08:00
740feeaa20
4 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
Joel Brobecker
|
618f726fcb |
GDB copyright headers update after running GDB's copyright.py script.
gdb/ChangeLog:
Update year range in copyright notice of all files.
|
||
|
Joel Brobecker
|
32d0add0a6 |
Update year range in copyright notice of all files owned by the GDB project.
gdb/ChangeLog:
Update year range in copyright notice of all files.
|
||
Pedro Alves
|
7c16b83e05 |
Put single-step breakpoints on the bp_location chain
This patch makes single-step breakpoints "real" breakpoints on the global location list. There are several benefits to this: - It removes the currently limitation that only 2 single-step breakpoints can be inserted. See an example here of a discussion around a case that wants more than 2, possibly unbounded: https://sourceware.org/ml/gdb-patches/2014-03/msg00663.html - makes software single-step work on read-only code regions. The logic to convert a software breakpoint to a hardware breakpoint if the memory map says the breakpoint address is in read only memory is in insert_bp_location. Because software single-step breakpoints bypass all that go and straight to target_insert_breakpoint, we can't software single-step over read only memory. This patch removes that limitation, and adds a test that makes sure that works, by forcing a code region to read-only with "mem LOW HIGH ro" and then stepping through that. - Fixes PR breakpoints/9649 This is an assertion failure in insert_single_step_breakpoint in breakpoint.c, because we may leave stale single-step breakpoints behind on error. The tests for stepping through read-only regions exercise the root cause of the bug, which is that we leave single-step breakpoints behind if we fail to insert any single-step breakpoint. Deleting the single-step breakpoints in resume_cleanups, delete_just_stopped_threads_infrun_breakpoints, and fetch_inferior_event fixes this. Without that, we'd no longer hit the assertion, as that code is deleted, but we'd instead run into errors/warnings trying to insert/remove the stale breakpoints on next resume. - Paves the way to have multiple threads software single-stepping at the same time, leaving update_global_location_list to worry about duplicate locations. - Makes the moribund location machinery aware of software single-step breakpoints, paving the way to enable software single-step on non-stop, instead of forcing serialized displaced stepping for all single steps. - It's generaly cleaner. We no longer have to play games with single-step breakpoints inserted at the same address as regular breakpoints, like we recently had to do for 7.8. See this discussion: https://sourceware.org/ml/gdb-patches/2014-06/msg00052.html. Tested on x86_64 Fedora 20, on top of my 'single-step breakpoints on x86' series. gdb/ 2014-10-15 Pedro Alves <palves@redhat.com> PR breakpoints/9649 * breakpoint.c (single_step_breakpoints, single_step_gdbarch): Delete array globals. (single_step_breakpoints): New global. (breakpoint_xfer_memory): Remove special handling for single-step breakpoints. (update_breakpoints_after_exec): Delete bp_single_step breakpoints. (detach_breakpoints): Remove special handling for single-step breakpoints. (breakpoint_init_inferior): Delete bp_single_step breakpoints. (bpstat_stop_status): Add comment. (bpstat_what, bptype_string, print_one_breakpoint_location) (adjust_breakpoint_address, init_bp_location): Handle bp_single_step. (new_single_step_breakpoint): New function. (set_momentary_breakpoint, bkpt_remove_location): Remove special handling for single-step breakpoints. (insert_single_step_breakpoint, single_step_breakpoints_inserted) (remove_single_step_breakpoints, cancel_single_step_breakpoints): Rewrite. (detach_single_step_breakpoints, find_single_step_breakpoint): Delete functions. (breakpoint_has_location_inserted_here): New function. (single_step_breakpoint_inserted_here_p): Rewrite. * breakpoint.h: Remove FIXME. (enum bptype) <bp_single_step>: New enum value. (insert_single_step_breakpoint): Update comment. * infrun.c (resume_cleanups) (delete_step_thread_step_resume_breakpoint): Remove single-step breakpoints. (fetch_inferior_event): Install a cleanup that removes infrun breakpoints. (switch_back_to_stepped_thread) <expect thread advanced also>: Clear step-over info. gdb/testsuite/ 2014-10-15 Pedro Alves <palves@redhat.com> PR breakpoints/9649 * gdb.base/breakpoint-in-ro-region.c (main): Add more instructions. * gdb.base/breakpoint-in-ro-region.exp (probe_target_hardware_step): New procedure. (top level): Probe hardware stepping and hardware breakpoint support. Test stepping through a read-only region, with both "breakpoint auto-hw" on and off and both "always-inserted" on and off. |
||
|
Pedro Alves
|
0fec99e8be |
Really fail inserting software breakpoints on read-only regions
Currently, with "set breakpoint auto-hw off", we'll still try to
insert a software breakpoint at addresses covered by supposedly
read-only or inacessible regions:
(top-gdb) mem 0x443000 0x450000 ro
(top-gdb) set mem inaccessible-by-default off
(top-gdb) disassemble
Dump of assembler code for function main:
0x0000000000443956 <+34>: movq $0x0,0x10(%rax)
=> 0x000000000044395e <+42>: movq $0x0,0x18(%rax)
0x0000000000443966 <+50>: mov -0x24(%rbp),%eax
0x0000000000443969 <+53>: mov %eax,-0x20(%rbp)
End of assembler dump.
(top-gdb) b *0x0000000000443969
Breakpoint 5 at 0x443969: file ../../src/gdb/gdb.c, line 29.
(top-gdb) c
Continuing.
warning: cannot set software breakpoint at readonly address 0x443969
Breakpoint 5, 0x0000000000443969 in main (argc=1, argv=0x7fffffffd918) at ../../src/gdb/gdb.c:29
29 args.argc = argc;
(top-gdb)
We warn, saying that the insertion can't be done, but then proceed
attempting the insertion anyway, and in case of manually added
regions, the insert actually succeeds.
This is a regression; GDB used to fail inserting the breakpoint. More
below.
I stumbled on this as I wrote a test that manually sets up a read-only
memory region with the "mem" command, in order to test GDB's behavior
with breakpoints set on read-only regions, even when the real memory
the breakpoints are set at isn't really read-only. I wanted that in
order to add a test that exercises software single-stepping through
read-only regions.
Note that the memory regions that target_memory_map returns aren't
like e.g., what would expect to see in /proc/PID/maps on Linux.
Instead, they're the physical memory map from the _debuggers_
perspective. E.g., a read-only region would be real ROM or flash
memory, while a read-only+execute mapping in /proc/PID/maps is still
read-write to the debugger (otherwise the debugger wouldn't be able to
set software breakpoints in the code segment).
If one tries to manually write to memory that falls within a memory
region that is known to be read-only, with e.g., "p foo = 1", then we
hit a check in memory_xfer_partial_1 before the write mananges to make
it to the target side.
But writing a software/memory breakpoint nowadays goes through
target_write_raw_memory, and unlike when writing memory with
TARGET_OBJECT_MEMORY, nothing on the TARGET_OBJECT_RAW_MEMORY path
checks whether we're trying to write to a read-only region.
At the time "breakpoint auto-hw" was added, we didn't have the
TARGET_OBJECT_MEMORY vs TARGET_OBJECT_RAW_MEMORY target object
distinction yet, and the code path in memory_xfer_partial that blocks
writes to read-only memory was hit for memory breakpoints too. With
GDB 6.8 we had:
warning: cannot set software breakpoint at readonly address 0000000000443943
Warning:
Cannot insert breakpoint 1.
Error accessing memory address 0x443943: Input/output error.
So I started out by fixing this by adding the memory region validation
to TARGET_OBJECT_RAW_MEMORY too.
But later, when testing against GDBserver, I realized that that would
only block software/memory breakpoints GDB itself inserts with
gdb/mem-break.c. If a target has a to_insert_breakpoint method, the
insertion request will still pass through to the target. So I ended
up converting the "cannot set breakpoint" warning in breakpoint.c to a
real error return, thus blocking the insertion sooner.
With that, we'll end up no longer needing the TARGET_OBJECT_RAW_MEMORY
changes once software single-step breakpoints are converted to real
breakpoints. We need them today as software single-step breakpoints
bypass insert_bp_location. But, it'll be best to leave that in as
safeguard anyway, for other direct uses of TARGET_OBJECT_RAW_MEMORY.
Tested on x86_64 Fedora 20, native and gdbserver.
gdb/
2014-10-01 Pedro Alves <palves@redhat.com>
* breakpoint.c (insert_bp_location): Error out if inserting a
software breakpoint at a read-only address.
* target.c (memory_xfer_check_region): New function, factored out
from ...
(memory_xfer_partial_1): ... this. Make the 'reg_len' local a
ULONGEST.
(target_xfer_partial) <TARGET_OBJECT_RAW_MEMORY>: Check the access
against the memory region attributes.
gdb/testsuite/
2014-10-01 Pedro Alves <palves@redhat.com>
* gdb.base/breakpoint-in-ro-region.c: New file.
* gdb.base/breakpoint-in-ro-region.exp: New file.
|