aboutsummaryrefslogtreecommitdiff
path: root/gdb
AgeCommit message (Collapse)AuthorFilesLines
2020-07-13Use volatile pointers when attempting to trigger SIGSEGVsGary Benson6-5/+14
Clang fails to compile a number of files with the following warning: indirection of non-volatile null pointer will be deleted, not trap [-Wnull-dereference]. This commit qualifies the relevant pointers with 'volatile'. gdb/testsuite/ChangeLog: * gdb.base/bigcore.c (main): Use a volatile pointer when attempting to trigger a SIGSEGV. * gdb.base/gcore-relro-pie.c (break_here): Likewise. * gdb.base/gcore-tls-pie.c (break_here): Likewise. * gdb.base/savedregs.c (thrower): Likewise. * gdb.mi/mi-syn-frame.c (bar): Likewise.
2020-07-13Skip VLA structure field tests when compiling with clangGary Benson5-77/+180
Clang fails to compile gdb.base/vla-datatypes.c with the following error: fields must have a constant size: 'variable length array in structure' extension will never be supported. This commit factors the affected tests out into a new testcase, vla-struct-fields.{exp,c}, which is skipped when the testcase is compiled using clang, gdb/testsuite/ChangeLog: * gdb.base/vla-datatypes.c (vla_factory): Factor out sections defining and using VLA structure fields into... * gdb.base/vla-struct-fields.c: New file. * gdb.base/vla-datatypes.exp: Factor out VLA structure field tests into... * gdb.base/vla-struct-fields.exp: New file.
2020-07-13[gdb/testsuite] Handle missing gold linker in gdb.base/morestack.expTom de Vries5-2/+29
When running test-case gdb.base/morestack.exp without the gold linker installed, we run into: ... Running src/gdb/testsuite/gdb.base/morestack.exp ... gdb compile failed, collect2: fatal error: cannot find 'ld' compilation terminated. FAIL: gdb.base/morestack.exp: continue === gdb Summary === nr of expected passes 1 nr of unexpected failures 1 nr of untested testcases 1 ... The test-case needs the gold linker to run correctly (as explained in commit b8d38ee425 "testsuite: Fix false FAIL for gdb.base/morestack.exp"), but only prefers it, and doesn't require it. Fix this by requiring the gold linker in the test-case. Furthermore, silence the compilation error by introducing a caching proc have_fuse_ld_gold and using it in this and other test-cases that use -fuse-ld=gold. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-07-13 Tom de Vries <tdevries@suse.de> * lib/gdb.exp (have_fuse_ld_gold): New caching proc. * gdb.base/gcore-tls-pie.exp: Use have_fuse_ld_gold. * gdb.base/gold-gdb-index.exp: Same. * gdb.base/morestack.exp: Same.
2020-07-12gdb: make type::bounds work for array and string typesSimon Marchi17-44/+69
Getting the bounds of an array (or string) type is a common operation, and is currently done through its index type: my_array_type->index_type ()->bounds () I think it would make sense to let the `type::bounds` methods work for arrays and strings, as a shorthand for this. It's natural that when asking for the bounds of an array, we get the bounds of the range type used as its index type. In a way, it's equivalent as the now-removed TYPE_ARRAY_{LOWER,UPPER}_BOUND_IS_UNDEFINED and TYPE_ARRAY_{LOWER,UPPER}_BOUND_VALUE, except it returns the `range_bounds` object. The caller is then responsible for getting the property it needs in it. I updated all the spots I could find that could take advantage of this. Note that this also makes `type::bit_stride` work on array types, since `type::bit_stride` uses `type::bounds`. `my_array_type->bit_stride ()` now returns the bit stride of the array's index type. So some spots are also changed to take advantage of this. gdb/ChangeLog: * gdbtypes.h (struct type) <bounds>: Handle array and string types. * ada-lang.c (assign_aggregate): Use type::bounds on array/string type. * c-typeprint.c (c_type_print_varspec_suffix): Likewise. * c-varobj.c (c_number_of_children): Likewise. (c_describe_child): Likewise. * eval.c (evaluate_subexp_for_sizeof): Likewise. * f-typeprint.c (f_type_print_varspec_suffix): Likewise. (f_type_print_base): Likewise. * f-valprint.c (f77_array_offset_tbl): Likewise. (f77_get_upperbound): Likewise. (f77_print_array_1): Likewise. * guile/scm-type.c (gdbscm_type_range): Likewise. * m2-typeprint.c (m2_array): Likewise. (m2_is_long_set_of_type): Likewise. * m2-valprint.c (get_long_set_bounds): Likewise. * p-typeprint.c (pascal_type_print_varspec_prefix): Likewise. * python/py-type.c (typy_range): Likewise. * rust-lang.c (rust_internal_print_type): Likewise. * type-stack.c (type_stack::follow_types): Likewise. * valarith.c (value_subscripted_rvalue): Likewise. * valops.c (value_cast): Likewise. Change-Id: I5c0c08930bffe42fd69cb4bfcece28944dd88d1f
2020-07-12gdb: remove TYPE_ARRAY_BIT_STRIDESimon Marchi4-9/+8
Remove it and update all callers to use the equivalent accessor methods. A subsequent patch will make type::bit_stride work for array types (effectively replacing this macro), but I wanted to keep this patch a simple mechanical change. gdb/ChangeLog: * gdbtypes.c (TYPE_ARRAY_BIT_STRIDE): Remove. Update all callers to use the equivalent accessor methods. Change-Id: I09e14bd45075f98567adce8a0b93edea7722f812
2020-07-12gdb: remove TYPE_BIT_STRIDESimon Marchi3-6/+22
Remove the macro and add a `bit_stride` method to `struct range_bounds`, which does the byte -> bit conversion if needed. Add a convenience `bit_stride` method to `struct type` as well. I don't really understand why the bit/byte stride is stored in the data structure for bounds. Maybe it was just put there because `range_bounds` was already a data structure specific to TYPE_CODE_RANGE types? If the stride is indeed not related to the bounds, then I find it more logical to do `my_range_type->bit_stride ()` than `my_range_type->bounds ()->bit_stride ()`, hence the convenience function on `struct type`. gdb/ChangeLog: * gdbtypes.h (struct range_bounds) <bit_stride>: New method. (struct type) <bit_stride>: New method. (TYPE_BIT_STRIDE): Remove. * gdbtypes.c (update_static_array_size): Use type::bit_stride. Change-Id: I6ecc1cfefdc20711fa8f188a94a05c1e116c9922
2020-07-12gdb: remove TYPE_ARRAY_{LOWER,UPPER}_BOUND_VALUESimon Marchi5-12/+12
Remove the macros, use the various equivalent getters instead. gdb/ChangeLog: * gdbtypes.h (TYPE_ARRAY_LOWER_BOUND_VALUE, TYPE_ARRAY_UPPER_BOUND_VALUE): Remove. Update all callers to use the equivalent accessor methods instead. Change-Id: I7f96d988f872170e7a2f58095832710e62b85cfd
2020-07-12gdb: remove TYPE_ARRAY_{UPPER,LOWER}_BOUND_IS_UNDEFINEDSimon Marchi9-17/+20
Remove the macros, use the various equivalent getters instead. gdb/ChangeLog: * gdbtypes.h (TYPE_ARRAY_UPPER_BOUND_IS_UNDEFINED, TYPE_ARRAY_LOWER_BOUND_IS_UNDEFINED): Remove. Update all callers to use the equivalent accessor methods instead. Change-Id: Ifb4c36f440b82533bde5d15a5cbb2fc91f467292
2020-07-12gdb: remove TYPE_LOW_BOUND_KIND and TYPE_HIGH_BOUND_KINDSimon Marchi7-16/+18
Remove the macros, use the getters of `struct dynamic_prop` instead. gdb/ChangeLog: * gdbtypes.h (TYPE_LOW_BOUND_KIND, TYPE_HIGH_BOUND_KIND): Remove. Update all callers to use dynamic_prop::kind. Change-Id: Icb1fc761f675bfac934209f8102392504d905c44
2020-07-12gdb: remove TYPE_LOW_BOUND_UNDEFINED and TYPE_HIGH_BOUND_UNDEFINEDSimon Marchi5-12/+17
Remove the macros, use the getters of `struct dynamic_prop` instead. gdb/ChangeLog: * gdbtypes.h (TYPE_LOW_BOUND_UNDEFINED, TYPE_HIGH_BOUND_UNDEFINED): Remove. Update all callers to get the bound property's kind and check against PROP_UNDEFINED. Change-Id: I6a7641ac1aa3fa7fca0c21f00556f185f2e2d68c
2020-07-12gdb: remove TYPE_HIGH_BOUND and TYPE_LOW_BOUNDSimon Marchi15-53/+58
Remove the macros, use the getters of `struct dynamic_prop` instead. gdb/ChangeLog: * gdbtypes.h (TYPE_LOW_BOUND, TYPE_HIGH_BOUND): Remove. Update all callers to use type::range_bounds followed by dynamic_prop::{low,high}. Change-Id: I31beeed65d94d81ac4f999244a8b859e2ee961d1
2020-07-12gdb: add accessors to struct dynamic_propSimon Marchi12-135/+183
Add setters, to ensure that the kind and value of the property are always kept in sync (a caller can't forget one or the other). Add getters, such that we can assert that when a caller accesses a data bit of the property, the property is indeed of the corresponding kind. Note that because of the way `struct dynamic_prop` is allocated currently, we can't make the `m_kind` and `m_data` fields private. That would make the type non-default-constructible, and we would have to call the constructor when allocating them. However, I still prefixed them with `m_` to indicate that they should not be accessed from outside the class (and also to be able to use the name `kind` for the method). gdb/ChangeLog: * gdbtypes.h (struct dynamic_prop) <kind, set_undefined, const_val, set_const_val, baton, set_locexpr, set_loclist, set_addr_offset, variant_parts, set_variant_parts, original_type, set_original_type>: New methods. <kind>: Rename to... <m_kind>: ... this. Update all users to use the new methods instead. <data>: Rename to... <m_data>: ... this. Update all users to use the new methods instead. Change-Id: Ib72a8eb440dfeb1a5421d0933334230d7f2478f9
2020-07-12gdb: make get_discrete_bounds check for non-constant range boundsSimon Marchi2-16/+20
The next patch adds getters to the `dynamic_prop` structure. These getters validate that the accessed data matches the property kind (for example, to access the `const_val` field, the property must be of kind `PROP_CONST`). It found one instance where we are accessing the `const_val` data of a property that has the undefined kind. This happens in function `get_discrete_bounds`, and is exposed by test gdb.base/ptype.exp, amongst others. Without this patch, we would get: $ ./gdb -q -nx --data-directory=data-directory testsuite/outputs/gdb.base/ptype/ptype -ex "ptype t_char_array" Reading symbols from testsuite/outputs/gdb.base/ptype/ptype... type = char [ /home/smarchi/src/binutils-gdb/gdb/gdbtypes.h:526: internal-error: LONGEST dynamic_prop::const_val() const: Assertion `m_kind == PROP_CONST' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) The `get_discrete_bounds` function returns the bounds of a type (not only range types). For range types, it naturally uses the bound properties that are intrinsic to the range type. It accesses these properties using TYPE_LOW_BOUND and TYPE_HIGH_BOUND, which assume the properties are defined and have constant values. This is sometimes not the case, and the passed range type (as in the example above) has an undefined high/upper bound. Given its current interface (returning two LONGEST values for low and high), `get_discrete_bounds` can't really work if the range type's bounds are not both defined and both constant values. This patch changes the function to return -1 (failure to get the bounds) if any of the range type's bounds is not a constant value. It is sufficient to fix the issue and it seems to keep the callers happy, at least according to the testsuite. A bit in `get_array_bounds` could be removed, since `get_discrete_bounds` no longer returns 1 if a bound is undefined. gdb/ChangeLog: * gdbtypes.c (get_discrete_bounds): Return failure if the range type's bounds are not both defined and constant values. (get_array_bounds): Update comment. Remove undefined bound check. Change-Id: I047a3beee2c1e275f888cfc4778228339922bde9
2020-07-12gdb: remove TYPE_RANGE_DATA macroSimon Marchi11-32/+34
Remove it in favor of using type::bounds directly. gdb/ChangeLog: * gdbtypes.h (TYPE_RANGE_DATA): Remove. Update callers to use the type::bounds method directly. Change-Id: Id4fab22af0a94cbf505f78b01b3ee5b3d682fba2
2020-07-12gdb: add type::bounds / type::set_boundsSimon Marchi4-12/+39
Add the `bounds` and `set_bounds` methods on `struct type`, in order to remove the `TYPE_RANGE_DATA` macro. In this patch, the `TYPE_RANGE_DATA` macro is changed to use `type::bounds`, so all the call sites that are used to set a range type's bounds are changed to use `type::set_bounds`. The next patch will remove `TYPE_RANGE_DATA` completely. gdb/ChangeLog: * gdbtypes.h (struct type) <bounds, set_bounds>: New methods. (TYPE_RANGE_DATA): Use type::bounds. Change all uses that are used to set the range type's bounds to use set_bounds. Change-Id: I62e15506239b98404e62bbea8120db184ed87847
2020-07-11rust: Fix rust modules testDaniel Xu2-1/+8
I noticed that the modules test was failing. Some choice use of `nm` revealed `TWENTY_THREE` was not in the final binary. Fix by taking a pointer to the global, forcing the linker to keep the symbol in. gdb/testsuite/ChangeLog 2020-07-11 Daniel Xu <dxu@dxuuu.xyz> PR rust/26121 * gdb.rust/modules.rs: Prevent linker from discarding test symbol. Signed-off-by: Daniel Xu <dxu@dxuuu.xyz>
2020-07-11Fine tune exec-file-mismatch help and documentation.Philippe Waroquiers4-2/+16
It was deemed better to explicitly mention in help and doc that build IDs are used for comparison, and that symbols are loaded when asking to load the exec-file. This is V2, fixing 2 typos and replacing 'If the user asks to load' by 'If the user confirms loading', as suggested by Pedro. gdb/ChangeLog 2020-07-11 Philippe Waroquiers <philippe.waroquiers@skynet.be> * exec.c (_initialize_exec): Update exec-file-mismatch help. gdb/doc/ChangeLog 2020-07-11 Philippe Waroquiers <philippe.waroquiers@skynet.be> * gdb.texinfo (Attach): Update exec-file-mismatch doc.
2020-07-10Fix crash if connection drops in scoped_restore_current_thread's ctor, part 2Pedro Alves3-19/+36
Running the testsuite against an Asan-enabled build of GDB makes gdb.base/multi-target.exp expose this bug. scoped_restore_current_thread's ctor calls get_frame_id to record the selected frame's ID to restore later. If the frame ID hasn't been computed yet, it will be computed on the spot, and that will usually require accessing the target's memory and registers. If the remote connection closes, while we're computing the frame ID, the remote target exits its inferiors, unpushes itself, and throws a TARGET_CLOSE_ERROR error. Exiting the inferiors deletes the inferior's threads. scoped_restore_current_thread increments the current thread's refcount to prevent the thread from being deleted from under its feet. However, the code that does that isn't considering the case of the thread being deleted from within get_frame_id. It only increments the refcount _after_ get_frame_id returns. So if the current thread is indeed deleted, the tp->incref (); statement references a stale TP pointer. Incrementing the refcounts earlier fixes it. We should probably also let the TARGET_CLOSE_ERROR error propagate in this case. That alone would fix it, though it seems better to tweak the refcount handling too. And to avoid having to manually decref before throwing, convert to use gdb::ref_ptr. Unfortunately, we can't define inferior_ref in inferior.h and then use it in scoped_restore_current_thread, because scoped_restore_current_thread is defined before inferior is (inferior.h includes gdbthread.h). To break that dependency, we would have to move scoped_restore_current_thread to its own header. I'm not doing that here. gdb/ChangeLog: * gdbthread.h (inferior_ref): Define. (scoped_restore_current_thread) <m_thread>: Now a thread_info_ref. (scoped_restore_current_thread) <m_inf>: Now an inferior_ref. * thread.c (scoped_restore_current_thread::restore): Adjust to gdb::ref_ptr. (scoped_restore_current_thread::~scoped_restore_current_thread): Remove manual decref handling. (scoped_restore_current_thread::scoped_restore_current_thread): Adjust to use inferior_ref::new_reference/thread_info_ref::new_reference. Incref the thread before calling get_frame_id instead of after. Let TARGET_CLOSE_ERROR propagate.
2020-07-10Fix crash if connection drops in scoped_restore_current_thread's ctor, part 1Pedro Alves3-3/+36
Running the testsuite against an Asan-enabled build of GDB makes gdb.base/multi-target.exp expose this bug. scoped_restore_current_thread's ctor calls get_frame_id to record the selected frame's ID to restore later. If the frame ID hasn't been computed yet, it will be computed on the spot, and that will usually require accessing the target's memory and registers, which requires remote accesses. If the remote connection closes while we're computing the frame ID, the remote target exits its inferiors, unpushes itself, and throws a TARGET_CLOSE_ERROR error. If that happens, GDB can currently crash, here: > ==18555==ERROR: AddressSanitizer: heap-use-after-free on address 0x621004670aa8 at pc 0x0000007ab125 bp 0x7ffdecaecd20 sp 0x7ffdecaecd10 > READ of size 4 at 0x621004670aa8 thread T0 > #0 0x7ab124 in dwarf2_frame_this_id src/binutils-gdb/gdb/dwarf2/frame.c:1228 > #1 0x983ec5 in compute_frame_id src/binutils-gdb/gdb/frame.c:550 > #2 0x9841ee in get_frame_id(frame_info*) src/binutils-gdb/gdb/frame.c:582 > #3 0x1093faa in scoped_restore_current_thread::scoped_restore_current_thread() src/binutils-gdb/gdb/thread.c:1462 > #4 0xaee5ba in fetch_inferior_event(void*) src/binutils-gdb/gdb/infrun.c:3968 > #5 0xaa990b in inferior_event_handler(inferior_event_type, void*) src/binutils-gdb/gdb/inf-loop.c:43 > #6 0xea61b6 in remote_async_serial_handler src/binutils-gdb/gdb/remote.c:14161 > #7 0xefca8a in run_async_handler_and_reschedule src/binutils-gdb/gdb/ser-base.c:137 > #8 0xefcd23 in fd_event src/binutils-gdb/gdb/ser-base.c:188 > #9 0x15a7416 in handle_file_event src/binutils-gdb/gdbsupport/event-loop.cc:548 > #10 0x15a7c36 in gdb_wait_for_event src/binutils-gdb/gdbsupport/event-loop.cc:673 > #11 0x15a5dbb in gdb_do_one_event() src/binutils-gdb/gdbsupport/event-loop.cc:215 > #12 0xbfe62d in start_event_loop src/binutils-gdb/gdb/main.c:356 > #13 0xbfe935 in captured_command_loop src/binutils-gdb/gdb/main.c:416 > #14 0xc01d39 in captured_main src/binutils-gdb/gdb/main.c:1253 > #15 0xc01dc9 in gdb_main(captured_main_args*) src/binutils-gdb/gdb/main.c:1268 > #16 0x414ddd in main src/binutils-gdb/gdb/gdb.c:32 > #17 0x7f590110b82f in __libc_start_main ../csu/libc-start.c:291 > #18 0x414bd8 in _start (build/binutils-gdb/gdb/gdb+0x414bd8) What happens is that above, we're in dwarf2_frame_this_id, just after the dwarf2_frame_cache call. The "cache" variable that the dwarf2_frame_cache function returned is already stale. It's been released here, from within the dwarf2_frame_cache: (top-gdb) bt #0 reinit_frame_cache () at src/gdb/frame.c:1855 #1 0x00000000014ff7b0 in switch_to_no_thread () at src/gdb/thread.c:1301 #2 0x0000000000f66d3e in switch_to_inferior_no_thread (inf=0x615000338180) at src/gdb/inferior.c:626 #3 0x00000000012f3826 in remote_unpush_target (target=0x6170000c5900) at src/gdb/remote.c:5521 #4 0x00000000013097e0 in remote_target::readchar (this=0x6170000c5900, timeout=2) at src/gdb/remote.c:9137 #5 0x000000000130be4d in remote_target::getpkt_or_notif_sane_1 (this=0x6170000c5900, buf=0x6170000c5918, forever=0, expecting_notif=0, is_notif=0x0) at src/gdb/remote.c:9683 #6 0x000000000130c8ab in remote_target::getpkt_sane (this=0x6170000c5900, buf=0x6170000c5918, forever=0) at src/gdb/remote.c:9790 #7 0x000000000130bc0d in remote_target::getpkt (this=0x6170000c5900, buf=0x6170000c5918, forever=0) at src/gdb/remote.c:9623 #8 0x000000000130838e in remote_target::remote_read_bytes_1 (this=0x6170000c5900, memaddr=0x7fffffffcdc0, myaddr=0x6080000ad3bc "", len_units=64, unit_size=1, xfered_len_units=0x7fff6a29b9a0) at src/gdb/remote.c:8860 #9 0x0000000001308bd2 in remote_target::remote_read_bytes (this=0x6170000c5900, memaddr=0x7fffffffcdc0, myaddr=0x6080000ad3bc "", len=64, unit_size=1, xfered_len=0x7fff6a29b9a0) at src/gdb/remote.c:8987 #10 0x0000000001311ed1 in remote_target::xfer_partial (this=0x6170000c5900, object=TARGET_OBJECT_MEMORY, annex=0x0, readbuf=0x6080000ad3bc "", writebuf=0x0, offset=140737488342464, len=64, xfered_len=0x7fff6a29b9a0) at src/gdb/remote.c:10988 #11 0x00000000014ba969 in raw_memory_xfer_partial (ops=0x6170000c5900, readbuf=0x6080000ad3bc "", writebuf=0x0, memaddr=140737488342464, len=64, xfered_len=0x7fff6a29b9a0) at src/gdb/target.c:918 #12 0x00000000014bb720 in target_xfer_partial (ops=0x6170000c5900, object=TARGET_OBJECT_RAW_MEMORY, annex=0x0, readbuf=0x6080000ad3bc "", writebuf=0x0, offset=140737488342464, len=64, xfered_len=0x7fff6a29b9a0) at src/gdb/target.c:1148 #13 0x00000000014bc3b5 in target_read_partial (ops=0x6170000c5900, object=TARGET_OBJECT_RAW_MEMORY, annex=0x0, buf=0x6080000ad3bc "", offset=140737488342464, len=64, xfered_len=0x7fff6a29b9a0) at src/gdb/target.c:1380 #14 0x00000000014bc593 in target_read (ops=0x6170000c5900, object=TARGET_OBJECT_RAW_MEMORY, annex=0x0, buf=0x6080000ad3bc "", offset=140737488342464, len=64) at src/gdb/target.c:1419 #15 0x00000000014bbd4d in target_read_raw_memory (memaddr=0x7fffffffcdc0, myaddr=0x6080000ad3bc "", len=64) at src/gdb/target.c:1252 #16 0x0000000000bf27df in dcache_read_line (dcache=0x6060001eddc0, db=0x6080000ad3a0) at src/gdb/dcache.c:336 #17 0x0000000000bf2b72 in dcache_peek_byte (dcache=0x6060001eddc0, addr=0x7fffffffcdd8, ptr=0x6020001231b0 "") at src/gdb/dcache.c:403 #18 0x0000000000bf3103 in dcache_read_memory_partial (ops=0x6170000c5900, dcache=0x6060001eddc0, memaddr=0x7fffffffcdd8, myaddr=0x6020001231b0 "", len=8, xfered_len=0x7fff6a29bf20) at src/gdb/dcache.c:484 #19 0x00000000014bafe9 in memory_xfer_partial_1 (ops=0x6170000c5900, object=TARGET_OBJECT_STACK_MEMORY, readbuf=0x6020001231b0 "", writebuf=0x0, memaddr=140737488342488, len=8, xfered_len=0x7fff6a29bf20) at src/gdb/target.c:1034 #20 0x00000000014bb212 in memory_xfer_partial (ops=0x6170000c5900, object=TARGET_OBJECT_STACK_MEMORY, readbuf=0x6020001231b0 "", writebuf=0x0, memaddr=140737488342488, len=8, xfered_len=0x7fff6a29bf20) at src/gdb/target.c:1076 #21 0x00000000014bb6b3 in target_xfer_partial (ops=0x6170000c5900, object=TARGET_OBJECT_STACK_MEMORY, annex=0x0, readbuf=0x6020001231b0 "", writebuf=0x0, offset=140737488342488, len=8, xfered_len=0x7fff6a29bf20) at src/gdb/target.c:1133 #22 0x000000000164564d in read_value_memory (val=0x60f000029440, bit_offset=0, stack=1, memaddr=0x7fffffffcdd8, buffer=0x6020001231b0 "", length=8) at src/gdb/valops.c:956 #23 0x0000000001680fff in value_fetch_lazy_memory (val=0x60f000029440) at src/gdb/value.c:3764 #24 0x0000000001681efd in value_fetch_lazy (val=0x60f000029440) at src/gdb/value.c:3910 #25 0x0000000001676143 in value_optimized_out (value=0x60f000029440) at src/gdb/value.c:1411 #26 0x0000000000e0fcb8 in frame_register_unwind (next_frame=0x6210066bfde0, regnum=16, optimizedp=0x7fff6a29c200, unavailablep=0x7fff6a29c240, lvalp=0x7fff6a29c2c0, addrp=0x7fff6a29c300, realnump=0x7fff6a29c280, bufferp=0x7fff6a29c3a0 "@\304)j\377\177") at src/gdb/frame.c:1144 #27 0x0000000000e10418 in frame_unwind_register (next_frame=0x6210066bfde0, regnum=16, buf=0x7fff6a29c3a0 "@\304)j\377\177") at src/gdb/frame.c:1196 #28 0x0000000000f00431 in i386_unwind_pc (gdbarch=0x6210043d0110, next_frame=0x6210066bfde0) at src/gdb/i386-tdep.c:1969 #29 0x0000000000e39724 in gdbarch_unwind_pc (gdbarch=0x6210043d0110, next_frame=0x6210066bfde0) at src/gdb/gdbarch.c:3056 #30 0x0000000000c2ea90 in dwarf2_tailcall_sniffer_first (this_frame=0x6210066bfde0, tailcall_cachep=0x6210066bfee0, entry_cfa_sp_offsetp=0x0) at src/gdb/dwarf2/frame-tailcall.c:423 #31 0x0000000000c36bdb in dwarf2_frame_cache (this_frame=0x6210066bfde0, this_cache=0x6210066bfdf8) at src/gdb/dwarf2/frame.c:1198 #32 0x0000000000c36eb3 in dwarf2_frame_this_id (this_frame=0x6210066bfde0, this_cache=0x6210066bfdf8, this_id=0x6210066bfe40) at src/gdb/dwarf2/frame.c:1226 Note that remote_target::readchar in frame #4 throws TARGET_CLOSE_ERROR after the remote_unpush_target in frame #3 returns. The problem is that the TARGET_CLOSE_ERROR is swallowed by value_optimized_out in frame #25. If we fix that one, then we run into dwarf2_tailcall_sniffer_first swallowing the exception in frame #30 too. The attached patch fixes it by making those spots swallow fewer kinds of errors. gdb/ChangeLog: * frame-tailcall.c (dwarf2_tailcall_sniffer_first): Only swallow NO_ENTRY_VALUE_ERROR / MEMORY_ERROR / OPTIMIZED_OUT_ERROR / NOT_AVAILABLE_ERROR. * value.c (value_optimized_out): Only swallow MEMORY_ERROR / OPTIMIZED_OUT_ERROR / NOT_AVAILABLE_ERROR.
2020-07-10Fix GDB busy loop when interrupting non-stop program (PR 26199)Simon Marchi2-27/+20
When interrupting a program in non-stop, the program gets interrupted correctly, but GDB busy loops (the event loop is always woken up). Here is how to reproduce it: 1. Start GDB: ./gdb -nx --data-directory=data-directory -ex "set non-stop 1" --args /bin/sleep 60 2. Run the program with "run" 3. Interrupt with ^C. 4. Look into htop, see GDB taking 100% CPU Debugging `handle_file_event`, we see that the event source that wakes up the event loop is the linux-nat one: (top-gdb) p file_ptr.proc $5 = (handler_func *) 0xb9cccd <handle_target_event(int, gdb_client_data)> ^^^^^^^^^^^^^^^^^^^ | \-- the linux-nat callback Debugging fetch_inferior_event and do_target_wait, we see that we don't actually call `wait` on the linux-nat target, because inferior_matches returns false: auto inferior_matches = [&wait_ptid] (inferior *inf) { return (inf->process_target () != NULL && (threads_are_executing (inf->process_target ()) || threads_are_resumed_pending_p (inf)) && ptid_t (inf->pid).matches (wait_ptid)); }; because `threads_are_executing` is false. What happens is: 1. User types ctrl-c, that writes in the linux-nat pipe, waking up the event source. 2. linux-nat's wait gets called, the SIGINT event is returned, but before returning, it marks the pipe again, in order for wait to get called again: /* If we requested any event, and something came out, assume there may be more. If we requested a specific lwp or process, also assume there may be more. */ if (target_is_async_p () && ((ourstatus->kind != TARGET_WAITKIND_IGNORE && ourstatus->kind != TARGET_WAITKIND_NO_RESUMED) || ptid != minus_one_ptid)) async_file_mark (); 3. The SIGINT event is handled, the program is stopped, the stop notification is printed. 4. The event loop is woken up again because of the `async_file_mark` of step 2. 5. Because `inferior_matches` returns false, we never call linux-nat's wait, so the pipe stays readable. 6. Goto 4. Pedro says: This commit fixes it by letting do_target_wait call target_wait even if threads_are_executing is false. This will normally result in the target returning TARGET_WAITKIND_NO_RESUMED, and _not_ marking its event source again. This results in infrun only calling into the target only once (i.e., breaking the busy loop). Note that the busy loop bug didn't trigger in all-stop mode because all-stop handles this by unregistering the target from the event loop as soon as it was all stopped -- see inf-loop.c:inferior_event_handler's INF_EXEC_COMPLETE handling. If we remove that non-stop check from inferior_event_handler, and replace the target_has_execution check for threads_are_executing instead, it also fixes the issue for non-stop. I considered that as the final solution, but decided that the solution proposed here instead is just simpler and more future-proof design. With the TARGET_WAITKIND_NO_RESUMED handling fixes done in the previous patches, I think it should be possible to always keep the target registered in the event loop, meaning we could eliminate the target_async(0) call from inferior_event_handler as well as most of the target_async(1) calls in the target backends. That would allow in the future e.g., the remote target reporting asynchronous notifications even if all threads are stopped. I haven't attempted that, though. gdb/ChangeLog: yyyy-mm-dd Simon Marchi <simon.marchi@polymtl.ca> Pedro Alves <pedro@palves.net> PR gdb/26199 * infrun.c (threads_are_resumed_pending_p): Delete. (do_target_wait): Remove threads_are_executing and threads_are_resumed_pending_p checks from the inferior_matches lambda. Update comments.
2020-07-10Testcase for previous handle_no_resumed fixesPedro Alves3-1/+87
This adds a testcase that covers the scenarios described in the previous two commits. gdb/testsuite/ChangeLog: PR gdb/26199 * gdb.multi/multi-target.c (exit_thread): New. (thread_start): Break loop if EXIT_THREAD. * gdb.multi/multi-target.exp (test_no_unwaited_for): New proc. (top level) Call test_no_resumed.
2020-07-10Make handle_no_resumed transfer terminalPedro Alves2-12/+60
Let's consider the same use case as in the previous commit: Say you have two inferiors 1 and 2, each connected to a different target, A and B. Now say you set inferior 2 running, with "continue &". Now you select a thread of inferior 1, say thread 1.2, and continue in the foreground. All other threads of inferior 1 are left stopped. Thread 1.2 exits, and thus target A has no other resumed thread, so it reports TARGET_WAITKIND_NO_RESUMED. At this point, because the threads of inferior 2 are still executing the TARGET_WAITKIND_NO_RESUMED event is ignored. Now, the user types Ctrl-C. Because GDB had previously put inferior 1 in the foreground, the kernel sends the SIGINT to that inferior. However, no thread in that inferior is executing right now, so ptrace never intercepts the SIGINT -- it is never dequeued by any thread. The result is that GDB's CLI is stuck. There's no way to get back the prompt (unless inferior 2 happens to report some event). The fix in this commit is to make handle_no_resumed give the terminal to some other inferior that still has threads executing so that a subsequent Ctrl-C reaches that target first (and then GDB intercepts the SIGINT). This is a bit hacky, but seems like the best we can do with the current design. I think that putting all native inferiors in their own session would help fixing this in a clean way, since with that a Ctrl-C on GDB's terminal will _always_ reach GDB first, and then GDB can decide how to pause the inferior. But that's a much larger change. The testcase added by the following patch needs this fix. gdb/ChangeLog: PR gdb/26199 * infrun.c (handle_no_resumed): Transfer terminal to inferior with executing threads.
2020-07-10Fix handle_no_resumed w/ multiple targetsPedro Alves2-5/+22
handle_no_resumed is currently not considering multiple targets. Say you have two inferiors 1 and 2, each connected to a different target, A and B. Now say you set inferior 2 running, with "continue &". Now you select a thread of inferior 1, say thread 1.2, and continue in the foreground. All other threads of inferior 1 are left stopped. Thread 1.2 exits, and thus target A has no other resumed thread, so it reports TARGET_WAITKIND_NO_RESUMED. At this point, if both inferiors were running in the same target, handle_no_resumed would realize that threads of inferior 2 are still executing, so the TARGET_WAITKIND_NO_RESUMED event should be ignored. But because handle_no_resumed only walks the threads of the current target, it misses noticing that threads of inferior 2 are still executing. The fix is just to walk over all threads of all targets. A testcase covering the use case above will be added in a following patch. It can't be added yet because it depends on yet another fix to handle_no_resumed not included here. gdb/ChangeLog: PR gdb/26199 * infrun.c (handle_no_resumed): Handle multiple targets.
2020-07-10Avoid constant stream of TARGET_WAITKIND_NO_RESUMEDPedro Alves2-1/+11
If we hit the synchronous execution command case described by handle_no_resumed, and handle_no_resumed determines that the event should be ignored, because it found a thread that is executing, we end up in prepare_to_wait. There, if the current target is not registered in the event loop right now, we call mark_infrun_async_event_handler. With that event handler marked, the event loop calls again into fetch_inferior_event, which calls target_wait, which returns TARGET_WAITKIND_NO_RESUMED, and we end up in handle_no_resumed, again ignoring the event and marking infrun_async_event_handler. The result is that GDB is now always keeping the CPU 100% busy in this loop, even though it continues to be able to react to input and to real target events, because we still go through the event-loop. The problem is that marking of the infrun_async_event_handler in prepare_to_wait. That is there to handle targets that don't support asynchronous execution. So the correct predicate is whether async execution is supported, not whether the target is async right now. gdb/ChangeLog: PR gdb/26199 * infrun.c (prepare_to_wait): Check target_can_async_p instead of target_is_async_p.
2020-07-10Fix latent bug in target_pass_ctrlcPedro Alves2-1/+7
We were checking the thr->executing of an exited thread. gdb/ChangeLog: PR gdb/26199 * target.c (target_pass_ctrlc): Look at the inferior's non-exited threads, not all threads.
2020-07-10Fix spurious unhandled remote %Stop notificationsPedro Alves2-1/+23
In non-stop mode, remote targets mark an async event source whose callback is supposed to result in calling remote_target::wait_ns to either process the event queue, or acknowledge an incoming %Stop notification. The callback in question is remote_async_inferior_event_handler, where we call inferior_event_handler, to end up in fetch_inferior_event -> target_wait -> remote_target::wait -> remote_target::wait_ns. A problem here however is that when debugging multiple targets, fetch_inferior_event can pull events out of any target picked at random, for event fairness. This means that when remote_async_inferior_event_handler returns, remote_target::wait may have not been called at all, and thus pending notifications may have not been acked. Because async event sources auto-clear, when remote_async_inferior_event_handler returns the async event handler is no longer marked, so the event loop won't automatically call remote_async_inferior_event_handler again to try to process the pending remote notifications/queue. The result is that stop events may end up not processed, e.g., "interrupt -a" seemingly not managing to stop all threads. Fix this by making remote_async_inferior_event_handler mark the event handler again before returning, if necessary. Maybe a better fix would be to make async event handlers not auto-clear themselves, make that the responsibility of the callback, so that the event loop would keep calling the callback automatically. Or, we could try making so that fetch_inferior_event would optionally handle events only for the target that it got passed down via parameter. However, I don't think now just before branching is the time to try to do any such change. gdb/ChangeLog: PR gdb/26199 * remote.c (remote_target::open_1): Pass remote target pointer as data to create_async_event_handler. (remote_async_inferior_event_handler): Mark async event handler before returning if the remote target still has either pending events or unacknowledged notifications.
2020-07-10Enable multi-process mode in the FreeBSD native target.John Baldwin3-0/+15
gdb/ChangeLog: * fbsd-nat.h (fbsd_nat_target::supports_multi_process): New declaration. * fbsd-nat.c (fbsd_nat_target::supports_multi_process): New function.
2020-07-09Don't compare the pid returned from 'wait' against inferior_ptid.John Baldwin2-1/+6
'inf_ptrace::wait' needs to discard termination events reported by detached child processes. Previously it compared the returned pid against the pid in inferior_ptid to determine if a termination event should be discarded or reported. The multi-target changes cleared inferior_ptid to null_ptid in 'wait' target methods, so this was always failing and never reporting exit events. Instead, report termination events whose pid matches any inferior belonging to the current target. Several tests started failing on FreeBSD after the multi-target changes and pass again after this change. gdb/ChangeLog: * inf-ptrace.c (inf_ptrace_target::wait): Don't compare against inferior_ptid.
2020-07-09Support several new ELF auxiliary vector types on FreeBSD.John Baldwin2-0/+11
FreeBSD's kernel recently added several ELF auxiliary vector entries to describe the arguments passed to new executable images during exec(). The AT_FREEBSD_ARGC and AT_FREEBSD_ARGV entries give the length and address of the process argument array. AT_FREEBSD_ENVC and AT_FREEBSD_ENVV entries give the length and address of the initial process environment. AT_FREEBSD_PS_STRINGS gives the address of the 'struct ps_strings' object. include/ChangeLog: * elf/common.h (AT_FREEBSD_ARGC, AT_FREEBSD_ARGV, AT_FREEBSD_ENVC) (AT_FREEBSD_ENVV, AT_FREEBSD_PS_STRINGS): Define. gdb/ChangeLog: * fbsd-tdep.c (fbsd_print_auxv_entry): Handle AT_FREEBSD_ARGC, AT_FREEBSD_ARGV, AT_FREEBSD_ENVC, AT_FREEBSD_ENVV, AT_FREEBSD_PS_STRINGS.
2020-07-08Handle Windows drives in auto-load script pathsHannes Domani4-0/+21
Fixes this testsuite fail on Windows: FAIL: gdb.base/auto-load.exp: print $script_loaded Converts the debugfile path from c:/dir/file to /c/dir/file, so it can be appended to the auto-load path. gdb/ChangeLog: 2020-07-08 Hannes Domani <ssbssa@yahoo.de> * auto-load.c (auto_load_objfile_script_1): Convert drive part of debugfile path on Windows. gdb/doc/ChangeLog: 2020-07-08 Hannes Domani <ssbssa@yahoo.de> * gdb.texinfo: Document Windows drive conversion of 'set auto-load scripts-directory'.
2020-07-08Rename the 'obfd' argument to fbsd_nat_target::find_memory_regions.John Baldwin2-6/+11
The argument is passed as a generic cookie value to the supplied callback and is not necessarily a pointer to a bfd. gdb/ChangeLog: * fbsd-nat.c (fbsd_nat_target::find_memory_regions): Rename 'obfd' argument to 'data'.
2020-07-08Use read_memory in ada_exception_message_1Tom Tromey5-3/+17
Testing using the internal AdaCore test suite showed a regression from the target string reading changes. In particular, now ada_exception_message_1 can get the wrong answer in some cases. In particular, when an Ada exception catchpoint is hit, sometimes the exception name will be incorrect. The case I was seeing changed from the correct: Catchpoint 2, CONSTRAINT_ERROR (catch C_E) at [...] to: Catchpoint 2, CONSTRAINT_ERROR (catch C_EE) at [...] I was not able to reproduce this failure with the Fedora gnat. Perhaps it is related to some local change to gnat; I do not know. Meanwhile, because ada_exception_message_1 knows the length of the string to read, we can use read_memory here. This fixes the bug. I've updated the test suite to at least exercise this code path. However, as mentioned above, the new test does not actually provoke the failure. gdb/ChangeLog 2020-07-08 Tom Tromey <tromey@adacore.com> * ada-lang.c (ada_exception_message_1): Use read_memory. gdb/testsuite/ChangeLog 2020-07-08 Tom Tromey <tromey@adacore.com> * gdb.ada/catch_ex/foo.adb: Pass string to raise. * gdb.ada/catch_ex.exp: Examine catchpoint text.
2020-07-06gdb: Python unwinders, inline frames, and tail-call framesAndrew Burgess9-48/+185
This started with me running into the bug described in python/22748, in summary, if the frame sniffing code accessed any registers within an inline frame then GDB would crash with this error: gdb/frame.c:579: internal-error: frame_id get_frame_id(frame_info*): Assertion `fi->level == 0' failed. The problem is that, when in the Python unwinder I write this: pending_frame.read_register ("register-name") This is translated internally into a call to `value_of_register', which in turn becomes a call to `value_of_register_lazy'. Usually this isn't a problem, `value_of_register_lazy' requires the next frame (more inner) to have a valid frame_id, which will be the case (if we're sniffing frame #1, then frame #0 will have had its frame-id figured out). Unfortunately if frame #0 is inline within frame #1, then the frame-id for frame #0 can't be computed until we have the frame-id for #1. As a result we can't create a lazy register for frame #1 when frame #0 is inline. Initially I proposed a solution inline with that proposed in bugzilla, changing value_of_register to avoid creating a lazy register value. However, when this was discussed on the mailing list I got this reply: https://sourceware.org/pipermail/gdb-patches/2020-June/169633.html Which led me to look at these two patches: [1] https://sourceware.org/pipermail/gdb-patches/2020-April/167612.html [2] https://sourceware.org/pipermail/gdb-patches/2020-April/167930.html When I considered patches [1] and [2] I saw that all of the issues being addressed here were related, and that there was a single solution that could address all of these issues. First I wrote the new test gdb.opt/inline-frame-tailcall.exp, which shows that [1] and [2] regress the inline tail-call unwinder, the reason for this is that these two patches replace a call to gdbarch_unwind_pc with a call to get_frame_register, however, this is not correct. The previous call to gdbarch_unwind_pc takes THIS_FRAME and returns the $pc value in the previous frame. In contrast get_frame_register takes THIS_FRAME and returns the value of the $pc in THIS_FRAME; these calls are not equivalent. The reason these patches appear (or do) fix the regressions listed in [1] is that the tail call sniffer depends on identifying the address of a caller and a callee, GDB then looks for a tail-call sequence that takes us from the caller address to the callee, if such a series is found then tail-call frames are added. The bug that was being hit, and which was address in patch [1] is that in order to find the address of the caller, GDB ended up creating a lazy register value for an inline frame with to frame-id. The solution in patch [1] is to instead take the address of the callee and treat this as the address of the caller. Getting the address of the callee works, but we then end up looking for a tail-call series from the callee to the callee, which obviously doesn't return any sane results, so we don't insert any tail call frames. The original patch [1] did cause some breakage, so patch [2] undid patch [1] in all cases except those where we had an inline frame with no frame-id. It just so happens that there were no tests that fitted this description _and_ which required tail-call frames to be successfully spotted, as a result patch [2] appeared to work. The new test inline-frame-tailcall.exp, exposes the flaw in patch [2]. This commit undoes patch [1] and [2], and replaces them with a new solution, which is also different to the solution proposed in the python/22748 bug report. In this solution I propose that we introduce some special case logic to value_of_register_lazy. To understand what this logic is we must first look at how inline frames unwind registers, this is very simple, they do this: static struct value * inline_frame_prev_register (struct frame_info *this_frame, void **this_cache, int regnum) { return get_frame_register_value (this_frame, regnum); } And remember: struct value * get_frame_register_value (struct frame_info *frame, int regnum) { return frame_unwind_register_value (frame->next, regnum); } So in all cases, unwinding a register in an inline frame just asks the next frame to unwind the register, this makes sense, as an inline frame doesn't really exist, when we unwind a register in an inline frame, we're really just asking the next frame for the value of the register in the previous, non-inline frame. So, if we assume that we only get into the missing frame-id situation when we try to unwind a register from an inline frame during the frame sniffing process, then we can change value_of_register_lazy to not create lazy register values for an inline frame. Imagine this stack setup, where #1 is inline within #2. #3 -> #2 -> #1 -> #0 \______/ inline Now when trying to figure out the frame-id for #1, we need to compute the frame-id for #2. If the frame sniffer for #2 causes a lazy register read in #2, either due to a Python Unwinder, or for the tail-call sniffer, then we call value_of_register_lazy passing in frame #2. In value_of_register_lazy, we grab the next frame, which is #1, and we used to then ask for the frame-id of #1, which was not computed, and this was our bug. Now, I propose we spot that #1 is an inline frame, and so lookup the next frame of #1, which is #0. As #0 is not inline it will have a valid frame-id, and so we create a lazy register value using #0 as the next-frame-id. This will give us the exact same result we had previously (thanks to the code we inspected above). Encoding into value_of_register_lazy the knowledge that reading an inline frame register will always just forward to the next frame feels.... not ideal, but this seems like the cleanest solution to this recursive frame-id computation/sniffing issue that appears to crop up. The following two commits are fully reverted with this commit, these correspond to patches [1] and [2] respectively: commit 5939967b355ba6a940887d19847b7893a4506067 Date: Tue Apr 14 17:26:22 2020 -0300 Fix inline frame unwinding breakage commit 991a3e2e9944a4b3a27bd989ac03c18285bd545d Date: Sat Apr 25 00:32:44 2020 -0300 Fix remaining inline/tailcall unwinding breakage for x86_64 gdb/ChangeLog: PR python/22748 * dwarf2/frame-tailcall.c (dwarf2_tailcall_sniffer_first): Remove special handling for inline frames. * findvar.c (value_of_register_lazy): Skip inline frames when creating lazy register values. * frame.c (frame_id_computed_p): Delete definition. * frame.h (frame_id_computed_p): Delete declaration. gdb/testsuite/ChangeLog: PR python/22748 * gdb.opt/inline-frame-tailcall.c: New file. * gdb.opt/inline-frame-tailcall.exp: New file. * gdb.python/py-unwind-inline.c: New file. * gdb.python/py-unwind-inline.exp: New file. * gdb.python/py-unwind-inline.py: New file.
2020-07-06gdb/python: New method to access list of register groupsAndrew Burgess10-0/+371
Add a new method gdb.Architecture.register_groups which returns a new object of type gdb.RegisterGroupsIterator. This new iterator then returns objects of type gdb.RegisterGroup. Each gdb.RegisterGroup object just wraps a single reggroup pointer, and (currently) has just one read-only property 'name' that is a string, the name of the register group. As with the previous commit (adding gdb.RegisterDescriptor) I made gdb.RegisterGroup an object rather than just a string in case we want to add additional properties in the future. gdb/ChangeLog: * NEWS: Mention additions to Python API. * python/py-arch.c (archpy_register_groups): New function. (arch_object_methods): Add 'register_groups' method. * python/py-registers.c (reggroup_iterator_object): New struct. (reggroup_object): New struct. (gdbpy_new_reggroup): New function. (gdbpy_reggroup_to_string): New function. (gdbpy_reggroup_name): New function. (gdbpy_reggroup_iter): New function. (gdbpy_reggroup_iter_next): New function. (gdbpy_new_reggroup_iterator): New function (gdbpy_initialize_registers): Register new types. (reggroup_iterator_object_type): Define new Python type. (gdbpy_reggroup_getset): New static global. (reggroup_object_type): Define new Python type. * python/python-internal.h gdb/testsuite/ChangeLog: * gdb.python/py-arch-reg-groups.exp: New file. gdb/doc/ChangeLog: * gdb.texi (Registers): Add @anchor for 'info registers <reggroup>' command. * python.texi (Architectures In Python): Document new register_groups method. (Registers In Python): Document two new object types related to register groups.
2020-07-06gdb/python: Add gdb.Architecture.registers methodAndrew Burgess11-0/+452
This commit adds a new method gdb.Architecture.registers that returns an object of the new type gdb.RegisterDescriptorIterator. This iterator returns objects of the new type gdb.RegisterDescriptor. A RegisterDescriptor is not a way to read the value of a register, this is already covered by Frame.read_register, a RegisterDescriptor is simply a way to discover from Python, which registers are available for a given architecture. I did consider just returning a string, the name of each register, instead of a RegisterDescriptor, however, I'm aware that it we don't want to break the existing Python API in any way, so if I return just a string now, but in the future we want more information about a register then we would have to add a second API to get that information. By going straight to a descriptor object now, it is easy to add additional properties in the future should we wish to. Right now the only property of a register that a user can access is the name of the register. In future we might want to be able to ask the register about is register groups, or its type. gdb/ChangeLog: * Makefile.in (SUBDIR_PYTHON_SRCS): Add py-registers.c * python/py-arch.c (archpy_registers): New function. (arch_object_methods): Add 'registers' method. * python/py-registers.c: New file. * python/python-internal.h (gdbpy_new_register_descriptor_iterator): Declare. (gdbpy_initialize_registers): Declare. * python/python.c (do_start_initialization): Call gdbpy_initialize_registers. * NEWS: Mention additions to the Python API. gdb/testsuite/ChangeLog: * gdb.python/py-arch-reg-names.exp: New file. gdb/doc/ChangeLog: * python.texi (Python API): Add new section the menu. (Frames In Python): Add new @anchor. (Architectures In Python): Document new registers method. (Registers In Python): New section.
2020-07-06gdb/python: Add architecture method to gdb.PendingFrameAndrew Burgess7-1/+54
It could be useful to determine the architecture of a frame being unwound during the frame unwind process, that is, before we have a gdb.Frame, but when we only have a gdb.PendingFrame. The PendingFrame already has a pointer to the gdbarch internally, this commit just exposes an 'architecture' method to Python, and has this return a gdb.Architecture object (list gdb.Frame.architecture does). gdb/ChangeLog: * NEWS: Mention new Python API method. * python/py-unwind.c (pending_framepy_architecture): New function. (pending_frame_object_methods): Add architecture method. gdb/testsuite/ChangeLog: * gdb.python/py-unwind.py (TestUnwinder::__call__): Add test for gdb.PendingFrame.architecture method. gdb/doc/ChangeLog: * python.texi (Unwinding Frames in Python): Document PendingFrame.architecture method.
2020-07-06gdb: Remove deprecated_set_gdbarch_dataAndrew Burgess6-68/+33
There are currently two remaining uses of deprecated_set_gdbarch_data, both of which are needed because during gdbarch initialisation we call gdbarch_data for a data field that is registered using: gdbarch_data_register_post_init (....) However, in both of these cases, the only thing that the call back needs from the gdbarch struct is its obstack. Given this there is nothing stopping us changing the post-init hooks into pre-init hooks. The pre-init hooks don't get passed the full gdbarch, they only get passed its obstack. The IA64 change is completely untested. The user-regs change has been tested a little by locally adding some user-regs to the x86-64 target, and also by running the RISC-V tests, which do use user-regs. gdb/ChangeLog: * gdbarch.c: Regenerate. * gdbarch.h: Regenerate. * gdbarch.sh (deprecated_set_gdbarch_data): Delete. (gdbarch_data): Use internal_error for the case where deprecated_set_gdbarch_data was originally needed. * ia64-libunwind-tdep.c (libunwind_descr_init): Update parameters, and use passed in obstack. (libunwind_frame_set_descr): Should no longer get back NULL from gdbarch_data. (_initialize_libunwind_frame): Register as a pre-init gdbarch data type. * user-regs.c (user_regs_init): Update parameters, and use passed in obstack. (user_reg_add): Should no longer get back NULL from gdbarch_data. (_initialize_user_regs): Register as a pre-init gdbarch data type.
2020-07-06[gdb/symtab] Fix line-table end-of-sequence sortingTom de Vries5-6/+30
Consider test-case gdb.dwarf2/dw2-ranges-base.exp. It has (ignoring non-sensical entries that are filtered out by buildsym_compunit::record_line) a line-table for dw2-ranges-base.c like this: ... Line Number Statements: [0x0000014e] Extended opcode 2: set Address to 0x4004ba [0x00000159] Advance Line by 10 to 11 [0x0000015b] Copy [0x0000015c] Advance PC by 12 to 0x4004c6 [0x0000015e] Extended opcode 1: End of Sequence [0x00000161] Extended opcode 2: set Address to 0x4004ae [0x0000016c] Advance Line by 20 to 21 [0x0000016e] Copy [0x0000016f] Advance PC by 12 to 0x4004ba [0x00000171] Extended opcode 1: End of Sequence [0x00000174] Extended opcode 2: set Address to 0x4004a7 [0x0000017f] Advance Line by 30 to 31 [0x00000181] Copy [0x00000182] Advance PC by 7 to 0x4004ae [0x00000184] Extended opcode 1: End of Sequence ... If we disable the sorting in buildsym_compunit::end_symtab_with_blockvector, we have the unsorted line table: ... INDEX LINE ADDRESS IS-STMT 0 11 0x00000000004004ba Y 1 END 0x00000000004004c6 Y 2 21 0x00000000004004ae Y 3 END 0x00000000004004ba Y 4 31 0x00000000004004a7 Y 5 END 0x00000000004004ae Y ... It contains 3 sequences, 11/END, 21/END and 31/END. We want to sort the 3 sequences relative to each other, while sorting on address, to get: ... INDEX LINE ADDRESS IS-STMT 0 31 0x00000000004004a7 Y 1 END 0x00000000004004ae Y 2 21 0x00000000004004ae Y 3 END 0x00000000004004ba Y 4 11 0x00000000004004ba Y 5 END 0x00000000004004c6 Y ... However, if we re-enable the sorting, we have instead: ... INDEX LINE ADDRESS IS-STMT 0 31 0x00000000004004a7 Y 1 21 0x00000000004004ae Y 2 END 0x00000000004004ae Y 3 11 0x00000000004004ba Y 4 END 0x00000000004004ba Y 5 END 0x00000000004004c6 Y ... This is a regression since commit 3d92a3e313 "gdb: Don't reorder line table entries too much when sorting", that introduced sorting on address while keeping entries with the same address in pre-sort order. Indeed the entries 1 and 2 are in pre-sort order (they map to entries 2 and 5 in the unsorted line table), but entry 1 does not belong in the sequence terminated by 2. Fix this by handling End-Of-Sequence entries in the sorting function, such that they are sorted before other entries with the same address. Also, revert the find_pc_sect_line workaround introduced in commit 3d92a3e313, since that's no longer necessary. Tested on x86_64-linux. gdb/ChangeLog: 2020-07-06 Tom de Vries <tdevries@suse.de> * buildsym.c (buildsym_compunit::end_symtab_with_blockvector): Handle End-Of-Sequence in lte_is_less_than. * symtab.c (find_pc_sect_line): Revert change from commit 3d92a3e313 "gdb: Don't reorder line table entries too much when sorting". gdb/testsuite/ChangeLog: 2020-07-06 Tom de Vries <tdevries@suse.de> * gdb.dwarf2/dw2-ranges-base.exp: Test line-table order.
2020-07-06[gdb/tui,c++17] Fix NULL string_view in tui_partial_win_by_nameTom de Vries2-13/+15
When building gdb with CFLAGS=-std=gnu17 and CXXFLAGS=-std=gnu++17 and running test-case gdb.tui/new-layout.exp, we run into: ... UNRESOLVED: gdb.tui/new-layout.exp: left window box after shrink (ll corner) FAIL: gdb.tui/new-layout.exp: right window box after shrink (ll corner) ... In a minimal form, we run into an abort when issuing a winheight command: ... $ gdb -tui -ex "winheight src - 5" <tui stuff> Aborted (core dumped) $ ... with this backtrace at the abort: ... \#0 0x0000000000438db0 in std::char_traits<char>::length (__s=0x0) at /usr/include/c++/9/bits/char_traits.h:335 \#1 0x000000000043b72e in std::basic_string_view<char, \ std::char_traits<char> >::basic_string_view (this=0x7fffffffd4f0, \ __str=0x0) at /usr/include/c++/9/string_view:124 \#2 0x000000000094971b in tui_partial_win_by_name (name="src") at src/gdb/tui/tui-win.c:663 ... due to a NULL comparison which constructs a string_view object from NULL: ... 657 /* Answer the window represented by name. */ 658 static struct tui_win_info * 659 tui_partial_win_by_name (gdb::string_view name) 660 { 661 struct tui_win_info *best = nullptr; 662 663 if (name != NULL) ... In gdbsupport/gdb_string_view.h, we either use: - gdb's copy of libstdc++-v3/include/experimental/string_view, or - the standard implementation of string_view, when built with C++17 or later (which in gcc's case comes from libstdc++-v3/include/std/string_view) In the first case, there's support for constructing a string_view from a NULL pointer: ... /*constexpr*/ basic_string_view(const _CharT* __str) : _M_len{__str == nullptr ? 0 : traits_type::length(__str)}, _M_str{__str} { } ... but in the second case, there's not: ... __attribute__((__nonnull__)) constexpr basic_string_view(const _CharT* __str) noexcept : _M_len{traits_type::length(__str)}, _M_str{__str} { } ... Fix this by removing the NULL comparison altogether. Build on x86_64-linux with CFLAGS=-std=gnu17 and CXXFLAGS=-std=gnu++17, and tested. gdb/ChangeLog: 2020-07-06 Tom de Vries <tdevries@suse.de> PR tui/26205 * tui/tui-win.c (tui_partial_win_by_name): Don't test for NULL name.
2020-07-05[gdb/build,c++17] Fix use of deprecated std::uncaught_exceptionTom de Vries2-1/+16
When compiling gdb with -std=gnu++17, we run into: ... ../../gdb/inferior.h: In member function ‘void \ infcall_suspend_state_deleter::operator()(infcall_suspend_state*) const’: ../../gdb/inferior.h:83:12: error: ‘bool std::uncaught_exception()’ is \ deprecated [-Werror=deprecated-declarations] 83 | if (!std::uncaught_exception ()) ... Fix this by rewriting using std::uncaught_exceptions. Tested on x86_64-linux with gcc 9.3.1 and -std=gnu17/gnu++17. Tested with test-case from RFC patch https://sourceware.org/pipermail/gdb-patches/2020-June/169970.html. gdb/ChangeLog: 2020-07-05 Tom de Vries <tdevries@suse.de> PR build/26187 * inferior.h (struct infcall_suspend_state_deleter): If available, use std::uncaught_exceptions instead of deprecated std::uncaught_exception.
2020-07-03gdb: make macro_stringify return a gdb::unique_xmalloc_ptr<char>Simon Marchi4-16/+15
The change to macro_stringify is straightforward. This allows removing the manual memory management in fixup_definition. gdb/ChangeLog: * macroexp.h (macro_stringify): Return gdb::unique_xmalloc_ptr<char>. * macroexp.c (macro_stringify): Likewise. * macrotab.c (fixup_definition): Update. Change-Id: Id7db8988bdbd569dd51c4f4655b00eb26db277cb
2020-07-03gdb: make macro_expand_next return a gdb::unique_xmalloc_ptr<char>Simon Marchi4-22/+28
For some reason, macro_expand_next does not return a gdb::unique_xmalloc_ptr<char>, like its counterparts macro_expand and macro_expand_once. This patch fixes that. macro_buffer::release now returns a gdb::unique_xmalloc_ptr<char> too, which required updating the other callers. The `.release (). release ()` in macro_stringify looks a bit funny, but it's because one release is for the macro_buffer, and the other is for the unique ptr. I removed the ATTRIBUTE_UNUSED_RESULT on macro_buffer::release, I don't really understand why it's there. I don't see how this method could be called without using the result, that would be an obvious memory leak. The commit that introduced it (4e4a8b932b7 "Add ATTRIBUTE_UNUSED_RESULT to macro_buffer") doesn't give any details. gdb/ChangeLog: * c-exp.y (scan_macro_expansion): Don't free `expansion`. (lex_one_token): Update. * macroexp.c (struct macro_buffer) <release>: Return gdb::unique_xmalloc_ptr<char>. (macro_stringify): Update. (macro_expand): Update. (macro_expand_next): Return gdb::unique_xmalloc_ptr<char>. * macroexp.h (macro_expand_next): Likewise. Change-Id: I67a74d0d479d2c20cdc82161ead7c54cea034f56
2020-07-03gdb: remove callback in macro expand functionsSimon Marchi7-91/+72
I started to look into changing the callbacks in macroexp.h to use gdb::function_view. However, I noticed that the passed lookup function was always `standard_macro_lookup`, which looks up a macro in a `macro_scope` object. Since that doesn't look like a very useful abstraction, it would be simpler to just pass the scope around and have the various functions call standard_macro_lookup themselves. This is what this patch does. gdb/ChangeLog: * macroexp.h (macro_lookup_ftype): Remove. (macro_expand, macro_expand_once, macro_expand_next): Remove lookup function parameters, add scope parameter. * macroexp.c (scan, substitute_args, expand, maybe_expand, macro_expand, macro_expand_once, macro_expand_next): Likewise. * macroscope.h (standard_macro_lookup): Change parameter type to macro_scope. * macroscope.c (standard_macro_lookup): Likewise. * c-exp.y (lex_one_token): Update. * macrocmd.c (macro_expand_command): Likewise. (macro_expand_once_command): Likewise. Change-Id: Id2431b1489359e1b0274dc2b81e5ea5d225d730c
2020-07-03Fix gdb.base/structs2.exp with ClangPedro Alves3-2/+8
gdb.base/structs2.exp fails to run with Clang, because of: gdb compile failed, /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/structs2.c:16:14: warning: implicit conversion from 'int' to 'signed char' changes value from 130 to -126 [-Wconstant-conversion] param_reg (130, 120, 33000, 32000); ~~~~~~~~~ ^~~ /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/structs2.c:16:24: warning: implicit conversion from 'int' to 'short' changes value from 33000 to -32536 [-Wconstant-conversion] param_reg (130, 120, 33000, 32000); ~~~~~~~~~ ^~~~~ 2 warnings generated. === gdb Summary === # of untested testcases 1 Fix it by passing actual negative numbers. gdb/testsuite/ChangeLog: * gdb.base/structs2.c (main): Adjust second parem_reg call to explicitly write negative numbers. * gdb.base/structs2.exp: Adjust expected output.
2020-07-03Fix gdb.base/charset.exp with ClangPedro Alves2-4/+18
gdb.base/charset.exp fails to run with Clang, because of: gdb compile failed, /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/charset.c:144:20: warning: implicit conversion from 'int' to 'char' changes value from 162 to -94 [-Wconstant-conversion] 11, 162, 17); ^~~ /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/charset.c:151:16: warning: implicit conversion from 'int' to 'char' changes value from 167 to -89 [-Wconstant-conversion] 167, ^~~ /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/charset.c:168:16: warning: implicit conversion from 'int' to 'char' changes value from 167 to -89 [-Wconstant-conversion] 167, ^~~ 3 warnings generated. === gdb Summary === # of untested testcases 1 Fix it by changing init_string to take unsigned char parameters. gdb/testsuite/ChangeLog: * gdb.base/charset.c (init_string): Change all char parameters to unsigned char parameters.
2020-07-03Remove stale -DNO_PROTOTYPES bits from gdb testsuitePedro Alves8-67/+27
The gdb.base/call-sc.exp, gdb.base/structs.exp and gdb.base/structs2.exp testcases still try compiling the sources with -DNO_PROTOTYPES, but the corresponding sources don't have any #ifdef NO_PROTOTYPES any longer. Those were removed throughout years ago. OTOH, gdb.base/ovlymgr.h does check for NO_PROTOTYPES, but no .exp file compiles it with -DNO_PROTOTYPES. gdb.base/reread.exp and gdb.base/varargs.exp set a 'prototypes' global, which is a stale bit left behind when the "try-compiling without and then with -DNO_PROTOTYPES" logic was around. gdb/testsuite/ChangeLog: * gdb.base/call-sc.exp (start_scalars_test): Use prepare_for_testing and don't try compiling with -DNO_PROTOTYPES. * gdb.base/overlays.c: Remove references to PARAMS. * gdb.base/ovlymgr.h (PARAMS): Delete, and remove all references. * gdb.base/reread.exp: Don't set 'prototypes' global. * gdb.base/structs.exp (start_structs_test): Use prepare_for_testing and don't try compiling with -DNO_PROTOTYPES. * gdb.base/structs2.exp: Don't set 'prototypes' global. Use prepare_for_testing and don't try compiling with -DNO_PROTOTYPES. Don't issue "set width 0". Remove gdb_stop_suppressing_tests call. * gdb.base/varargs.exp: Don't set 'prototypes' global.
2020-07-03Remove stale overlay testcase bitsPedro Alves4-583/+5
D10V support was removed years ago, but the gdb.base/d10vovly.c file stayed behind. Looking a bit closer, I can't find anywhere that references gdb.base/m32rovly.c either. Both gdb.base/m32rovly.c and gdb.base/d10vovly.c seem to be older copies of gdb.base/ovlymgr.c, that are exactly the same, except for some cosmetic differences, and for missing _ovly_debug_event. Note that gdb.base/ovlymgr.c has the #ifdef __M32R__ bits too. Note also that gdb.base/overlays.exp is currently only supported on m32r, and that uses ovlymgr.c not gdb.base/m32rovly.c. gdb/testsuite/ChangeLog: * gdb.base/d10vovly.c: Delete. * gdb.base/m32rovly.c: Delete. * gdb.base/ovlymgr.c: Remove all code guarded by __D10V__.
2020-07-02gdb: remove unused fetch_inferior_event and inferior_event_handler parametersSimon Marchi10-18/+31
I noticed that fetch_inferior_event receives the client_data parameter from its caller, inferior_event_handler, but doesn't actually need it. This patch removes it. In turn, inferior_event_handler doesn't use its parameter, so remove it too. The `data` argument used when registering remote_async_inferior_event_handler is changed to NULL, to avoid confusion. It could make people think that the value passed is used somewhere, when in fact it's not. gdb/ChangeLog: * inf-loop.c (inferior_event_handler): Remove client_data param. * inf-loop.h (inferior_event_handler): Likewise. * infcmd.c (step_1): Adjust. * infrun.c (proceed): Adjust. (fetch_inferior_event): Remove client_data param. (infrun_async_inferior_event_handler): Adjust. * infrun.h (fetch_inferior_event): Remove `void *` param. * linux-nat.c (handle_target_event): Adjust. * record-btrace.c (record_btrace_handle_async_inferior_event): Adjust. * record-full.c (record_full_async_inferior_event_handler): Adjust. * remote.c (remote_async_inferior_event_handler): Adjust. Change-Id: I3c2aa1eb0ea3e0985df096660d2dcd794674f2ea
2020-07-01Make tui_win_info::name pure virtualTom Tromey3-4/+11
It seemed cleaner to me for tui_win_info::name to be pure virtual. This meant adding a name method to the locator window; but this too seems like an improvement. gdb/ChangeLog 2020-07-01 Tom Tromey <tom@tromey.com> * tui/tui-data.h (struct tui_win_info) <name>: Now pure virtual. * tui/tui-stack.h (struct tui_locator_window) <name>: New method.
2020-07-01Remove tui_gen_win_infoTom Tromey6-93/+76
This merges the tui_gen_win_info base class with tui_win_info; renaming the resulting class to tui_win_info. gdb/ChangeLog 2020-07-01 Tom Tromey <tom@tromey.com> * tui/tui-wingeneral.c (tui_win_info::refresh_window): Move from tui_gen_win_info. (tui_win_info::make_window): Merge with tui_gen_win_info::make_window. (tui_win_info::make_visible): Move from tui_gen_win_info. * tui/tui-win.c (tui_win_info::max_width): Move from tui_gen_win_info. * tui/tui-layout.h (class tui_layout_window) <m_window>: Change type. <window_factory>: Likewise. * tui/tui-layout.c (tui_win_info::resize): Move from tui_gen_win_info. (make_standard_window): Change return type. (get_locator_window, tui_get_window_by_name): Likewise. (tui_layout_window::apply): Remove a cast. * tui/tui-data.h (MIN_WIN_HEIGHT): Move earlier. (struct tui_win_info): Merge with tui_gen_win_info. (struct tui_gen_win_info): Remove.
generated by cgit v1.1 at 2025-01-21 10:27:09 +0000