aboutsummaryrefslogtreecommitdiff
path: root/gdb
AgeCommit message (Collapse)AuthorFilesLines
2020-08-05gdb/testsuite: link some dwarf2 tests with nopieSimon Marchi7-6/+14
I noticed some gdb.dwarf2 tests not running on my machine because of this: Running /home/simark/src/binutils-gdb/gdb/testsuite/gdb.dwarf2/dw2-single-line-discriminators.exp ... gdb compile failed, /usr/bin/ld: /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.dwarf2/dw2-single-line-discriminators/dw2-single-line-discriminators0.o: relocation R_X86_64_32S against symbol `x' can not be used when making a PIE object; recompile with -fPIE collect2: error: ld returned 1 exit status We get this when the target toolchain produces position-independent executables by default. These tests are built from some assembly which produces some relocations incompatible with position-independent executables. Add `nopie` to the compilation flags of these tests to force the toolchain to produce non-position-independent executables. With this, the changed tests run successfully on my machine. gdb/ChangeLog: * gdb.dwarf2/clztest.exp, gdb.dwarf2/dw2-common-block.exp, gdb.dwarf2/dw2-dup-frame.exp, gdb.dwarf2/dw2-reg-undefined.exp, gdb.dwarf2/dw2-single-line-discriminators.exp, dw2-undefined-ret-addr.exp: Pass nopie to compilation options. Change-Id: Ie06c946f8e56a6030be247d1c57f416fa8b67e4c
2020-08-05Fix variant part regressions with older Rust compilerTom Tromey2-9/+30
Older Rust compilers used special field names, rather than DWARF features, to express the variant parts of Rust enums. This is handled in gdb through a quirk recognizer that rewrites the types. Tom de Vries pointed out in PR rust/26197 that the variant part rewrite regressed this code. This patch fixes the problems: * Univariant enums were not handled properly. Now we simply call alloc_rust_variant for these as well. * There was an off-by-one error in the handling of ordinary enums. * Ordinary enums should have the size of their member types reset to match the size of the enclosing enum. (It's not clear to me if this is truly necessary, but it placates a test, and this is just legacy handling in any case.) Tested with Rust 1.12.0, 1.14.0, 1.19.0, 1.36.0, and 1.45.0 on x86-64 Fedora 32. There were some unrelated failures with 1.14.0 and 1.19,0; but considering that these are fairly old releases, I don't plan to look into them unless someone complains. Note that this patch will not fix all the issues in the PR. In that PR, Tom is using a somewhat unusual build of Rust -- in particular it uses an older (pre-DWARF variant part) LLVM with a newer Rust. I believe this compiler doesn't correctly implement the old-style name fallback; the details are in the bug. gdb/ChangeLog 2020-08-05 Tom Tromey <tromey@adacore.com> PR rust/26197: * dwarf2/read.c (alloc_rust_variant): Handle univariant case. (quirk_rust_enum): Call alloc_rust_variant for univariant case. Fix off-by-one and type size errors in ordinary case.
2020-08-05[gdb] Fix prop->const_val uses in gdbtypes.cTom de Vries2-2/+7
After commit 66d6346b25 "gdb: remove TYPE_DYN_PROP_ADDR", I run into: ... FAIL: gdb.fortran/class-allocatable-array.exp: print this%_data%b ... (and 185 more FAILs, all for fortran test-cases). The commit replaces "!x" by "x != 0". Fix this by using "x == 0" instead. Build and tested on x86_64-linux. gdb/ChangeLog: 2020-08-05 Tom de Vries <tdevries@suse.de> * gdbtypes.c (type_not_allocated, type_not_associated): Use "prop->const_val () == 0" instead of "prop->const_val () != 0".
2020-08-04gdb: use bool in frame codeSimon Marchi4-143/+182
Change instances of int variables and return values used as boolean values to use the bool type. Shorten the comments of a few functions, because I think they go a bit too much in implementation details, which appear out of date anyway. Make other misc changes to the functions that are already being changed, such as using nullptr instead of NULL, dropping `struct` keywords and declaring variables when first used. gdb/ChangeLog: * frame.h (frame_id_p): Return bool. (frame_id_artificial_p): Return bool. (frame_id_eq): Return bool. (has_stack_frames): Return bool. (get_selected_frame): Fix typo in comment. (get_frame_pc_if_available): Return bool. (get_frame_address_in_block_if_available): Return bool. (get_frame_func_if_available): Return bool. (read_frame_register_unsigned): Return bool. (get_frame_register_bytes): Return bool. (safe_frame_unwind_memory): Return bool. (deprecated_frame_register_read): Return bool. (frame_unwinder_is): Return bool. * frame.c (struct frame_info) <prev_arch::p>: Change type to bool. <this_id::p>: Likewise. <prev_p>: Likewise. (frame_stash_add): Return bool. (get_frame_id): Use bool. (frame_id_build_special) Use bool. (frame_id_build_unavailable_stack): Use bool. (frame_id_build): Use bool. (frame_id_p): Return bool, use true/false instead of 1/0. (frame_id_artificial_p): Likewise. (frame_id_eq): Likewise. (frame_id_inner): Likewise. (get_frame_func_if_available): Likewise. (read_frame_register_unsigned): Likewise. (deprecated_frame_register_read): Likewise. (get_frame_register_bytes): Likewise. (has_stack_frames): Likewise. (inside_main_func): Likewise. (inside_entry_func): Likewise. (get_frame_pc_if_available): Likewise. (get_frame_address_in_block_if_available): Likewise. (frame_unwinder_is): Likewise. (safe_frame_unwind_memory): Likewise. (frame_unwind_arch): Likewise. Change-Id: I6121fa56739b688be79d73d087d76b268ba5a46a
2020-08-04gdb: change frame_info::prev_func::p type to cached_copy_statusSimon Marchi2-8/+18
One might think that variable `frame_info::prev_func::p` is a simple true/false value, but that's not the case, it can also have the value -1 to mean "unavaiable". Change it to use the `cached_copy_status` enum, which seems designed exactly for this purpose. Rename to `status` to be consistent with `prev_pc::status` (and be cause `p` means `predicate`, which implies boolean, which this is not). gdb/ChangeLog: * frame.c (frame_info) <prev_func> <p>: Rename to status, change type to cached_copy_status. (fprintf_frame): Adjust. (get_frame_func_if_available): Adjust. (frame_cleanup_after_sniffer): Adjust. Change-Id: I50c6ebef6c0acb076e25c741f7f417bfd101d953
2020-08-04Update email address in MAINTAINERSMark Wielaard2-1/+5
gdb/ChangeLog: * MAINTAINERS (Write After Approval): Update email address.
2020-08-04gdb: remove TYPE_DYN_PROP_ADDRSimon Marchi3-6/+7
Remove TYPE_DYN_PROP_ADDR, replacing its uses with calling dynamic_prop::const_val directly. gdb/ChangeLog: * gdbtypes.h (TYPE_DYN_PROP_ADDR): Remove, replace uses with dynamic_prop::const_val. Change-Id: Ie99b9cd9a0627488c1c69a75e57f020d34e392af
2020-08-04gdb: remove TYPE_DYN_PROP_KINDSimon Marchi4-9/+12
Replace uses with calling the dynamic_prop::kind method directly. gdb/ChangeLog: * gdbtypes.h (TYPE_DYN_PROP_KIND): Remove, replace uses with dynamic_prop::kind. Change-Id: I78a3e2890f0b3e3950e9a19ad657b976cbb9610b
2020-08-04gdb: remove TYPE_DYN_PROP_BATONSimon Marchi2-2/+4
This macro is now unused. gdb/ChangeLog: * gdbtypes.h (TYPE_DYN_PROP_BATON): Remove. Change-Id: I6daead794f7ecb516cc59f9e05262c894515fad3
2020-08-04sim: eBPF simulatorJose E. Marchesi2-0/+5
This patch introduces the basics of an instruction-simulator for eBPF. The simulator is based on CGEN. gdb/ChangeLog: 2020-08-04 Jose E. Marchesi <jose.marchesi@oracle.com> * configure.tgt: Set gdb_sim for bpf-*-* targets. sim/ChangeLog: 2020-08-04 Jose E. Marchesi <jose.marchesi@oracle.com> David Faust <david.faust@oracle.com> * configure.tgt (sim_arch): Add entry for bpf-*-*. * configure: Regenerate. * MAINTAINERS: Add maintainer for the BPF simulator. * bpf/Makefile.in: New file. * bpf/bpf-helpers.c: Likewise. * bpf/bpf-helpers.def: Likewise. * bpf/bpf-helpers.h: Likewise. * bpf/bpf-sim.h: Likewise. * bpf/bpf.c: Likewise. * bpf/config.in: Likewise. * bpf/configure.ac: Likewise. * bpf/decode.h: Likewise. * bpf/eng.h: Likewise. * bpf/mloop.in: Likewise. * bpf/sim-if.c: Likewise. * bpf/sim-main.h: Likewise. * bpf/traps.c: Likewise. * bpf/configure: Generate. * bpf/aclocal.m4: Likewise. sim/testsuite/ChangeLog: 2020-08-04 David Faust <david.faust@oracle.com> Jose E. Marchesi <jose.marchesi@oracle.com> * configure: Regenerate. * sim/bpf/allinsn.exp: New file. * sim/bpf/alu.s: Likewise. * sim/bpf/alu32.s: Likewise. * sim/bpf/endbe.s: Likewise. * sim/bpf/endle.s: Likewise. * sim/bpf/jmp.s: Likewise. * sim/bpf/jmp32.s: Likewise. * sim/bpf/ldabs.s: Likewise. * sim/bpf/mem.s: Likewise. * sim/bpf/mov.s: Likewise. * sim/bpf/testutils.inc: Likewise. * sim/bpf/xadd.s: Likewise.
2020-08-04gdb: support for eBPFJose E. Marchesi8-0/+434
This patch adds basic support for the eBPF target: tdep and build machinery. The accompanying simulator is introduced in subsequent patches. gdb/ChangeLog: 2020-08-04 Weimin Pan <weimin.pan@oracle.com> Jose E. Marchesi <jose.marchesi@oracle.com> * configure.tgt: Add entry for bpf-*-*. * Makefile.in (ALL_TARGET_OBS): Add bpf-tdep.o (ALLDEPFILES): Add bpf-tdep.c. * bpf-tdep.c: New file. * MAINTAINERS: Add bpf target and maintainer. gdb/doc/ChangeLog: 2020-08-04 Jose E. Marchesi <jose.marchesi@oracle.com> * gdb.texinfo (Contributors): Add information for the eBPF support. (BPF): New section.
2020-08-04gdb/testsuite: Use 'array unset' instead of just 'unset'Andrew Burgess2-1/+6
In the check-test-names.exp library 'unset' was being used to unset an array variable. Though this seems to work fine on tcl 8.6, it was discovered on a CentOS 7.8.2003 machine, running tcl 8.5, that this doesn't work and 'array unset' should be used instead. Using 'array unset' should work fine for newer and older versions of tcl (since 8.3, releases ~2000). gdb/testsuite/ChangeLog: * lib/check-test-names.exp (do_reset_vars): Use 'array unset' to unset the array variable.
2020-08-04[gdb/symtab] Handle invalid partial DIE referenceTom de Vries2-3/+7
When reverting commit 9cfd2b89bd "[gdb/testsuite] Fix gdb.arch/amd64-entry-value-paramref.S", we run into an internal-error: ... (gdb) file amd64-entry-value-paramref^M Reading symbols from amd64-entry-value-paramref...^M src/gdb/dwarf2/read.c:18903: internal-error: could not find partial DIE 0x1b7 in cache [from module amd64-entry-value-paramref]^M A problem internal to GDB has been detected,^M further debugging may prove unreliable.^M ... because of invalid dwarf. In contrast, when using -readnow, we have: ... (gdb) file -readnow amd64-entry-value-paramref Reading symbols from amd64-entry-value-paramref... Expanding full symbols from amd64-entry-value-paramref... Dwarf Error: Cannot find DIE at 0x1b7 referenced from DIE at 0x11a \ [in module amd64-entry-value-paramref] (gdb) ... Change the internal error into a Dwarf Error, such that we have: ... (gdb) file amd64-entry-value-paramref^M Reading symbols from amd64-entry-value-paramref...^M Dwarf Error: Cannot not find DIE at 0x1b7 \ [from module amd64-entry-value-paramref]^M ^M (No debugging symbols found in amd64-entry-value-paramref)^M (gdb) ... Build and tested on x86_64-linux. gdb/ChangeLog: 2020-08-04 Tom de Vries <tdevries@suse.de> PR symtab/23270 * dwarf2/read.c (find_partial_die): Change internal error into Dwarf Error.
2020-08-03Update FreeBSD system calls for 13.0-CURRENT.John Baldwin2-2/+19
This matches the current set of system calls in the FreeBSD head development branch as of r363367. Some of these system calls were also included in 12.1 release. gdb/ChangeLog: * syscalls/freebsd.xml: Regenerate.
2020-08-03Fix script name in usage and generated year range.John Baldwin2-2/+6
gdb/ChangeLog: * syscalls/update-freebsd.sh: Fix usage and year range.
2020-08-03[gdb/symtab] Ignore DW_LNE_lo_user/DW_LNE_hi_user rangeTom de Vries6-0/+149
When reading an exec with a .debug_line section containing a vendor-specific extended opcode, we get: ... $ gdb -batch -iex "set complaints 10" dw2-vendor-extended-opcode During symbol reading: mangled .debug_line section ... and reading of the .debug_line section is abandoned. The vendor-specific extended opcode should be ignored, as specified in the DWARF standard (7.1 Vendor Extensibility). [ FWIW, vendor-specific standard opcodes are already ignored. ] Fix this by ignoring all vendor-specific extended opcodes. Build and tested on x86_64-linux. gdb/ChangeLog: 2020-08-03 Tom de Vries <tdevries@suse.de> PR symtab/26333 * dwarf2/read.c (dwarf_decode_lines_1): Ignore DW_LNE_lo_user/DW_LNE_hi_user range. gdb/testsuite/ChangeLog: 2020-08-03 Tom de Vries <tdevries@suse.de> PR symtab/26333 * lib/dwarf.exp (DW_LNE_user): New proc. * gdb.dwarf2/dw2-vendor-extended-opcode.c: New test. * gdb.dwarf2/dw2-vendor-extended-opcode.exp: New file.
2020-07-31gdb.base/coremaker2.c: Fix compilation problems for x86_64 -m32 multilibKevin Buettner2-7/+14
There are compilation warnings / errors when compiling coremaker2.c for the gdb.base/corefile2.exp tests. Here's the command to use on x86_64 linux: make check RUNTESTFLAGS="--target_board unix/-m32" \ TESTS="gdb.base/corefile2.exp" These are the warnings / errors - I've shortened the paths somewhat: gdb compile failed, gdb/testsuite/gdb.base/coremaker2.c: In function 'main': gdb/testsuite/gdb.base/coremaker2.c:106:11: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] 106 | addr = ((unsigned long long) buf_ro + pagesize) & ~(pagesize - 1); | ^ gdb/testsuite/gdb.base/coremaker2.c:108:15: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] 108 | if (addr <= (unsigned long long) buf_ro | ^ gdb/testsuite/gdb.base/coremaker2.c:109:18: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] 109 | || addr >= (unsigned long long) buf_ro + sizeof (buf_ro)) | ^ gdb/testsuite/gdb.base/coremaker2.c:115:19: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] 115 | mbuf_ro = mmap ((void *) addr, pagesize, PROT_READ, | ^ gdb/testsuite/gdb.base/coremaker2.c:130:11: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] 130 | addr = ((unsigned long long) buf_rw + pagesize) & ~(pagesize - 1); | ^ gdb/testsuite/gdb.base/coremaker2.c:132:15: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] 132 | if (addr <= (unsigned long long) buf_rw | ^ gdb/testsuite/gdb.base/coremaker2.c:133:18: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] 133 | || addr >= (unsigned long long) buf_rw + sizeof (buf_rw)) | ^ gdb/testsuite/gdb.base/coremaker2.c:139:19: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] 139 | mbuf_rw = mmap ((void *) addr, pagesize, PROT_READ, | ^ These were fixed by changing unsigned long long to uintptr_t. Tested on either rawhide or Fedora 32 with architectures: x86_64, x86_64/-m32, aarch64, s390x, and ppc64le. gdb/testsuite/ChangeLog: * gdb.base/coremaker2.c: Change all uses of 'unsigned long long' to 'uintptr_t' (inttypes.h): Include.
2020-07-31Fix gdb.base/corefile2.exp test case for ppc64leKevin Buettner2-12/+22
It turns out that the recently added gdb.base/corefile2.exp test won't run on ppc64le linux. The test case fails the internal checks which ensure that a mmap'd region can be placed within the statically allocated regions buf_rw[] and buf_ro[]. ppc64le linux apparently has 64k pages, which is much larger than the 24k regions originally allocated for buf_rw[] and buf_ro[]. This patch increases the size of each region to 256 KiB. Tested on either rawhide or Fedora 32 for these architectures: x86_64, x86_64/-m32, ppc64le, aarch64, and s390x. gdb/testsuite/ChangeLog: * gdb.base/coremaker2.c (buf_rw): Increase size to 256 KiB. (C5_24k): Delete. (C5_8k, C5_64k, C5_256k): New macros. (buf_ro): Allocate 256 KiB of initialized data.
2020-07-30gdb: handle non-const property types in ada_modulus (PR ada/26318)Simon Marchi2-1/+14
PR 26318 shows that running `maint print symbols` on an Ada binary, compiled with an Ada distribution that includes debug info for the standard library, triggers this assertion: /home/simark/src/binutils-gdb/gdb/gdbtypes.h:526: internal-error: LONGEST dynamic_prop::const_val() const: Assertion `m_kind == PROP_CONST' failed. The problem is in particular when printing type `system__object_reader__decoded_ada_name__TTdecodedSP1___XDL_0`, which has a dynamic high bound (PROP_LOCLIST kind). When printing a concrete value of this type, this type gets resolved to a type with a constant high bound, so ada_modulus can return this constant value. However, when printing the dynamic range type on its own, such as with `maint print symbols`, the high bound is still of kind PROP_LOCLIST. When ada_modulus tries to access the property as a const value, the assert triggers. There's no sensible numerical value to return in this case. Ideally, ada_modulus would return something to the caller indicating that the value is dynamic and therefore can't be returned as an integer. The callers would handle it, for example `maint print symbols` would say that the high bound of the type is dynamic. However, this patch implements the simpler fix of returning 0 in that case. It kind of restores the previous behavior of before we validated the dynamic property kind in the getters, where we would just return whatever random integer value was in `const_val`. Except now it's consistently 0. This is what we had before we added dynamic property getters: $ ./gdb -q ~/foo -ex "maint expand-symtabs" -ex "maint print symbols" -batch | grep 'typedef <system__object_reader__decoded_ada_name__TTdecodedSP1' typedef <system__object_reader__decoded_ada_name__TTdecodedSP1: mod 107820865988257; and this is what we have now: $ ./gdb -q ~/foo -ex "maint expand-symtabs" -ex "maint print symbols" -batch | grep 'typedef <system__object_reader__decoded_ada_name__TTdecodedSP1' typedef <system__object_reader__decoded_ada_name__TTdecodedSP1: mod 0; The value 107820865988257 is the `baton` field of the property's union interpreted as an integer, so a bogus value. gdb/ChangeLog: PR ada/26318 * ada-lang.c (ada_modulus): Return 0 if property is not of const kind. Change-Id: I3f6d343a9c3cd7cd62a4fc591943a43541223d50
2020-07-30gdb/breakpoint: refactor 'set_breakpoint_condition'Tankut Baris Aktemur2-20/+13
Apply minor refactoring to 'set_breakpoint_condition'. gdb/ChangeLog: 2020-07-30 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> * breakpoint.c (set_breakpoint_condition): Do minor refactoring.
2020-07-30gdb/breakpoint: set the condition exp after parsing the condition successfullyTankut Baris Aktemur4-21/+139
In 'set_breakpoint_condition', GDB resets the condition expressions before parsing the condition input by the user. This leads to the problem of losing the condition expressions if the new condition does not parse successfully and is thus rejected. For instance: $ gdb ./test Reading symbols from ./test... (gdb) start Temporary breakpoint 1 at 0x114e: file test.c, line 4. Starting program: test Temporary breakpoint 1, main () at test.c:4 4 int a = 10; (gdb) break 5 Breakpoint 2 at 0x555555555155: file test.c, line 5. Now define a condition that would evaluate to false. Next, attempt to overwrite that with an invalid condition: (gdb) cond 2 a == 999 (gdb) cond 2 gibberish No symbol "gibberish" in current context. (gdb) info breakpoints Num Type Disp Enb Address What 2 breakpoint keep y 0x0000555555555155 in main at test.c:5 stop only if a == 999 It appears as if the bad condition is successfully rejected. But if we resume the program, we see that we hit the breakpoint although the condition would evaluate to false. (gdb) continue Continuing. Breakpoint 2, main () at test.c:5 5 a = a + 1; /* break-here */ Fix the problem by not resetting the condition expressions before parsing the condition input. Suppose the fix is applied. A similar problem could occur if the condition is valid, but has "junk" at the end. In this case, parsing succeeds, but an error is raised immediately after. It is too late, though; the condition expression is already updated. For instance: $ gdb ./test Reading symbols from ./test... (gdb) start Temporary breakpoint 1 at 0x114e: file test.c, line 4. Starting program: test Temporary breakpoint 1, main () at test.c:4 4 int a = 10; (gdb) break 5 Breakpoint 2 at 0x555555555155: file test.c, line 5. (gdb) cond 2 a == 999 (gdb) cond 2 a == 10 if Junk at end of expression (gdb) info breakpoints Num Type Disp Enb Address What 2 breakpoint keep y 0x0000555555555155 in main at test.c:5 stop only if a == 999 (gdb) c Continuing. Breakpoint 2, main () at test.c:5 5 a = a + 1; /* break-here */ (gdb) We should not have hit the breakpoint because the condition would evaluate to false. Fix this problem by updating the condition expression of the breakpoint after parsing the input successfully and checking that there is no remaining junk. gdb/ChangeLog: 2020-07-30 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> * breakpoint.c (set_breakpoint_condition): Update the condition expressions after checking that the input condition string parses successfully and does not contain junk at the end. gdb/testsuite/ChangeLog: 2020-07-30 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> * gdb.base/condbreak-bad.exp: Extend the test with scenarios that attempt to overwrite an existing condition with a condition that fails parsing and also with a condition that parses fine but contains junk at the end.
2020-07-30gdb/breakpoint: do not update the condition string if parsing the condition ↵Tankut Baris Aktemur5-8/+83
fails The condition of a breakpoint can be set with the 'cond' command. If the condition has errors that make it problematic to evaluate, it appears like GDB rejects the condition, but updates the breakpoint's condition string, which causes incorrect/unintuitive behavior. For instance: $ gdb ./test Reading symbols from ./test... (gdb) break 5 Breakpoint 1 at 0x1155: file test.c, line 5. (gdb) cond 1 gibberish No symbol "gibberish" in current context. At this point, it looks like the condition was rejected. But "info breakpoints" shows the following: (gdb) info breakpoints Num Type Disp Enb Address What 1 breakpoint keep y 0x0000000000001155 in main at test.c:5 stop only if gibberish Running the code gives the following behavior, where re-insertion of the breakpoint causes failures. (gdb) run Starting program: test warning: failed to reevaluate condition for breakpoint 1: No symbol "gibberish" in current context. warning: failed to reevaluate condition for breakpoint 1: No symbol "gibberish" in current context. warning: failed to reevaluate condition for breakpoint 1: No symbol "gibberish" in current context. warning: failed to reevaluate condition for breakpoint 1: No symbol "gibberish" in current context. warning: failed to reevaluate condition for breakpoint 1: No symbol "gibberish" in current context. [Inferior 1 (process 19084) exited normally] (gdb) This broken behavior occurs because GDB updates the condition string of the breakpoint *before* checking that it parses successfully. When parsing fails, the update has already taken place. Fix the problem by updating the condition string *after* parsing the condition. We get the following behavior when this patch is applied: $ gdb ./test Reading symbols from ./test... (gdb) break 5 Breakpoint 1 at 0x1155: file test.c, line 5. (gdb) cond 1 gibberish No symbol "gibberish" in current context. (gdb) info breakpoints Num Type Disp Enb Address What 1 breakpoint keep y 0x0000000000001155 in main at test.c:5 (gdb) run Starting program: test Breakpoint 1, main () at test.c:5 5 a = a + 1; /* break-here */ (gdb) c Continuing. [Inferior 1 (process 15574) exited normally] (gdb) A side note: The problem does not occur if the condition is given at the time of breakpoint definition, as in "break 5 if gibberish", because the parsing of the condition fails during symtab-and-line creation, before the breakpoint is created. Finally, the code included the following comment: /* I don't know if it matters whether this is the string the user typed in or the decompiled expression. */ This comment did not make sense to me because the condition string is the user-typed input. The patch updates this comment, too. gdb/ChangeLog: 2020-07-30 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> * breakpoint.c (set_breakpoint_condition): Update the condition string after parsing the new condition successfully. gdb/testsuite/ChangeLog: 2020-07-30 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> * gdb.base/condbreak-bad.c: New test. * gdb.base/condbreak-bad.exp: New file.
2020-07-30[gdb/testsuite] Fix gdb.fortran/info-modules.exp with gcc-4.8Tom de Vries3-6/+32
When running test-case gdb.fortran/info-modules.exp with gfortran 4.8.5, I get: ... FAIL: gdb.fortran/info-modules.exp: info module functions: \ check for entry 'info-types.f90', '35', \ 'void mod1::__copy_mod1_M1t1\(Type m1t1, Type m1t1\);' FAIL: gdb.fortran/info-modules.exp: info module functions -m mod1: \ check for entry 'info-types.f90', '35', \ 'void mod1::__copy_mod1_M1t1\(Type m1t1, Type m1t1\);' FAIL: gdb.fortran/info-modules.exp: info module variables: \ check for entry 'info-types.f90', '(35)?', \ 'Type m1t1 mod1::__def_init_mod1_M1t1;' FAIL: gdb.fortran/info-modules.exp: info module variables: \ check for entry 'info-types.f90', '(35)?', \ 'Type __vtype_mod1_M1t1 mod1::__vtab_mod1_M1t1;' ... With gfortran 7.5.0, we have: ... $ readelf -wi info-modules | egrep "DW_AT_name.*(copy|def_init|vtype)_mod1" <286> DW_AT_name : __def_init_mod1_M1t1 <29f> DW_AT_name : __vtype_mod1_M1t1 <3de> DW_AT_name : __copy_mod1_M1t1 $ ... but with gfortran 4.8.5: ... $ readelf -wi info-modules | egrep "DW_AT_name.*(copy|def_init|vtype)_mod1" $ ... Fix this by allowing these module functions and variables to be missing. Tested on x86_64-linux with gcc 4.8.5 and gcc 7.5.0. gdb/testsuite/ChangeLog: 2020-07-30 Tom de Vries <tdevries@suse.de> * lib/sym-info-cmds.exp (GDBInfoModuleSymbols::check_entry_1): Factor out of ... (GDBInfoModuleSymbols::check_entry): ... here. (GDBInfoModuleSymbols::check_optional_entry): New proc. * gdb.fortran/info-modules.exp: Use check_optional_entry for entries related to __def_init_mod1_M1t1 / __vtype_mod1_M1t1 / __copy_mod1_M1t1.
2020-07-30Unify Solaris procfs and largefile handlingRainer Orth9-45/+99
GDB currently doesn't build on 32-bit Solaris: * On Solaris 11.4/x86: In file included from /usr/include/sys/procfs.h:26, from /vol/src/gnu/gdb/hg/master/dist/gdb/i386-sol2-nat.c:24: /usr/include/sys/old_procfs.h:31:2: error: #error "Cannot use procfs in the large file compilation environment" #error "Cannot use procfs in the large file compilation environment" ^~~~~ * On Solaris 11.3/x86 there are several more instances of this. The interaction between procfs and large-file support historically has been a royal mess on Solaris: * There are two versions of the procfs interface: ** The old ioctl-based /proc, deprecated and not used any longer in either gdb or binutils. ** The `new' (introduced in Solaris 2.6, 1997) structured /proc. * There are two headers one can possibly include: ** <procfs.h> which only provides the structured /proc, definining _STRUCTURED_PROC=1 and then including ... ** <sys/procfs.h> which defaults to _STRUCTURED_PROC=0, the ioctl-based /proc, but provides structured /proc if _STRUCTURED_PROC == 1. * procfs and the large-file environment didn't go well together: ** Until Solaris 11.3, <sys/procfs.h> would always #error in 32-bit compilations when the large-file environment was active (_FILE_OFFSET_BITS == 64). ** In both Solaris 11.4 and Illumos, this restriction was lifted for structured /proc. So one has to be careful always to define _STRUCTURED_PROC=1 when testing for or using <sys/procfs.h> on Solaris. As the errors above show, this isn't always the case in binutils-gdb right now. Also one may need to disable large-file support for 32-bit compilations on Solaris. config/largefile.m4 meant to do this by wrapping the AC_SYS_LARGEFILE autoconf macro with appropriate checks, yielding ACX_LARGEFILE. Unfortunately the macro doesn't always succeed because it neglects the _STRUCTURED_PROC part. To make things even worse, since GCC 9 g++ predefines _FILE_OFFSET_BITS=64 on Solaris. So even if largefile.m4 deciced not to enable large-file support, this has no effect, breaking the gdb build. This patch addresses all this as follows: * All tests for the <sys/procfs.h> header are made with _STRUCTURED_PROC=1, the definition going into the various config.h files instead of having to make them (and sometimes failing) in the affected sources. * To cope with the g++ predefine of _FILE_OFFSET_BITS=64, -U_FILE_OFFSET_BITS is added to various *_CPPFLAGS variables. It had been far easier to have just #undef _FILE_OFFSET_BITS in config.h, but unfortunately such a construct in config.in is commented by config.status irrespective of indentation and whitespace if large-file support is disabled. I found no way around this and putting the #undef in several global headers for bfd, binutils, ld, and gdb seemed way more invasive. * Last, the applicability check in largefile.m4 was modified only to disable largefile support if really needed. To do so, it checks if <sys/procfs.h> compiles with _FILE_OFFSET_BITS=64 defined. If it doesn't, the disabling only happens if gdb exists in-tree and isn't disabled, otherwise (building binutils from a tarball), there's no conflict. What initially confused me was the check for $plugins here, which originally caused the disabling not to take place. Since AC_PLUGINGS does enable plugin support if <dlfcn.h> exists (which it does on Solaris), the disabling never happened. I could find no explanation why the linker plugin needs large-file support but thought it would be enough if gld and GCC's lto-plugin agreed on the _FILE_OFFSET_BITS value. Unfortunately, that's not enough: lto-plugin uses the simple-object interface from libiberty, which includes off_t arguments. So to fully disable large-file support would mean also disabling it in libiberty and its users: gcc and libstdc++-v3. This seems highly undesirable, so I decided to disable the linker plugin instead if large-file support won't work. The patch allows binutils+gdb to build on i386-pc-solaris2.11 (both Solaris 11.3 and 11.4, using GCC 9.3.0 which is the worst case due to predefined _FILE_OFFSET_BITS=64). Also regtested on amd64-pc-solaris2.11 (again on Solaris 11.3 and 11.4), x86_64-pc-linux-gnu and i686-pc-linux-gnu. config: * largefile.m4 (ACX_LARGEFILE) <sparc-*-solaris*|i?86-*-solaris*>: Check for <sys/procfs.h> incompatilibity with large-file support on Solaris. Only disable large-file support and perhaps plugins if needed. Set, substitute LARGEFILE_CPPFLAGS if so. bfd: * bfd.m4 (BFD_SYS_PROCFS_H): New macro. (BFD_HAVE_SYS_PROCFS_TYPE): Require BFD_SYS_PROCFS_H. Don't define _STRUCTURED_PROC. (BFD_HAVE_SYS_PROCFS_TYPE_MEMBER): Likewise. * elf.c [HAVE_SYS_PROCFS_H] (_STRUCTURED_PROC): Don't define. * configure.ac: Use BFD_SYS_PROCFS_H to check for <sys/procfs.h>. * configure, config.in: Regenerate. * Makefile.am (AM_CPPFLAGS): Add LARGEFILE_CPPFLAGS. * Makefile.in, doc/Makefile.in: Regenerate. binutils: * Makefile.am (AM_CPPFLAGS): Add LARGEFILE_CPPFLAGS. * Makefile.in, doc/Makefile.in: Regenerate. * configure: Regenerate. gas: * Makefile.am (AM_CPPFLAGS): Add LARGEFILE_CPPFLAGS. * Makefile.in, doc/Makefile.in: Regenerate. * configure: Regenerate. gdb: * proc-api.c (_STRUCTURED_PROC): Don't define. * proc-events.c: Likewise. * proc-flags.c: Likewise. * proc-why.c: Likewise. * procfs.c: Likewise. * Makefile.in (INTERNAL_CPPFLAGS): Add LARGEFILE_CPPFLAGS. * configure, config.in: Regenerate. gdbserver: * configure, config.in: Regenerate. gdbsupport: * Makefile.am (AM_CPPFLAGS): Add LARGEFILE_CPPFLAGS. * common.m4 (GDB_AC_COMMON): Use BFD_SYS_PROCFS_H to check for <sys/procfs.h>. * Makefile.in: Regenerate. * configure, config.in: Regenerate. gnulib: * configure.ac: Run ACX_LARGEFILE before gl_EARLY. * configure: Regenerate. gprof: * Makefile.am (AM_CPPFLAGS): Add LARGEFILE_CPPFLAGS. * Makefile.in: Regenerate. * configure: Regenerate. ld: * Makefile.am (AM_CPPFLAGS): Add LARGEFILE_CPPFLAGS. * Makefile.in: Regenerate. * configure: Regenerate.
2020-07-30[gdb/testsuite] Fix gdb.fortran/ptype-on-functions.exp with gcc-4.8Tom de Vries2-2/+7
When running test-case gdb.fortran/ptype-on-functions.exp with gfortran 4.8.5, we run into: ... (gdb) ptype some_module::get_number^M type = integer(kind=4) (Type __class_some_module_Number)^M (gdb) FAIL: gdb.fortran/ptype-on-functions.exp: ptype some_module::get_number ptype some_module::set_number^M type = void (Type __class_some_module_Number, integer(kind=4))^M (gdb) FAIL: gdb.fortran/ptype-on-functions.exp: ptype some_module::set_number ... The test-case pattern expects a "_t" suffix on "__class_some_module_Number". The difference is caused by a gcc commit 073afca6884 'class.c (gfc_build_class_symbol): Append "_t" to target class names to make the generated type names unique' which has been present since gcc 4.9.0. Fix the pattern by optionally matching the _t suffix. Tested on x86_64-linux, with gfortran 4.8.5 and 7.5.0. gdb/testsuite/ChangeLog: 2020-07-30 Tom de Vries <tdevries@suse.de> * gdb.fortran/ptype-on-functions.exp: Make "_t" suffix on "__class_some_module_Number_t" optional.
2020-07-30[gdb/build] Fix Wmaybe-uninitialized in gdb/ui-style.hTom de Vries2-2/+14
When building CFLAGS/CXXFLAGS="-O2 -g -Wall" and gcc 4.8.5, we run into: ... src/gdb/cli/cli-style.c:154:42: warning: '*((void*)&<anonymous> +8)' \ may be used uninitialized in this function [-Wmaybe-uninitialized] src/gdb/cli/cli-style.c:154:42: warning: '*((void*)&<anonymous> +9)' \ may be used uninitialized in this function [-Wmaybe-uninitialized] src/gdb/cli/cli-style.c:154:42: warning: '*((void*)&<anonymous> +10)' \ may be used uninitialized in this function [-Wmaybe-uninitialized] ... The root cause is that the data members of class color, nested in struct ui_file_style in gdb/ui-style.h: ... bool m_simple; int m_value; uint8_t m_red, m_green, m_blue; ... are only partially initialized by this constructor: ... color (int c) : m_simple (true), m_value (c) { gdb_assert (c >= -1 && c <= 255); } ... but the default copy constructor will copy all the fields. The member m_simple acts as a discriminant, to indicate which other members are valid: - m_value (with m_simple == true) - m_red, m_green, m_blue (with m_simple == false) So, we don't need storage for both m_value and m_red/m_green/m_blue at the same time. Fix this by wrapping the respective members in a union: ... bool m_simple; union { int m_value; struct { uint8_t m_red, m_green, m_blue; }; }; ... which also fixes the warning. Build and reg-tested on x86_64-linux. gdb/ChangeLog: 2020-07-30 Tom de Vries <tdevries@suse.de> PR build/26320 * ui-style.h (struct ui_file_style::color): Wrap m_value and m_red/m_green/m_blue in a union.
2020-07-29[gdb/testsuite] Fix captured_command_loop breakpoint in selftestsTom de Vries2-2/+8
When building gcc with CFLAGS/CXXFLAGS="-O2 -g", and running the regression tests, I run into the following FAILs: ... FAIL: gdb.gdb/complaints.exp: breakpoint in captured_command_loop FAIL: gdb.gdb/python-interrupts.exp: breakpoint in captured_command_loop FAIL: gdb.gdb/python-selftest.exp: breakpoint in captured_command_loop ... The problem is that when setting the breakpoint at captured_command_loop: ... (gdb) break captured_command_loop^M Breakpoint 1 at 0x4230ed: captured_command_loop. (2 locations)^M (gdb) FAIL: gdb.gdb/complaints.exp: breakpoint in captured_command_loop ... there are two breakpoint locations instead of one. This is due to PR26096 - "gdb sets breakpoint at cold clone": ... $ nm gdb | grep captured_command_loop| c++filt 0000000000659f20 t captured_command_loop() 00000000004230ed t captured_command_loop() [clone .cold] ... Work around this by allowing multiple breakpoint locations for captured_command_loop. Reg-tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-07-29 Tom de Vries <tdevries@suse.de> * lib/selftest-support.exp (selftest_setup): Allow breakpoint at multiple locations.
2020-07-29[tdep/s390] Fix Wmaybe-uninitialized in s390_displaced_step_fixupTom de Vries2-2/+8
When building gdb with CFLAGS/CXXFLAGS="-O2 -g -Wall", I see: ... src/gdb/s390-tdep.c: In function 'void s390_displaced_step_fixup(gdbarch*, \ displaced_step_closure*, CORE_ADDR, CORE_ADDR, regcache*)': src/gdb/s390-tdep.c:528:30: warning: 'r2' may be used uninitialized in this \ function [-Wmaybe-uninitialized] 528 | if (insn[0] == op_basr && r2 == 0) | ~~~~~~~~~~~~~~~~~~~^~~~~~~~~~ ... The problem is that the compiler is unaware that 'is_rr (insn, op_basr, &r1, &r2) == 1' ensures that 'insn[0] == op_basr': ... if (is_rr (insn, op_basr, &r1, &r2) || is_rx (insn, op_bas, &r1, &d2, &x2, &b2)) { /* Recompute saved return address in R1. */ regcache_cooked_write_unsigned (regs, S390_R0_REGNUM + r1, amode | (from + insnlen)); /* Update PC iff the instruction doesn't actually branch. */ if (insn[0] == op_basr && r2 == 0) regcache_write_pc (regs, from + insnlen); } ... Fix this by storing the result of the call, and using it instead of 'insn[0] ==op_basr'. Build on x86_64-linux with --enable-targets=s390-suse-linux,s390x-suse-linux. gdb/ChangeLog: 2020-07-29 Tom de Vries <tdevries@suse.de> PR tdep/26280 * s390-tdep.c (s390_displaced_step_fixup): Fix Wmaybe-uninitialized.
2020-07-29[gdb/testsuite] Make gdb.dwarf2/dw2-line-number-zero.exp more robustTom de Vries2-2/+7
On aarch64, there are FAILs for gdb.dwarf2/dw2-line-number-zero.exp due to problems in the prologue analyzer (filed as PR26310). Make the test-case more robust by avoiding to use the prologue analyzer: ... -gdb_breakpoint "bar1" +gdb_breakpoint "$srcfile:27" ... Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-07-29 Tom de Vries <tdevries@suse.de> * gdb.dwarf2/dw2-line-number-zero.exp: Set breakpoints on lines rather than function name.
2020-07-28Demangle function names when disassemblingAndrew Burgess7-11/+160
Andrew Burgess pointed out a regression, which he described in PR symtab/26270: ================ After commit: commit bcfe6157ca288efed127c5efe21ad7924e0d98cf (refs/bisect/bad) Date: Fri Apr 24 15:35:01 2020 -0600 Use the linkage name if it exists The disassembler no longer demangles function names in its output. So we see things like this: (gdb) disassemble tree_insert Dump of assembler code for function _Z11tree_insertP4nodei: .... Instead of this: (gdb) disassemble tree_insert Dump of assembler code for function tree_insert(node*, int): .... This is because find_pc_partial_function now returns the linkage name rather than the demangled name. ================ This patch fixes the problem by introducing a new "overload" of find_pc_partial_function, which returns the general_symbol_info rather than simply the name. This lets the disassemble command choose which name to show. Regression tested on x86-64 Fedora 32. gdb/ChangeLog 2020-07-28 Tom Tromey <tromey@adacore.com> PR symtab/26270: * symtab.h (find_pc_partial_function_sym): Declare. * cli/cli-cmds.c (disassemble_command): Use find_pc_partial_function_sym. Check asm_demangle. * blockframe.c (cache_pc_function_sym): New global. (cache_pc_function_name): Remove. (clear_pc_function_cache): Update. (find_pc_partial_function_sym): New function, from find_pc_partial_function. (find_pc_partial_function): Rewrite using find_pc_partial_function_sym. gdb/testsuite/ChangeLog 2020-07-28 Andrew Burgess <andrew.burgess@embecosm.com> PR symtab/26270: * gdb.cp/disasm-func-name.cc: New file. * gdb.cp/disasm-func-name.exp: New file.
2020-07-28Update "disassemble" helpTom Tromey2-5/+10
Pedro pointed out that disassemble/m should be documented after disassemble/s, because /m is deprecated. This patch does so, and adds a usage line. Regression tested on x86-64 Fedora 32. gdb/ChangeLog 2020-07-28 Tom Tromey <tromey@adacore.com> * cli/cli-cmds.c (_initialize_cli_cmds): Rearrange "disassemble" help. Add usage.
2020-07-28Fix bug in DW_OP_GNU_variable_value evaluationTom Tromey4-1/+14
A modified version of the gnat compiler (TBH I don't know if the modifications are relevant to this bug or not, but I figured I'd mention it) can generate a DWARF location expression like: <1><1201>: Abbrev Number: 3 (DW_TAG_dwarf_procedure) <1202> DW_AT_location : 32 byte block: 12 31 29 28 4 0 30 2f 12 0 14 30 2d 28 4 0 14 2f 1 0 30 34 1e 23 3 9 fc 1a 16 13 16 13 (DW_OP_dup; DW_OP_lit1; DW_OP_eq; DW_OP_bra: 4; DW_OP_lit0; DW_OP_skip: 18; DW_OP_over; DW_OP_lit0; DW_OP_lt; DW_OP_bra: 4; DW_OP_over; DW_OP_skip: 1; DW_OP_lit0; DW_OP_lit4; DW_OP_mul; DW_OP_plus_uconst: 3; DW_OP_const1s: -4; DW_OP_and; DW_OP_swap; DW_OP_drop; DW_OP_swap; DW_OP_drop) <2><1279>: Abbrev Number: 9 (DW_TAG_structure_type) <127a> DW_AT_name : (indirect string, offset: 0x1a5a): p__logical_channel_t <127e> DW_AT_byte_size : 18 byte block: fd 43 12 0 0 97 94 1 99 34 0 0 0 23 7 9 fc 1a (DW_OP_GNU_variable_value: <0x1243>; DW_OP_push_object_address; DW_OP_deref_size: 1; DW_OP_call4: <0x1201>; DW_OP_plus_uconst: 7; DW_OP_const1s: -4; DW_OP_and) When evaluated, this gives: Incompatible types on DWARF stack In Jakub's original message about DW_OP_GNU_variable_value: https://gcc.gnu.org/legacy-ml/gcc-patches/2017-02/msg01499.html .. it says: The intended behavior is that the debug info consumer computes the value of that referenced variable at the current PC, and if it can compute it and pushes the value as a generic type integer into the DWARF stack Instead, gdb is using the variable's type -- but this fails with some operations, like DW_OP_and, which expect the types to match. I believe what was intended was for the value to be cast to the DWARF "untyped" type, which is what this patch implements. This patch also updates varval.exp to exhibit the bug. gdb/ChangeLog 2020-07-28 Tom Tromey <tromey@adacore.com> * dwarf2/expr.c (dwarf_expr_context::execute_stack_op) <DW_OP_GNU_variable_value>: Cast to address type. gdb/testsuite/ChangeLog 2020-07-28 Tom Tromey <tromey@adacore.com> * gdb.dwarf2/varval.exp (setup_exec): Add 'or' instruction to 'varval' location.
2020-07-28Implement xfer_partial TARGET_OBJECT_SIGNAL_INFO for NetBSDKamil Rytarowski4-0/+217
NetBSD implements reading and overwriting siginfo_t received by the tracee. With TARGET_OBJECT_SIGNAL_INFO signal information can be examined and modified through the special variable $_siginfo. Implement the "get_siginfo_type" gdbarch method for NetBSD architectures. As with Linux architectures, cache the created type in the gdbarch when it is first created. Currently NetBSD uses an identical siginfo type on all architectures, so there is no support for architecture-specific fields. gdb/ChangeLog: * nbsd-nat.h (nbsd_nat_target::xfer_partial): New declaration. * nbsd-nat.c (nbsd_nat_target::xfer_partial): New function. * nbsd-tdep.c (nbsd_gdbarch_data_handle, struct nbsd_gdbarch_data) (init_nbsd_gdbarch_data, get_nbsd_gdbarch_data) (nbsd_get_siginfo_type): New. (nbsd_init_abi): Install gdbarch "get_siginfo_type" method. (_initialize_nbsd_tdep): New
2020-07-28PKG_CHECK_MODULES: Properly check if $pkg_cv_[]$1[]_LIBS worksH.J. Lu2-6/+13
There is no need to check $pkg_cv_[]$1[]_LIBS works if package check failed. config/ PR binutils/26301 * pkg.m4 (PKG_CHECK_MODULES): Use AC_TRY_LINK only if $pkg_failed = no. binutils/ PR binutils/26301 * configure: Regenerated. gdb/ PR binutils/26301 * configure: Regenerated.
2020-07-28PKG_CHECK_MODULES: Check if $pkg_cv_[]$1[]_LIBS worksH.J. Lu2-0/+27
It is quite normal to have headers without library on multilib OSes. Add AC_TRY_LINK to PKG_CHECK_MODULES to check if $pkg_cv_[]$1[]_LIBS works. config/ PR binutils/26301 * pkg.m4 (PKG_CHECK_MODULES): Add AC_TRY_LINK to check if $pkg_cv_[]$1[]_LIBS works. binutils/ PR binutils/26301 * configure: Regenerated. gdb/ PR binutils/26301 * configure: Regenerated.
2020-07-28gdb/python: make more use of RegisterDescriptorsAndrew Burgess9-57/+153
This commit unifies all of the Python register lookup code (used by Frame.read_register, PendingFrame.read_register, and gdb.UnwindInfo.add_saved_register), and adds support for using a gdb.RegisterDescriptor for register lookup. Currently the register unwind code (PendingFrame and UnwindInfo) allow registers to be looked up either by name, or by GDB's internal number. I suspect the number was added for performance reasons, when unwinding we don't want to repeatedly map from name to number for every unwind. However, this kind-of sucks, it means Python scripts could include GDB's internal register numbers, and if we ever change this numbering in the future users scripts will break in unexpected ways. Meanwhile, the Frame.read_register method only supports accessing registers using a string, the register name. This commit unifies all of the register to register-number lookup code in our Python bindings, and adds a third choice into the mix, the use of gdb.RegisterDescriptor. The register descriptors can be looked up by name, but once looked up, they contain GDB's register number, and so provide all of the performance benefits of using a register number directly. However, as they are looked up by name we are no longer tightly binding the Python API to GDB's internal numbering scheme. As we may already have scripts in the wild that are using the register numbers directly I have kept support for this in the API, but I have listed this method last in the manual, and I have tried to stress that this is NOT a good method to use and that users should use either a string or register descriptor approach. After this commit all existing Python code should function as before, but users now have new options for how to identify registers. gdb/ChangeLog: * python/py-frame.c: Remove 'user-regs.h' include. (frapy_read_register): Rewrite to make use of gdbpy_parse_register_id. * python/py-registers.c (gdbpy_parse_register_id): New function, moved here from python/py-unwind.c. Updated the return type, and also accepts register descriptor objects. * python/py-unwind.c: Remove 'user-regs.h' include. (pyuw_parse_register_id): Moved to python/py-registers.c. (unwind_infopy_add_saved_register): Update to use gdbpy_parse_register_id. (pending_framepy_read_register): Likewise. * python/python-internal.h (gdbpy_parse_register_id): Declare. gdb/testsuite/ChangeLog: * gdb.python/py-unwind.py: Update to make use of a register descriptor. gdb/doc/ChangeLog: * python.texi (Unwinding Frames in Python): Update descriptions for PendingFrame.read_register and gdb.UnwindInfo.add_saved_register. (Frames In Python): Update description of Frame.read_register.
2020-07-28gdb: Add a find method for RegisterDescriptorIteratorAndrew Burgess6-1/+84
Adds a new method 'find' to the gdb.RegisterDescriptorIterator class, this allows gdb.RegisterDescriptor objects to be looked up directly by register name rather than having to iterate over all registers. This will be of use for a later commit. I've documented the new function in the manual, but I don't think a NEWS entry is required here, as, since the last release, the whole register descriptor mechanism is new, and is already mentioned in the NEWS file. gdb/ChangeLog: * python/py-registers.c: Add 'user-regs.h' include. (register_descriptor_iter_find): New function. (register_descriptor_iterator_object_methods): New static global methods array. (register_descriptor_iterator_object_type): Add pointer to methods array. gdb/testsuite/ChangeLog: * gdb.python/py-arch-reg-names.exp: Add additional tests. gdb/doc/ChangeLog: * python.texi (Registers In Python): Document new find function.
2020-07-27Use SIGTRAP si_code values for all FreeBSD architectures on 11.3 and later.John Baldwin2-3/+14
Fixes to set correct si_code values (such as TRAP_BRKPT) were made to the remaining FreeBSD architectures (MIPS and sparc64) in the head branch leading up to 12.0 and were merged back between the 11.2 and 11.3 releases. gdb/ChangeLog: * fbsd-nat.h: Include <osreldate.h>. Define USE_SIGTRAP_SIGINFO for all architectures on FreeBSD 11.3 and later.
2020-07-27Remove unused declaration from gcore.hTom Tromey2-1/+4
gcore.h declares load_corefile, but there are no other mentions of this in the source. This patch removes it. Tested by grep and rebuilding. gdb/ChangeLog 2020-07-27 Tom Tromey <tromey@adacore.com> * gcore.h (load_corefile): Don't declare.
2020-07-27[gdb/build] Fix typo sys/sockets.h -> sys/socket.hTom de Vries4-8/+11
I'm running into a build breaker: ... src/gdb/ser-tcp.c:65:13: error: conflicting declaration ‘typedef int socklen_t’ 65 | typedef int socklen_t; | ^~~~~~~~~ In file included from ../gnulib/import/unistd.h:40, from /home/vries/gdb_versions/devel/src/gdb/../gnulib/import/pathmax.h:42, from /home/vries/gdb_versions/devel/src/gdb/../gdbsupport/common-defs.h:120, from src/gdb/defs.h:28, from src/gdb/ser-tcp.c:20: /usr/include/unistd.h:277:21: note: previous declaration as ‘typedef __socklen_t socklen_t’ 277 | typedef __socklen_t socklen_t; | ^~~~~~~~~ ... after commit 05a6b8c28b "Don't unnecessarily redefine 'socklen_t' type in MinGW builds". The root cause is a typo in gdb/configure.ac, using sys/sockets.h where sys/socket.h was meant: ... AC_CHECK_HEADERS([sys/sockets.h]) ... Fix the typo. Build and tested on x86_64-linux. gdb/ChangeLog: 2020-07-27 Tom de Vries <tdevries@suse.de> * configure.ac: Fix sys/sockets.h -> sys/socket.h typo. * config.in: Regenerate. * configure: Regenerate.
2020-07-26Don't unnecessarily redefine 'socklen_t' type in MinGW builds.Eli Zaretskii4-2/+52
The original configure-time tests in gdb/ and gdbserver/ failed to detect that 'socklen_t' is defined in MinGW headers because the test program included only sys/socket.h, which is absent in MinGW system headers. However on MS-Windows this data type is declared in another header, ws2tcpip.h. The modified test programs try using ws2tcpip.h if sys/socket.h is unavailable. Thanks to Joel Brobecker who helped me regenerate the configure scripts and the config.in files. gdb/ChangeLog: 2020-07-26 Eli Zaretskii <eliz@gnu.org> * configure.ac (AC_CHECK_HEADERS): Check for sys/socket.h and ws2tcpip.h. When checking whether socklen_t type is defined, use ws2tcpip.h if it is available and sys/socket.h isn't. * configure: Regenerate. * config.in: Regenerate. gdbserver/ChangeLog: 2020-07-26 Eli Zaretskii <eliz@gnu.org> * configure.ac (AC_CHECK_HEADERS): Add ws2tcpip.h. When checking whether socklen_t type is defined, use ws2tcpip.h if it is available and sys/socket.h isn't. * configure: Regenerate. * config.in: Regenerate.
2020-07-25gdb/fortran: resolve dynamic types when readjusting after an indirectionAndrew Burgess9-19/+233
After dereferencing a pointer (in value_ind) or following a reference (in coerce_ref) we call readjust_indirect_value_type to "fixup" the type of the resulting value object. This fixup handles cases relating to the type of the resulting object being different (a sub-class) of the original pointers target type. If we encounter a pointer to a dynamic type then after dereferencing a pointer (in value_ind) the type of the object created will have had its dynamic type resolved. However, in readjust_indirect_value_type, we use the target type of the original pointer to "fixup" the type of the resulting value. In this case, the target type will be a dynamic type, so the resulting value object, once again has a dynamic type. This then triggers an assertion later within GDB. The solution I propose here is that we call resolve_dynamic_type on the pointer's target type (within readjust_indirect_value_type) so that the resulting value is not converted back to a dynamic type. The test case is based on the original test in the bug report. gdb/ChangeLog: PR fortran/23051 PR fortran/26139 * valops.c (value_ind): Pass address to readjust_indirect_value_type. * value.c (readjust_indirect_value_type): Make parameter non-const, and add extra address parameter. Resolve original type before using it. * value.h (readjust_indirect_value_type): Update function signature and comment. gdb/testsuite/ChangeLog: PR fortran/23051 PR fortran/26139 * gdb.fortran/class-allocatable-array.exp: New file. * gdb.fortran/class-allocatable-array.f90: New file. * gdb.fortran/pointer-to-pointer.exp: New file. * gdb.fortran/pointer-to-pointer.f90: New file.
2020-07-25[gdb/symtab] Ignore zero line table entriesTom de Vries5-2/+217
The DWARF standard states for the line register in the line number information state machine the following: ... An unsigned integer indicating a source line number. Lines are numbered beginning at 1. The compiler may emit the value 0 in cases where an instruction cannot be attributed to any source line. ... So, it's possible to have a zero line number in the DWARF line table. This is currently not handled by GDB. The zero value is read in as any other line number, but internally the zero value has a special meaning: end-of-sequence, so the line table entry ends up having a different interpretation than intended in some situations. I've created a test-case where various aspects are tested, which has these 4 interesting tests. 1. Next-step through a zero-line instruction, is_stmt == 1 gdb.dwarf2/dw2-line-number-zero.exp: bar1, 2nd next 2. Next-step through a zero-line instruction, is_stmt == 0 gdb.dwarf2/dw2-line-number-zero.exp: bar2, 2nd next 3. Show source location at zero-line instruction, is_stmt == 1 gdb.dwarf2/dw2-line-number-zero.exp: continue to breakpoint: bar1_label_3 4. Show source location at zero-line instruction, is_stmt == 0 gdb.dwarf2/dw2-line-number-zero.exp: continue to breakpoint: bar2_label_3 And we have the following results: 8.3.1, 9.2: ... FAIL: gdb.dwarf2/dw2-line-number-zero.exp: bar1, 2nd next PASS: gdb.dwarf2/dw2-line-number-zero.exp: bar2, 2nd next PASS: gdb.dwarf2/dw2-line-number-zero.exp: continue to breakpoint: bar1_label_3 FAIL: gdb.dwarf2/dw2-line-number-zero.exp: continue to breakpoint: bar2_label_3 ... commit 8c95582da8 "gdb: Add support for tracking the DWARF line table is-stmt field": ... PASS: gdb.dwarf2/dw2-line-number-zero.exp: bar1, 2nd next PASS: gdb.dwarf2/dw2-line-number-zero.exp: bar2, 2nd next FAIL: gdb.dwarf2/dw2-line-number-zero.exp: continue to breakpoint: bar1_label_3 FAIL: gdb.dwarf2/dw2-line-number-zero.exp: continue to breakpoint: bar2_label_3 ... commit d8cc8af6a1 "[gdb/symtab] Fix line-table end-of-sequence sorting", master: FAIL: gdb.dwarf2/dw2-line-number-zero.exp: bar1, 2nd next FAIL: gdb.dwarf2/dw2-line-number-zero.exp: bar2, 2nd next PASS: gdb.dwarf2/dw2-line-number-zero.exp: continue to breakpoint: bar1_label_3 PASS: gdb.dwarf2/dw2-line-number-zero.exp: continue to breakpoint: bar2_label_3 ... The regression in test 2 at commit d8cc8af6a1 was filed as PR symtab/26243, where clang emits zero line numbers. The way to fix all tests is to make sure line number zero internally doesn't clash with special meaning values, and by handling it appropriately everywhere. That however looks too intrusive for the GDB 10 release. Instead, we decide to ensure defined behaviour for line number zero by ignoring it. This gives us back the test results from before commit d8cc8af6a1, fixing PR26243. We mark the FAILs for tests 3 and 4 as KFAILs. Test 4 was already failing for the 9.2 release, and we consider the regression of test 3 from gdb 9.2 to gdb 10 the cost for having defined behaviour. Build and reg-tested on x86_64-linux. gdb/ChangeLog: 2020-07-25 Tom de Vries <tdevries@suse.de> PR symtab/26243 * dwarf2/read.c (lnp_state_machine::record_line): Ignore zero line entries. gdb/testsuite/ChangeLog: 2020-07-25 Tom de Vries <tdevries@suse.de> PR symtab/26243 * gdb.dwarf2/dw2-line-number-zero.c: New test. * gdb.dwarf2/dw2-line-number-zero.exp: New file.
2020-07-24config/debuginfod.m4: Use PKG_CHECK_MODULESAaron Merey3-104/+268
Use PKG_CHECK_MODULES to set debuginfod autoconf vars. Also add pkg.m4 to config/. ChangeLog: * config/debuginfod.m4: use PKG_CHECK_MODULES. * config/pkg.m4: New file. * configure: Rebuild. * configure.ac: Remove AC_DEBUGINFOD. ChangeLog/binutils: * Makefile.am: Replace LIBDEBUGINFOD with DEBUGINFOD_LIBS. * Makefile.in: Rebuild. * configure: Rebuild. * doc/Makefile.in: Rebuild. ChangeLog/gdb: * Makefile.in: Replace LIBDEBUGINFOD with DEBUGINFOD_LIBS. * configure: Rebuild.
2020-07-24[gdb/testsuite] Require gnatmake-8 for gdb.ada/mi_prot.expTom de Vries2-0/+8
With gcc-7, I run into: ... gcc -c -I./ -gnata -Isrc/gdb/testsuite/gdb.ada/mi_prot -g -lm -I- \ src/gdb/testsuite/gdb.ada/mi_prot/prot.adb^M prot.adb:21:04: info: "Obj_Type" is frozen here, aspects evaluated at this \ point^M prot.adb:23:09: visibility of aspect for "Obj_Type" changes after freeze \ point^M gnatmake: "src/gdb/testsuite/gdb.ada/mi_prot/prot.adb" compilation error^M compiler exited with status 1 ... FAIL: gdb.ada/mi_prot.exp: compilation prot.adb ... Fix this by requiring gnatmake-8 for this test-case. Tested on x86_64-linux, with gnatmake-7, gnatmake-8 and gnatmake-11. gdb/testsuite/ChangeLog: 2020-07-24 Tom de Vries <tdevries@suse.de> PR testsuite/26293 * gdb.ada/mi_prot.exp: Require gnatmake-8.
2020-07-23Fix BZ 26294 - Add period to help text for maint print core-file-backed-mappingsKevin Buettner2-1/+7
gdb/ChangeLog: PR corefiles/26294 * corelow.c (_initialize_corelow): Add period to help text for "maintenance print core-file-backed-mappings".
2020-07-23Don't touch frame_info objects if frame cache was reinitializedPedro Alves6-29/+144
This fixes yet another bug exposed by ASAN + multi-target.exp Running an Asan-enabled GDB against gdb.multi/multi-target.exp exposed yet another latent GDB bug. See here for the full log: https://sourceware.org/pipermail/gdb-patches/2020-July/170761.html As Simon described, the problem is: - We create a new frame_info object in restore_selected_frame (by calling find_relative_frame) - The frame is allocated on the frame_cache_obstack - In frame_unwind_try_unwinder, we try to find an unwinder for that frame - While trying unwinders, memory read fails because the remote target closes, because of "monitor exit" - That calls reinit_frame_cache (as shown above), which resets frame_cache_obstack - When handling the exception in frame_unwind_try_unwinder, we try to set some things on the frame_info object (like *this_cache, which in fact tries to write into frame_info::prologue_cache), but the frame_info object is no more, it went away with the obstack. Fix this by maintaining a frame cache generation counter. Then in exception handling code paths, don't touch frame objects if the generation is not the same as it was on entry. This commit generalizes the gdb.server/server-kill.exp testcase and reuses it to test the scenario in question. The new tests fail without the GDB fix. gdb/ChangeLog: * frame-unwind.c (frame_unwind_try_unwinder): On exception, don't touch THIS_CACHE/THIS_FRAME if the frame cache was cleared meanwhile. * frame.c (frame_cache_generation, get_frame_cache_generation): New. (reinit_frame_cache): Increment FRAME_CACHE_GENERATION. (get_prev_frame_if_no_cycle): On exception, don't touch PREV_FRAME/THIS_FRAME if the frame cache was cleared meanwhile. * frame.h (get_frame_cache_generation): Declare. gdb/testsuite/ChangeLog: * gdb.server/server-kill.exp (prepare): New, factored out from the top level. (kill_server): New. (test_tstatus, test_unwind_nosyms, test_unwind_syms): New. (top level) : Call test_tstatus, test_unwind_nosyms, test_unwind_syms.
2020-07-23[gdb/tui] Fix Wmaybe-uninitialized warning in tui-winsource.cTom de Vries2-0/+11
When compiling with CFLAGS/CXXFLAGS="-O0 -g -Wall" and using g++ 11.0.0, we run into: ... src/gdb/tui/tui-winsource.c: In function \ 'void tui_update_all_breakpoint_info(breakpoint*)': src/gdb/tui/tui-winsource.c:427:58: warning: '<unknown>' may be used \ uninitialized [-Wmaybe-uninitialized] 427 | for (tui_source_window_base *win : tui_source_windows ()) | ^ In file included from src/gdb/tui/tui-winsource.c:38: src/gdb/tui/tui-winsource.h:236:30: note: by argument 1 of type \ 'const tui_source_windows*' to 'tui_source_window_iterator \ tui_source_windows::begin() const' declared here 236 | tui_source_window_iterator begin () const | ^~~~~ src/gdb/tui/tui-winsource.c:427:58: note: '<anonymous>' declared here 427 | for (tui_source_window_base *win : tui_source_windows ()) | ^ ... The warning doesn't make sense for an empty struct, PR gcc/96295 has been filed about that. For now, work around the warning by defining a default constructor. Build on x86_64-linux. gdb/ChangeLog: 2020-07-23 Tom de Vries <tdevries@suse.de> PR tui/26282 * tui/tui-winsource.h (struct tui_source_windows::tui_source_windows): New default constructor.
2020-07-23gdb/disassembly: Update to handle non-statement addressesAndrew Burgess4-6/+215
After the introduction of support for non-statement addresses in the line table, the output for 'disassemble /m' can be broken in some cases. With the /m format disassembly GDB associates a set of addresses with each line, these addresses are then sorted and printed for each line. When the non-statement support was added GDB was incorrectly told to ignore non-statement instructions, and not add these to the result table. This means that these instructions are completely missing from the output. This commit removes the code that caused non-statement lines to be ignored. A result of this change is that GDB will now potentially include new line numbers in the 'disassemble /m' output, lines that previously were only in the line table as non-statement lines will now appear in the disassembly output. This feels like an improvement though. gdb/ChangeLog: * disasm.c (do_mixed_source_and_assembly_deprecated): Don't exclude non-statement entries. gdb/testsuite/ChangeLog: * gdb.dwarf2/dw2-disasm-over-non-stmt.exp: New file.
2020-07-22Fix more bugs in gdb testglue wrapper handlingSandra Loosemore2-12/+22
In commit 24ac169ac5a918cd82b7485935f0c40a094c625e, this patch: 2020-02-21 Shahab Vahedi <shahab@synopsys.com> * lib/gdb.exp (gdb_wrapper_init): Reset "gdb_wrapper_initialized" to 0 if "wrapper_file" does not exist. attempted to fix problems finding the gdb test wrapper gdb_tg.o in some tests that cd to some non-default directory by rebuilding also the test wrapper in that directory. This had the side-effect of leaving these .o files in various places in the GDB source directory tree. Furthermore, while the tests that cd to some non-default directory cannot run on remote host, the code that was added to probe for the presence of the wrapper file was also specific to host == build. This patch reverts the problematic parts of that commit and replaces it with forcing use of an absolute (rather than relative) pathname to the .o file for linking when host == build. While debugging this patch, I also observed that use of the construct "[info exists gdb_wrapper_file]" was not reliable for detecting when that variable had been initialized by gdb_wrapper_init. I rewrote that so that the variable is always initialized and has a value of an empty string when no wrapper file is needed. 2020-07-22 Sandra Loosemore <sandra@codesourcery.com> gdb/testsuite/ * lib/gdb.exp (gdb_wrapper_file, gdb_wrapper_flags): Initialize to empty string at top level. (gdb_wrapper_init): Revert check for file existence on build. Build the wrapper in its default place, not a build-specific location. When host == build, make the pathname absolute. (gdb_compile): Delete leftover declaration of gdb_wrapper_initialized. Check gdb_wrapper_file being an empty string instead of uninitialized.
generated by cgit v1.1 at 2025-02-25 13:13:58 +0000