summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* x86: drop vex_scalar_w_dq_modeJan Beulich2021-07-223-51/+41
| | | | | | It has only a single use and can easily be represented by dq_mode instead. Plus its handling in intel_operand_size() was duplicating that of vex_vsib_{d,q}_w_dq_mode anyway.
* x86: drop xmm_m{b,w,d,q}_modeJan Beulich2021-07-224-164/+91
| | | | They're effectively redundant with {b,w,d,q}_mode.
* x86: fold duplicate vector register printing codeJan Beulich2021-07-221-74/+33
| | | | | | The bulk of OP_XMM() can be easily reused also for OP_EX(). Break the shared logic out of the function, and invoke the new helper from both places.
* x86: drop vex_mode and vex_scalar_modeJan Beulich2021-07-221-11/+7
| | | | These are fully redundant with, respectively, x_mode and scalar_mode.
* x86: correct EVEX.V' handling outside of 64-bit modeJan Beulich2021-07-222-6/+18
| | | | | | | Unlike the high bit of VEX.vvvv / EVEX.vvvv, EVEX.V' is not ignored outside of 64-bit mode. Oddly enough there already are tests for these cases, but their expectations were wrong. (This may have been based on an old SDM version, where the restriction wasn't properly spelled out.)
* x86: fold duplicate code in MOVSXD_Fixup()Jan Beulich2021-07-221-16/+10
| | | | There's no need to have two paths printing the "xd" mnemonic suffix.
* x86: fold duplicate register printing codeJan Beulich2021-07-221-105/+14
| | | | | | | | What so far was OP_E_register() can be easily reused also for OP_G(). Add suitable parameters to the function and move the invocation of swap_operand() to OP_E(). Adjust MOVSXD's first operand: There never was a need to use movsxd_mode there, and its use gets in the way of the code folding.
* x86-64: properly bounds-check %bnd<N> in OP_G()Jan Beulich2021-07-223-1/+17
| | | | | The restriction to %bnd0-%bnd3 requires to also check REX.R is clear, just like OP_E_Register() also includes REX.B in its check.
* x86-64: generalize OP_G()'s EVEX.R' handlingJan Beulich2021-07-224-1/+14
| | | | | EVEX.R' is invalid to be clear not only for mask registers, but also for GPRs - IOW everything handled in this function.
* x86: correct VCVT{,U}SI2SD rounding mode handlingJan Beulich2021-07-227-16/+31
| | | | | | | | | | With EVEX.W clear the instruction doesn't ignore the rounding mode, but (like for other insns without rounding semantics) EVEX.b set causes #UD. Hence the handling of EVEX.W needs to be done when processing evex_rounding_64_mode, not at the decode stages. Derive a new 64-bit testcase from the 32-bit one to cover the different EVEX.W treatment in both cases.
* x86: drop OP_Mask()Jan Beulich2021-07-224-48/+28
| | | | By moving its vex.r check there it becomes fully redundant with OP_G().
* Automatic date update in version.inGDB Administrator2021-07-221-1/+1
|
* [gdb/testsuite] Fix gdb.cp/step-and-next-inline.exp with gcc-11Tom de Vries2021-07-213-13/+84
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When running test-case gdb.cp/step-and-next-inline.exp with gcc-11, I run into: ... KPASS: gdb.cp/step-and-next-inline.exp: no_header: next step 1 \ (PRMS symtab/25507) FAIL: gdb.cp/step-and-next-inline.exp: no_header: next step 2 KPASS: gdb.cp/step-and-next-inline.exp: no_header: next step 3 \ (PRMS symtab/25507) ... [ Note that I get the same result with gcc-11 and target board unix/gdb:debug_flags=-gdwarf-4, so this is not a dwarf 4 vs 5 issue. ] With gcc-10, I have this trace: ... 64 get_alias_set (&xx); get_alias_set (t=0x601038 <xx>) at step-and-next-inline.cc:51 51 if (t != NULL 40 if (t->x != i) 52 && TREE_TYPE (t).z != 1 43 return x; 53 && TREE_TYPE (t).z != 2 43 return x; 54 && TREE_TYPE (t).z != 3) 43 return x; main () at step-and-next-inline.cc:65 65 return 0; ... and with gcc-11, I have instead: ... 64 get_alias_set (&xx); get_alias_set (t=0x601038 <xx>) at step-and-next-inline.cc:51 51 if (t != NULL 52 && TREE_TYPE (t).z != 1 43 return x; 53 && TREE_TYPE (t).z != 2 43 return x; 54 && TREE_TYPE (t).z != 3) 43 return x; main () at step-and-next-inline.cc:65 65 return 0; ... and with clang-10, I have instead: ... 64 get_alias_set (&xx); get_alias_set (t=0x601034 <xx>) at step-and-next-inline.cc:51 51 if (t != NULL 52 && TREE_TYPE (t).z != 1 53 && TREE_TYPE (t).z != 2 54 && TREE_TYPE (t).z != 3) 51 if (t != NULL 57 } main () at step-and-next-inline.cc:65 65 return 0; ... The test-case tries to verify that we don't step into inlined function tree_check (lines 40-43) (so, with the clang trace we get that right). The test-case then tries to kfail the problems when using gcc, but this is done in such a way that the testing still gets out of sync after a failure. That is: the "next step 2" check that is supposed to match "TREE_TYPE (t).z != 2" is actually matching "TREE_TYPE (t).z != 1": ... (gdb) next^M 52 && TREE_TYPE (t).z != 1^M (gdb) PASS: gdb.cp/step-and-next-inline.exp: no_header: next step 2 ... Fix this by issuing extra nexts to arrive at the required lines. Tested on x86_64-linux, with gcc-8, gcc-9, gcc-10, gcc-11, clang-8, clang-10 and clang-12. gdb/testsuite/ChangeLog: 2021-07-20 Tom de Vries <tdevries@suse.de> * gdb.cp/step-and-next-inline.cc (tree_check, get_alias_set, main): Tag closing brace with comment. * gdb.cp/step-and-next-inline.h: Update to keep identical with step-and-next-inline.cc. * gdb.cp/step-and-next-inline.exp: Issue extra next when required.
* Updated Russian translation for the bfd libraryNick Clifton2021-07-211-1840/+2056
|
* Allows linker scripts to set the SEC_READONLY flag.Luca Boccassi2021-07-218-1/+34
| | | | | | | | | | | * ld.texi: Document new output section type. * ldgram.y: Add new token. * ldlang.c: Handle the new flag. * ldlang.h: Add readonly_section to list of section types. * ldlex.l: Add a new identifier. * testsuite/ld-scripts/output-section-types.t: New example linker script. * testsuite/ld-scripts/output-section-types.d: Test driver. * testsyute/ld-scripts/script.exp: Run the new test.
* [gdb/testsuite] Fix FAILs due to PR gcc/101452Tom de Vries2021-07-216-4/+52
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When running test-case gdb.base/ptype-offsets.exp with gcc-11 (with -gdwarf-5 default) or gcc-10 with target board unix/gdb:debug_flags=-gdwarf-5 we run into this regression: ... (gdb) ptype/o static_member^M /* offset | size */ type = struct static_member {^M - static static_member Empty;^M /* 0 | 4 */ int abc;^M ^M /* total size (bytes): 4 */^M }^M -(gdb) PASS: gdb.base/ptype-offsets.exp: ptype/o static_member +(gdb) FAIL: gdb.base/ptype-offsets.exp: ptype/o static_member ... This is caused by missing debug info, which I filed as gcc PR101452 - "[debug, dwarf-5] undefined static member removed by -feliminate-unused-debug-symbols". It's not clear yet whether this is a bug or a feature, but work around this in the test-cases by: - defining the static member - adding additional_flags=-fno-eliminate-unused-debug-types. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2021-07-20 Tom de Vries <tdevries@suse.de> * lib/gdb.exp (gcc_major_version): New proc. * gdb.base/ptype-offsets.cc: Define static member static_member::Empty. * gdb.cp/templates.exp: Define static member using -DGCC_BUG. * gdb.cp/m-static.exp: Add additional_flags=-fno-eliminate-unused-debug-types. * gdb.cp/pr-574.exp: Same. * gdb.cp/pr9167.exp: Same.
* [gdb/testsuite] Add KFAILs for gdb.ada FAILs with gcc-11Tom de Vries2021-07-213-22/+127
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With gcc-11 we run into: ... (gdb) print pa_ptr.all^M That operation is not available on integers of more than 8 bytes.^M (gdb) KFAIL: gdb.ada/arrayptr.exp: scenario=all: print pa_ptr.all (PRMS: gdb/20991) ... This is due to PR exp/20991 - "__int128 type support". Mark this and similar FAILs as KFAIL. Also mark this FAIL: .... (gdb) print pa_ptr(3)^M cannot subscript or call something of type `foo__packed_array_ptr'^M (gdb) FAIL: gdb.ada/arrayptr.exp: scenario=minimal: print pa_ptr(3) ... as a KFAIL for PR ada/28115 - "Support packed array encoded as DW_TAG_subrange_type". Tested on x86_64-linux, with gcc-10 and gcc-11. gdb/testsuite/ChangeLog: 2021-07-21 Tom de Vries <tdevries@suse.de> * gdb.ada/arrayptr.exp: Add KFAILs for PR20991 and PR28115. * gdb.ada/exprs.exp: Add KFAILs for PR20991. * gdb.ada/packed_array_assign.exp: Same.
* as_bad_subtractAlan Modra2021-07-2133-149/+121
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Many places report errors of the nature "can't resolve a - b". This provides a utility function to report such errors consistently. I removed the section reporting and quotes around symbol names while I was at it. Compare ifunc-2.s:4: Error: can't resolve `bar1' {.text.1 section} - `foo1' {.text.1 section} with ifunc-2.s:4: Error: can't resolve bar1 - foo1 In many cases the section names don't help the user very much in figuring out what went wrong, and the quotes if present arguably ought to be placed around the entire expression: can't resolve `bar1 - foo1' The patch also tidies some tc_get_reloc functions that leak memory on error paths. * write.h (as_bad_subtract): Declare. * write.c (as_bad_subtract): New function. (fixup_segment): Use as_bad_subtract. * config/tc-arc.c (md_apply_fix): Likewise. * config/tc-avr.c (md_apply_fix, tc_gen_reloc): Likewise. * config/tc-cris.c (md_apply_fix): Likewise. * config/tc-d10v.c (md_apply_fix): Likewise. * config/tc-d30v.c (md_apply_fix): Likewise. * config/tc-ft32.c (md_apply_fix): Likewise. * config/tc-h8300.c (tc_gen_reloc): Likewise. * config/tc-m68hc11.c (md_apply_fix): Likewise. * config/tc-mmix.c (mmix_frob_file): Likewise. * config/tc-mn10200.c (tc_gen_reloc): Likewise. * config/tc-nds32.c (nds32_apply_fix): Likewise. * config/tc-pru.c (md_apply_fix): Likewise. * config/tc-riscv.c (md_apply_fix): Likewise. * config/tc-s12z.c (md_apply_fix): Likewise. * config/tc-s390.c (md_apply_fix): Likewise. * config/tc-tilegx.c (md_apply_fix): Likewise. * config/tc-tilepro.c (md_apply_fix): Likewise. * config/tc-v850.c (md_apply_fix): Likewise. * config/tc-vax.c (md_apply_fix): Likewise. * config/tc-xc16x.c (tc_gen_reloc): Likewise. * config/tc-xgate.c (md_apply_fix): Likewise. * config/tc-xstormy16.c (xstormy16_md_apply_fix): Likewise. * config/tc-xtensa.c (md_apply_fix): Likewise. * config/tc-z80.c (tc_gen_reloc): Likewise. * config/tc-spu.c (md_apply_fix): Likewise. (tc_gen_reloc): Delete dead code. Free memory on error. * config/tc-cr16.c (tc_gen_reloc): Use as_bad_subtract. Free on error. * config/tc-crx.c (tc_gen_reloc): Likewise. * config/tc-ppc.c (tc_gen_reloc): Likewise. * testsuite/gas/i386/ifunc-2.l: Adjust to suit changed error message. * testsuite/gas/mips/lui-2.l: Likewise. * testsuite/gas/tic6x/reloc-bad-1.l: Likewise.
* Remove `netbsdpe` supportJohn Ericson2021-07-218-13/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | netbsdpe was deprecated in c2ce831330e10dab4703094491f80b6b9a5c2289. Since then, a release has passed (2.37), and it was marked obselete in 5c9cbf07f3f972ecffe13d858010b3179df17b32. Unless I am mistaken, that means we can now remove support altogether. All branches in the "active" code are remove, and the target is additionally marked as obsolete next to the other removed ones for libbfd and gdb. Per [1] from the NetBSD toolchain list, PE/COFF support was removed a decade ago. Furthermore, the sole mention of this target in the binutils commit history was in 2002. Together, I'm led to believe this target hasn't seen much attention in quite a while. [1]: https://mail-index.netbsd.org/tech-toolchain/2021/06/16/msg003996.html bfd/ * config.bfd: Remove netbsdpe entry. binutils/ * configure.ac: Remove netbsdpe entry. * testsuite/lib/binutils-common.exp (is_pecoff_format): Likewise. * configure: Regenerate. gas/ * configure.tgt: Remove netbsdpe entry. gdb/ * configure.tgt: Add netbsdpe to removed targets. ld/ * configure.tgt: Remove netbsdpe entry. * testsuite/ld-bootstrap/bootstrap.exp: Likewise.
* Automatic date update in version.inGDB Administrator2021-07-211-1/+1
|
* PR28106, build of 2.37 fails on FreeBSD and ClangAlan Modra2021-07-202-2/+8
| | | | | | | | | | | https://en.cppreference.com/w/cpp/types/NULL says NULL might be defined as nullptr. https://en.cppreference.com/w/cpp/language/reinterpret_cast says reinterpret_cast can't be used on nullptr. PR gold/28106 PR gold/27815 * gc.h (gc_process_relocs): Use static_cast in Section_id constructor.
* Fix printing of non-address types when memory tagging is enabledLuis Machado2021-07-203-31/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When the architecture supports memory tagging, we handle pointer/reference types in a special way, so we can validate tags and show mismatches. Unfortunately, the currently implementation errors out when the user prints non-address values: composite types, floats, references, member functions and other things. Vector registers: (gdb) p $v0 Value can't be converted to integer. Non-existent internal variables: (gdb) p $foo Value can't be converted to integer. The same happens for complex types and printing struct/union types. There are a few problems here. The first one is that after print_command_1 evaluates the expression to print, the tag validation code call value_as_address unconditionally, without making sure we have have a suitable type where it makes to sense to call it. That results in value_as_address (if it isn't given a pointer-like type) trying to treat the value as an integer and convert it to an address, which #1 - doesn't make sense (i.e., no sense in validating tags after "print 1"), and throws for non-integer-convertible types. We fix this by making sure we have a pointer or reference type first, and only if so then proceed to check if the address-like value has tags. The second is that we're calling value_as_address even if we have an optimized out or unavailable value, which throws, because the value's contents aren't fully accessible/readable. This error currently escapes out and aborts the print. This case is fixed by checking for optimized out / unavailable explicitly. Third, the tag checking process does not gracefully handle exceptions. If any exception is thrown from the tag validation code, we abort the print. E.g., the target may fail to access tags via a running thread. Or the needed /proc files aren't available. Or some other untold reason. This is a bit too rigid. This commit changes print_command_1 to catch errors, print them, and still continue with the normal expression printing path instead of erroring out and printing nothing useful. With this patch, printing works correctly again: (gdb) p $v0 $1 = {d = {f = {2.0546950501119882e-81, 2.0546950501119882e-81}, u = {3399988123389603631, 3399988123389603631}, s = { 3399988123389603631, 3399988123389603631}}, s = {f = {1.59329203e-10, 1.59329203e-10, 1.59329203e-10, 1.59329203e-10}, u = { 791621423, 791621423, 791621423, 791621423}, s = {791621423, 791621423, 791621423, 791621423}}, h = {bf = {1.592e-10, 1.592e-10, 1.592e-10, 1.592e-10, 1.592e-10, 1.592e-10, 1.592e-10, 1.592e-10}, f = {0.11224, 0.11224, 0.11224, 0.11224, 0.11224, 0.11224, 0.11224, 0.11224}, u = {12079, 12079, 12079, 12079, 12079, 12079, 12079, 12079}, s = {12079, 12079, 12079, 12079, 12079, 12079, 12079, 12079}}, b = {u = {47 <repeats 16 times>}, s = {47 <repeats 16 times>}}, q = {u = { 62718710765820030520700417840365121327}, s = {62718710765820030520700417840365121327}}} (gdb) p $foo $2 = void (gdb) p 2 + 2i $3 = 2 + 2i Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28110
* RISC-V: Minor updates for architecture parser.Nelson Chu2021-07-203-96/+84
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * Two add subset functions is redundant. Keep the riscv_add_implicit_subset, and renamed it to riscv_add_subset. Besides, if the subset is added in order, then we just add it at the tail of the subset list. * Removed the "-march:" prefix from the error messages. Since not only the -march= option will use the parser, but also the architecture elf attributes, the default architecture setting and linker will use the same parser. * Use a function, riscv_parse_check_conflicts, to check the conflicts of extensions, including the rv64e and rv32q. The rv32emc-elf/rv32i-elf/rv32gc-linux/rv64gc-elf/rv64gc-linux regressions are tested and passed. bfd/ * elfxx-riscv.c (riscv_lookup_subset): Check the subset tail list first. If the subset is added in order, then we can just add it to the tail without searching the whole list. (riscv_add_subset): Replaced by riscv_add_implicit_subset. (riscv_add_implicit_subset): Renamed to riscv_add_subset. (riscv_parse_add_subset): Updated. (riscv_parsing_subset_version): Removed the "-march:" prefix from the error message. (riscv_parse_prefixed_ext): Likewise. (riscv_parse_std_ext): Likewise. And move the rv<xlen>e check to riscv_parse_check_conflicts. (riscv_parse_check_conflicts): New function used to check conflicts. (riscv_parse_subset): Updated. gas/ * testsuite/gas/riscv/march-fail-base-02.l: Updated. * testsuite/gas/riscv/march-fail-unknown-std.l: Likewise.
* Automatic date update in version.inGDB Administrator2021-07-201-1/+1
|
* gdb: set current thread in btrace_compute_ftrace_{bts,pt}Simon Marchi2021-07-191-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As documented in bug 28086, test gdb.btrace/enable-new-thread.exp started failing with commit 0618ae414979 ("gdb: optimize all_matching_threads_iterator"): (gdb) record btrace^M (gdb) PASS: gdb.btrace/enable-new-thread.exp: record btrace break 24^M Breakpoint 2 at 0x555555555175: file /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.btrace/enable-new-thread.c, line 24.^M (gdb) continue^M Continuing.^M /home/smarchi/src/binutils-gdb/gdb/inferior.c:303: internal-error: inferior* find_inferior_pid(process_stratum_target*, int): Assertion `pid != 0' failed.^M A problem internal to GDB has been detected,^M further debugging may prove unreliable.^M Quit this debugging session? (y or n) FAIL: gdb.btrace/enable-new-thread.exp: continue to breakpoint: cont to bp.1 (GDB internal error) Note that I only see the failure if GDB is compiled without libipt support. This is because GDB then makes use BTS instead of PT, so exercises different code paths. I think that the commit above just exposed an existing problem. The stack trace of the internal error is: #8 0x0000561cb81e404e in internal_error (file=0x561cb83aa2f8 "/home/smarchi/src/binutils-gdb/gdb/inferior.c", line=303, fmt=0x561cb83aa099 "%s: Assertion `%s' failed.") at /home/smarchi/src/binutils-gdb/gdbsupport/errors.cc:55 #9 0x0000561cb7b5c031 in find_inferior_pid (targ=0x561cb8aafb60 <the_amd64_linux_nat_target>, pid=0) at /home/smarchi/src/binutils-gdb/gdb/inferior.c:303 #10 0x0000561cb7b5c102 in find_inferior_ptid (targ=0x561cb8aafb60 <the_amd64_linux_nat_target>, ptid=...) at /home/smarchi/src/binutils-gdb/gdb/inferior.c:317 #11 0x0000561cb7f1d1c3 in find_thread_ptid (targ=0x561cb8aafb60 <the_amd64_linux_nat_target>, ptid=...) at /home/smarchi/src/binutils-gdb/gdb/thread.c:487 #12 0x0000561cb7f1b921 in all_matching_threads_iterator::all_matching_threads_iterator (this=0x7ffc4ee34678, filter_target=0x561cb8aafb60 <the_amd64_linux_nat_target>, filter_ptid=...) at /home/smarchi/src/binutils-gdb/gdb/thread-iter.c:125 #13 0x0000561cb77bc462 in filtered_iterator<all_matching_threads_iterator, non_exited_thread_filter>::filtered_iterator<process_stratum_target* const&, ptid_t const&> (this=0x7ffc4ee34670) at /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/filtered-iterator.h:42 #14 0x0000561cb77b97cb in all_non_exited_threads_range::begin (this=0x7ffc4ee34650) at /home/smarchi/src/binutils-gdb/gdb/thread-iter.h:243 #15 0x0000561cb7d8ba30 in record_btrace_target::record_is_replaying (this=0x561cb8aa6250 <record_btrace_ops>, ptid=...) at /home/smarchi/src/binutils-gdb/gdb/record-btrace.c:1411 #16 0x0000561cb7d8bb83 in record_btrace_target::xfer_partial (this=0x561cb8aa6250 <record_btrace_ops>, object=TARGET_OBJECT_MEMORY, annex=0x0, readbuf=0x7ffc4ee34c58 "\260g\343N\374\177", writebuf=0x0, offset=140737352774277, len=1, xfered_len=0x7ffc4ee34ad8) at /home/smarchi/src/binutils-gdb/gdb/record-btrace.c:1437 #17 0x0000561cb7ef73a9 in raw_memory_xfer_partial (ops=0x561cb8aa6250 <record_btrace_ops>, readbuf=0x7ffc4ee34c58 "\260g\343N\374\177", writebuf=0x0, memaddr=140737352774277, len=1, xfered_len=0x7ffc4ee34ad8) at /home/smarchi/src/binutils-gdb/gdb/target.c:1504 #18 0x0000561cb7ef77da in memory_xfer_partial_1 (ops=0x561cb8aa6250 <record_btrace_ops>, object=TARGET_OBJECT_CODE_MEMORY, readbuf=0x7ffc4ee34c58 "\260g\343N\374\177", writebuf=0x0, memaddr=140737352774277, len=1, xfered_len=0x7ffc4ee34ad8) at /home/smarchi/src/binutils-gdb/gdb/target.c:1635 #19 0x0000561cb7ef78b5 in memory_xfer_partial (ops=0x561cb8aa6250 <record_btrace_ops>, object=TARGET_OBJECT_CODE_MEMORY, readbuf=0x7ffc4ee34c58 "\260g\343N\374\177", writebuf=0x0, memaddr=140737352774277, len=1, xfered_len=0x7ffc4ee34ad8) at /home/smarchi/src/binutils-gdb/gdb/target.c:1664 #20 0x0000561cb7ef7ba4 in target_xfer_partial (ops=0x561cb8aa6250 <record_btrace_ops>, object=TARGET_OBJECT_CODE_MEMORY, annex=0x0, readbuf=0x7ffc4ee34c58 "\260g\343N\374\177", writebuf=0x0, offset=140737352774277, len=1, xfered_len=0x7ffc4ee34ad8) at /home/smarchi/src/binutils-gdb/gdb/target.c:1721 #21 0x0000561cb7ef8503 in target_read_partial (ops=0x561cb8aa6250 <record_btrace_ops>, object=TARGET_OBJECT_CODE_MEMORY, annex=0x0, buf=0x7ffc4ee34c58 "\260g\343N\374\177", offset=140737352774277, len=1, xfered_len=0x7ffc4ee34ad8) at /home/smarchi/src/binutils-gdb/gdb/target.c:1974 #22 0x0000561cb7ef861f in target_read (ops=0x561cb8aa6250 <record_btrace_ops>, object=TARGET_OBJECT_CODE_MEMORY, annex=0x0, buf=0x7ffc4ee34c58 "\260g\343N\374\177", offset=140737352774277, len=1) at /home/smarchi/src/binutils-gdb/gdb/target.c:2014 #23 0x0000561cb7ef809f in target_read_code (memaddr=140737352774277, myaddr=0x7ffc4ee34c58 "\260g\343N\374\177", len=1) at /home/smarchi/src/binutils-gdb/gdb/target.c:1869 #24 0x0000561cb7937f4d in gdb_disassembler::dis_asm_read_memory (memaddr=140737352774277, myaddr=0x7ffc4ee34c58 "\260g\343N\374\177", len=1, info=0x7ffc4ee34e88) at /home/smarchi/src/binutils-gdb/gdb/disasm.c:139 #25 0x0000561cb80ab66d in fetch_data (info=0x7ffc4ee34e88, addr=0x7ffc4ee34c59 "g\343N\374\177") at /home/smarchi/src/binutils-gdb/opcodes/i386-dis.c:194 #26 0x0000561cb80ab7e2 in ckprefix () at /home/smarchi/src/binutils-gdb/opcodes/i386-dis.c:8628 #27 0x0000561cb80adbd8 in print_insn (pc=140737352774277, info=0x7ffc4ee34e88) at /home/smarchi/src/binutils-gdb/opcodes/i386-dis.c:9587 #28 0x0000561cb80abe4f in print_insn_i386 (pc=140737352774277, info=0x7ffc4ee34e88) at /home/smarchi/src/binutils-gdb/opcodes/i386-dis.c:8894 #29 0x0000561cb7744a19 in default_print_insn (memaddr=140737352774277, info=0x7ffc4ee34e88) at /home/smarchi/src/binutils-gdb/gdb/arch-utils.c:1029 #30 0x0000561cb7b33067 in i386_print_insn (pc=140737352774277, info=0x7ffc4ee34e88) at /home/smarchi/src/binutils-gdb/gdb/i386-tdep.c:4013 #31 0x0000561cb7acd8f4 in gdbarch_print_insn (gdbarch=0x561cbae2fb60, vma=140737352774277, info=0x7ffc4ee34e88) at /home/smarchi/src/binutils-gdb/gdb/gdbarch.c:3478 #32 0x0000561cb793a32d in gdb_disassembler::print_insn (this=0x7ffc4ee34e80, memaddr=140737352774277, branch_delay_insns=0x0) at /home/smarchi/src/binutils-gdb/gdb/disasm.c:795 #33 0x0000561cb793a5b0 in gdb_print_insn (gdbarch=0x561cbae2fb60, memaddr=140737352774277, stream=0x561cb8ac99f8 <null_stream>, branch_delay_insns=0x0) at /home/smarchi/src/binutils-gdb/gdb/disasm.c:850 #34 0x0000561cb793a631 in gdb_insn_length (gdbarch=0x561cbae2fb60, addr=140737352774277) at /home/smarchi/src/binutils-gdb/gdb/disasm.c:859 #35 0x0000561cb77f53f4 in btrace_compute_ftrace_bts (tp=0x561cbba11210, btrace=0x7ffc4ee35188, gaps=...) at /home/smarchi/src/binutils-gdb/gdb/btrace.c:1107 #36 0x0000561cb77f55f5 in btrace_compute_ftrace_1 (tp=0x561cbba11210, btrace=0x7ffc4ee35180, cpu=0x0, gaps=...) at /home/smarchi/src/binutils-gdb/gdb/btrace.c:1527 #37 0x0000561cb77f5705 in btrace_compute_ftrace (tp=0x561cbba11210, btrace=0x7ffc4ee35180, cpu=0x0) at /home/smarchi/src/binutils-gdb/gdb/btrace.c:1560 #38 0x0000561cb77f583b in btrace_add_pc (tp=0x561cbba11210) at /home/smarchi/src/binutils-gdb/gdb/btrace.c:1589 #39 0x0000561cb77f5a86 in btrace_enable (tp=0x561cbba11210, conf=0x561cb8ac6878 <record_btrace_conf>) at /home/smarchi/src/binutils-gdb/gdb/btrace.c:1629 #40 0x0000561cb7d88d26 in record_btrace_enable_warn (tp=0x561cbba11210) at /home/smarchi/src/binutils-gdb/gdb/record-btrace.c:294 #41 0x0000561cb7c603dc in std::__invoke_impl<void, void (*&)(thread_info*), thread_info*> (__f=@0x561cbb6c4878: 0x561cb7d88cdc <record_btrace_enable_warn(thread_info*)>) at /usr/include/c++/10/bits/invoke.h:60 #42 0x0000561cb7c5e5a6 in std::__invoke_r<void, void (*&)(thread_info*), thread_info*> (__fn=@0x561cbb6c4878: 0x561cb7d88cdc <record_btrace_enable_warn(thread_info*)>) at /usr/include/c++/10/bits/invoke.h:153 #43 0x0000561cb7c5dc92 in std::_Function_handler<void (thread_info*), void (*)(thread_info*)>::_M_invoke(std::_Any_data const&, thread_info*&&) (__functor=..., __args#0=@0x7ffc4ee35310: 0x561cbba11210) at /usr/include/c++/10/bits/std_function.h:291 #44 0x0000561cb7f2600f in std::function<void (thread_info*)>::operator()(thread_info*) const (this=0x561cbb6c4878, __args#0=0x561cbba11210) at /usr/include/c++/10/bits/std_function.h:622 #45 0x0000561cb7f23dc8 in gdb::observers::observable<thread_info*>::notify (this=0x561cb8ac5aa0 <gdb::observers::new_thread>, args#0=0x561cbba11210) at /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/observable.h:150 #46 0x0000561cb7f1c436 in add_thread_silent (targ=0x561cb8aafb60 <the_amd64_linux_nat_target>, ptid=...) at /home/smarchi/src/binutils-gdb/gdb/thread.c:263 #47 0x0000561cb7f1c479 in add_thread_with_info (targ=0x561cb8aafb60 <the_amd64_linux_nat_target>, ptid=..., priv=0x561cbb3f7ab0) at /home/smarchi/src/binutils-gdb/gdb/thread.c:272 #48 0x0000561cb7bfa1d0 in record_thread (info=0x561cbb0413a0, tp=0x0, ptid=..., th_p=0x7ffc4ee35610, ti_p=0x7ffc4ee35620) at /home/smarchi/src/binutils-gdb/gdb/linux-thread-db.c:1380 #49 0x0000561cb7bf7a2a in thread_from_lwp (stopped=0x561cba81db20, ptid=...) at /home/smarchi/src/binutils-gdb/gdb/linux-thread-db.c:429 #50 0x0000561cb7bf7ac5 in thread_db_notice_clone (parent=..., child=...) at /home/smarchi/src/binutils-gdb/gdb/linux-thread-db.c:447 #51 0x0000561cb7bdc9a2 in linux_handle_extended_wait (lp=0x561cbae25720, status=4991) at /home/smarchi/src/binutils-gdb/gdb/linux-nat.c:1981 #52 0x0000561cb7bdf0f3 in linux_nat_filter_event (lwpid=435403, status=198015) at /home/smarchi/src/binutils-gdb/gdb/linux-nat.c:2920 #53 0x0000561cb7bdfed6 in linux_nat_wait_1 (ptid=..., ourstatus=0x7ffc4ee36398, target_options=...) at /home/smarchi/src/binutils-gdb/gdb/linux-nat.c:3202 #54 0x0000561cb7be0b68 in linux_nat_target::wait (this=0x561cb8aafb60 <the_amd64_linux_nat_target>, ptid=..., ourstatus=0x7ffc4ee36398, target_options=...) at /home/smarchi/src/binutils-gdb/gdb/linux-nat.c:3440 #55 0x0000561cb7bfa2fc in thread_db_target::wait (this=0x561cb8a9acd0 <the_thread_db_target>, ptid=..., ourstatus=0x7ffc4ee36398, options=...) at /home/smarchi/src/binutils-gdb/gdb/linux-thread-db.c:1412 #56 0x0000561cb7d8e356 in record_btrace_target::wait (this=0x561cb8aa6250 <record_btrace_ops>, ptid=..., status=0x7ffc4ee36398, options=...) at /home/smarchi/src/binutils-gdb/gdb/record-btrace.c:2547 #57 0x0000561cb7ef996d in target_wait (ptid=..., status=0x7ffc4ee36398, options=...) at /home/smarchi/src/binutils-gdb/gdb/target.c:2608 #58 0x0000561cb7b6d297 in do_target_wait_1 (inf=0x561cba6d8780, ptid=..., status=0x7ffc4ee36398, options=...) at /home/smarchi/src/binutils-gdb/gdb/infrun.c:3640 #59 0x0000561cb7b6d43e in operator() (__closure=0x7ffc4ee36190, inf=0x561cba6d8780) at /home/smarchi/src/binutils-gdb/gdb/infrun.c:3701 #60 0x0000561cb7b6d7b2 in do_target_wait (ecs=0x7ffc4ee36370, options=...) at /home/smarchi/src/binutils-gdb/gdb/infrun.c:3720 #61 0x0000561cb7b6e67d in fetch_inferior_event () at /home/smarchi/src/binutils-gdb/gdb/infrun.c:4069 #62 0x0000561cb7b4659b in inferior_event_handler (event_type=INF_REG_EVENT) at /home/smarchi/src/binutils-gdb/gdb/inf-loop.c:41 #63 0x0000561cb7be25f7 in handle_target_event (error=0, client_data=0x0) at /home/smarchi/src/binutils-gdb/gdb/linux-nat.c:4227 #64 0x0000561cb81e4ee2 in handle_file_event (file_ptr=0x561cbae24e10, ready_mask=1) at /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:575 #65 0x0000561cb81e5490 in gdb_wait_for_event (block=0) at /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:701 #66 0x0000561cb81e41be in gdb_do_one_event () at /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:212 #67 0x0000561cb7c18096 in start_event_loop () at /home/smarchi/src/binutils-gdb/gdb/main.c:421 #68 0x0000561cb7c181e0 in captured_command_loop () at /home/smarchi/src/binutils-gdb/gdb/main.c:481 #69 0x0000561cb7c19d7e in captured_main (data=0x7ffc4ee366a0) at /home/smarchi/src/binutils-gdb/gdb/main.c:1353 #70 0x0000561cb7c19df0 in gdb_main (args=0x7ffc4ee366a0) at /home/smarchi/src/binutils-gdb/gdb/main.c:1368 #71 0x0000561cb7693186 in main (argc=11, argv=0x7ffc4ee367b8) at /home/smarchi/src/binutils-gdb/gdb/gdb.c:32 At frame 45, the new_thread observable is fired. At this moment, the new thread isn't the current thread, inferior_ptid is null_ptid. I think this is ok: the new_thread observable doesn't give any guarantee on the global context when observers are invoked. Frame 35, btrace_compute_ftrace_bts, calls gdb_insn_length. gdb_insn_length doesn't have a thread_info or other parameter what could indicate where to read memory from, it implicitly uses the global context (inferior_ptid). So we reach the all_non_exited_threads_range in record_btrace_target::record_is_replaying with a null inferior_ptid. The previous implemention of all_non_exited_threads_range didn't care, but the new one does. The problem of calling gdb_insn_length and ultimately trying to read memory with a null inferior_ptid already existed, but the commit mentioned above made it visible. Something between frames 40 (record_btrace_enable_warn) and 35 (btrace_compute_ftrace_bts) needs to be switching the global context to make TP the current thread. Since btrace_compute_ftrace_bts takes the thread_info to work with as a parameter, that typically means that it doesn't require its caller to also set the global current context (current thread) when calling. If it needs to call other functions that do require the global current thread to be set, then it needs to temporarily change the current thread while calling these other functions. Therefore, switch and restore the current thread in btrace_compute_ftrace_bts. By inspection, it looks like btrace_compute_ftrace_pt may also call functions sensitive to the global context: it installs the btrace_pt_readmem_callback callback in the PT instruction decoder. When this function gets called, inferior_ptid must be set appropriately. Add a switch and restore in there too. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28086 Change-Id: I407fbfe41aab990068bd102491aa3709b0a034b3
* Automatic date update in version.inGDB Administrator2021-07-191-1/+1
|
* Move pending-obsolesence targets onto the obsolete list.Nick Clifton2021-07-182-6/+8
| | | | * config.bfd: Move pending obsoletion targets to obsolete list.
* Update how-to-make-a-release checklist with latest changes from 2.37 releaseNick Clifton2021-07-181-16/+35
|
* PR28098 Skip R_*_NONE relocation entries with zero r_sym without countingMichael Krasnyk2021-07-183-2/+11
| | | | | | PR gold/28098 * reloc.cc (Track_relocs::advance): Skip R_*_NONE relocation entries with r_sym of zero without counting in advance method.
* gdb: convert nat/x86-dregs.c macros to functionsSimon Marchi2021-07-171-11/+48
| | | | | | | | | I'm debugging why GDB crashes on OpenBSD/amd64, turns out it's because x86_dr_low.get_status is nullptr. It would have been useful to be able to break on x86_dr_low_get_status, so I thought it would be a good reason to convert these function-like macros into functions. Change-Id: Ic200b50ef8455b4697bc518da0fa2bb704cf4721
* Automatic date update in version.inGDB Administrator2021-07-181-1/+1
|
* Fix file-name handling regression with DWARF indexTom Tromey2021-07-174-84/+84
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When run with the gdb-index or debug-names target boards, dup-psym.exp fails. This came up for me because my new DWARF scanner reuses this part of the existing index code, and so it registers as a regression. This is PR symtab/25834. Looking into this, I found that the DWARF index code here is fairly different from the psymtab code. I don't think there's a deep reason for this, and in fact, it seemed to me that the index code could simply mimic what the psymtab code already does. That is what this patch implements. The DW_AT_name and DW_AT_comp_dir are now stored in the quick file names table. This may require allocating a quick file names table even when DW_AT_stmt_list does not exist. Then, the functions that work with this data are changed to use find_source_or_rewrite, just as the psymbol code does. Finally, line_header::file_full_name is removed, as it is no longer needed. Currently, the index maintains a hash table of "quick file names". The hash table uses a deletion function to free the "real name" components when necessary. There's also a second such function to implement the forget_cached_source_info method. This bug fix patch will create a quick file name object even when there is no DW_AT_stmt_list, meaning that the object won't be entered in the hash table. So, this patch changes the memory management approach so that the entries are cleared when the per-BFD object is destroyed. (A dwarf2_per_cu_data destructor is not introduced, because we have been avoiding adding a vtable to that class.) Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=25834
* Check for debug-types in map_symbol_filenamesTom Tromey2021-07-171-2/+4
| | | | | | | | | map_symbol_filenames can skip type units -- in fact I think it has to, due to the assertion at the top of dw2_get_file_names. This may be a regression due to the TU/CU unification patch, I did not check.
* Simplify DWARF file name cachingTom Tromey2021-07-171-17/+7
| | | | | | | | | | The DWARF index file name caching code only records when a line table has been read and the reading failed. However, the code would be simpler if it recorded any attempt, which is what this patch implements.
* Introduce find_source_or_rewriteTom Tromey2021-07-173-19/+37
| | | | | | | | | The final bug fix in this series would duplicate the logic in psymtab_to_fullname, so this patch extracts the body of this function into a new function.
* Simplify file_and_directory storage managementTom Tromey2021-07-171-10/+7
| | | | | | | | | | | file_and_directory carries a std::string in case the compilation directory is computed, but a subsequent patch wants to preserve this string without also having to maintain the storage for it. So, this patch arranges for the compilation directory string to be stored in the per-BFD string bcache instead.
* Pass file_and_directory through DWARF line-decoding codeTom Tromey2021-07-171-32/+25
| | | | | | | | | | | This patch removes the redundant "comp_unit" parameter from compute_include_file_name, and arranges to pass a file_and_directory object from the readers down to this function. It also changes the partial symtab reader to use find_file_and_directory, rather than reimplement this functionality by hand.
* Rename and refactor psymtab_include_file_nameTom Tromey2021-07-171-18/+19
| | | | | | | | | | | | In order to fix an index-related regression, I want to use psymtab_include_file_name in the DWARF index file-handling code. This patch renames this function and changes it to no longer require a partial symtab to be passed in. A subsequent patch will further refactor this code to remove the redundant parameter (which was always there but is now more obvious).
* Add basic Z80 CPU supportSergey Belyashov2021-07-1710-2/+2966
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Supported ISAs: - Z80 (all undocumented instructions) - Z180 - eZ80 (Z80 mode only) Datasheets: Z80: https://www.zilog.com/manage_directlink.php?filepath=docs/z80/um0080&extn=.pdf Z180: https://www.zilog.com/manage_directlink.php?filepath=docs/z180/ps0140&extn=.pdf eZ80: http://www.zilog.com/force_download.php?filepath=YUhSMGNEb3ZMM2QzZHk1NmFXeHZaeTVqYjIwdlpHOWpjeTlWVFRBd056Y3VjR1Jt To debug Z80 programs using GDB you must configure and embed z80-stub.c to your program (SDCC compiler is required). Or you may use some simulator with GDB support. gdb/ChangeLog: * Makefile.in (ALL_TARGET_OBS): Add z80-tdep.c. * NEWS: Mention z80 support. * configure.tgt: Handle z80*. * features/Makefile (XMLTOC): Add z80.xml. * features/z80-cpu.xml: New. * features/z80.c: Generate. * features/z80.xml: New. * z80-tdep.c: New file. * z80-tdep.h: New file. gdb/stubs/ChangeLog: * z80-stub.c: New file. Change-Id: Id0b7a6e210c3f93c6853c5e3031b7bcee47d0db9
* gdb: make all_inferiors_safe actually workSimon Marchi2021-07-172-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The test gdb.threads/fork-plus-threads.exp fails since 08bdefb58b78 ("gdb: make inferior_list use intrusive_list"): FAIL: gdb.threads/fork-plus-threads.exp: detach-on-fork=off: only inferior 1 left Looking at the log, we see that we are left with a bunch of inferiors in the detach-on-fork=off case: info inferiors^M Num Description Connection Executable ^M * 1 <null> <snip>/fork-plus-threads ^M 2 <null> <snip>/fork-plus-threads ^M 3 <null> <snip>/fork-plus-threads ^M 4 <null> <snip>/fork-plus-threads ^M 5 <null> <snip>/fork-plus-threads ^M 6 <null> <snip>/fork-plus-threads ^M 7 <null> <snip>/fork-plus-threads ^M 8 <null> <snip>/fork-plus-threads ^M 9 <null> <snip>/fork-plus-threads ^M 10 <null> <snip>/fork-plus-threads ^M 11 <null> <snip>/fork-plus-threads ^M (gdb) FAIL: gdb.threads/fork-plus-threads.exp: detach-on-fork=off: only inferior 1 left when we expect to have just one. The problem is prune_inferiors not pruning inferiors. And this is caused by all_inferiors_safe not actually iterating on inferiors. The current implementation: inline all_inferiors_safe_range all_inferiors_safe () { return {}; } default-constructs an all_inferiors_safe_range, which default-constructs an all_inferiors_safe_iterator as its m_begin field, which default-constructs a all_inferiors_iterator. A default-constructed all_inferiors_iterator is an end iterator, which means we have constructed an (end,end) all_inferiors_safe_range. We actually need to pass down the list on which we want to iterator (that is the inferior_list global), so that all_inferiors_iterator's first constructor is chosen. We also pass nullptr as the proc_target filter. In this case, we don't do any filtering, but if in the future all_inferiors_safe needed to allow filtering on process target (like all_inferiors does), we could pass down a process target pointer. basic_safe_iterator's constructor needs to be changed to allow constructing the wrapped iterator with multiple arguments, not just one. With this, gdb.threads/fork-plus-threads.exp is passing once again for me. Change-Id: I650552ede596e3590c4b7606ce403690a0278a01
* Automatic date update in version.inGDB Administrator2021-07-171-1/+1
|
* gdb: Support stepping out from signal handler on riscv*-linuxLancelot SIX2021-07-163-0/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, gdb cannot step outside of a signal handler on RISC-V platforms. This causes multiple failures in gdb.base/sigstep.exp: FAIL: gdb.base/sigstep.exp: continue to handler, nothing in handler, step from handler: leave handler (timeout) FAIL: gdb.base/sigstep.exp: continue to handler, si+advance in handler, step from handler: leave handler (timeout) FAIL: gdb.base/sigstep.exp: continue to handler, nothing in handler, next from handler: leave handler (timeout) FAIL: gdb.base/sigstep.exp: continue to handler, si+advance in handler, next from handler: leave handler (timeout) FAIL: gdb.base/sigstep.exp: stepi from handleri: leave signal trampoline FAIL: gdb.base/sigstep.exp: nexti from handleri: leave signal trampoline === gdb Summary === # of expected passes 587 # of unexpected failures 6 This patch adds support for stepping outside of a signal handler on riscv*-*-linux*. Implementation is heavily inspired from mips_linux_syscall_next_pc and surroundings as advised by Pedro Alves. After this patch, all tests in gdb.base/sigstep.exp pass. Build and tested on riscv64-linux-gnu.
* gdb/testsuite: Declare that riscv*-*-linux* cannot hardware_single_stepLancelot SIX2021-07-161-1/+1
| | | | | | | | | | | | | | | | Many tests fail in gdb/testsuite/gdb.base/sigstep.exp on riscv64-linux-gnu. Those tests check that when stepping, if the debuggee received a signal it should step inside the signal handler. This feature requires hardware support for single stepping (or at least kernel support), but none are available on riscv*-linux-gnu hosts, at the moment at least. This patch adds RISC-V to the list of configurations that does not have hardware single step capability, disabling tests relying on such feature. Tested on riscv64-linux-gnu.
* Document quick_symbol_functions::expand_symtabs_matching invariantTom Tromey2021-07-164-3/+15
| | | | | | | | | | | | While working on my series to replace the DWARF psymbol reader, I noticed that the expand_symtabs_matching has an undocumented invariant. I think that, if this invariant is not followed, then GDB will crash. So, this patch documents this in the relevant spots and introduces some asserts to make it clear. Regression tested on x86-64 Fedora 32.
* Fix array stride bugTom Tromey2021-07-163-7/+20
| | | | | | | | | | | | | | | | | | | | | | | | | Investigation of using the Python API with an Ada program showed that an array of dynamic types was not being handled properly. I tracked this down to an oddity of how array strides are handled. In gdb, an array stride can be attached to the range type, via the range_bounds object. However, the stride can also be put into the array's first field. From create_range_type_with_stride: else if (bit_stride > 0) TYPE_FIELD_BITSIZE (result_type, 0) = bit_stride; It's hard to be sure why this is done, but I would guess a combination of historical reasons plus a desire (mentioned in a comment somewhere) to avoid modifying the range type. This patch fixes the problem by changing type::bit_stride to understand this convention. It also fixes one spot that reproduces this logic. Regression tested on x86-64 Fedora 32.
* or1k: fix pc-relative relocation against dynamic on PC relative 26 bit ↵Giulio Benetti2021-07-162-0/+18
| | | | | | | | relocation. bfd * elf32-or1k.c (or1k_elf_relocate_section): Use a separate entry in switch case R_OR1K_INSN_REL_26 where we need to check for !SYMBOL_CALLS_LOCAL() instead of !SYMBOL_REFERENCES_LOCAL().
* Updated Swedish translation for the binutils sub-directoryNick Clifton2021-07-163-2301/+3142
|
* Automatic date update in version.inGDB Administrator2021-07-161-1/+1
|
* Avoid expression parsing crash with unknown languageTom Tromey2021-07-152-2/+8
| | | | | | | | | | | | | PR gdb/28093 points out that gdb crashes when language is set to "unknown" and expression parsing is attempted. At first I thought this was a regression due to the expression rewrite, but it turns out that older versions crash as well. This patch avoids the crash by changing the default expression parser to throw an exception. I think this is preferable -- the current behavior of silently doing nothing does not really make sense. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28093
* gdb: pass child_ptid and fork kind to target_ops::follow_forkSimon Marchi2021-07-1412-64/+59
| | | | | | | | | | | | | | | | | | | | | | | | This is a small cleanup I think would be nice, that I spotted while doing the following patch. gdb/ChangeLog: * target.h (struct target_ops) <follow_fork>: Add ptid and target_waitkind parameters. (target_follow_fork): Likewise. * target.c (default_follow_fork): Likewise. (target_follow_fork): Likewise. * fbsd-nat.h (class fbsd_nat_target) <follow_fork>: Likewise. * fbsd-nat.c (fbsd_nat_target::follow_fork): Likewise. * linux-nat.h (class linux_nat_target) <follow_fork>: Likewise. * linux-nat.c (linux_nat_target::follow_fork): Likewise. * obsd-nat.h (class obsd_nat_target) <follow_fork>: Likewise. * obsd-nat.c (obsd_nat_target::follow_fork): Likewise. * remote.c (class remote_target) <follow_fork>: Likewise. * target-debug.h (target_debug_print_target_waitkind): New. * target-delegates.c: Re-generate. Change-Id: I5421a542f2e19100a22b74cc333d2b235d0de3c8
View Lorry Controller Status