aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2021-07-23gdb: rename cfunc to simple_funcSimon Marchi5-44/+53
After browsing the CLI code for quite a while and trying really hard, I reached the conclusion that I can't give a meaningful explanation of what "sfunc" and "cfunc" functions are, in cmd_list_element. I don't see a logic at all. That makes it very difficult to do any kind of change. Unless somebody can make sense out of all that, I'd like to try to retro-fit some logic in the cmd_list_element callback function code so that we can understand what is going on, do some cleanups and add new features. The first change is about "cfunc". I can't figure out what the "c" in cfunc means. It's not const, because there's already "const" in "cmd_const_cfunc_ftype", and the previous "cmd_cfunc_ftype" had nothing const.. It's not "cmd" or "command", because there's already "cmd" in "cmd_const_cfunc_ftype". The "main" command callback, cmd_list_element::func, has three parameters, whereas cfunc has two. It is missing the cmd_list_element parameter. So the only reason I see for cfunc to exist is to be a shim between the three and two parameter versions. Most commands don't need to receive the cmd_list_element object, so adding it everywhere would be long and would just add more unnecessary boilerplate. So since this is the "simple" version of the callback, compared to the "full", I suggest renaming cmd_const_cfunc_ftype into cmd_simple_func_ftype, as well as everything (like the utility functions) that goes with it. Change-Id: I4e46cacfd77a66bc1cbf683f6a362072504b7868
2021-07-23gdb: make inferior::m_terminal an std::stringSimon Marchi6-51/+41
Same idea as the previous patch, but for m_terminal. Change-Id: If9367d5db8c976a4336680adca4ea5bc31ab64d2
2021-07-23gdb: make inferior::m_cwd an std::stringSimon Marchi8-48/+41
Same idea as the previous patch, but for m_cwd. To keep things consistent across the board, change get_inferior_cwd as well, which is shared with GDBserver. So update the related GDBserver code too. Change-Id: Ia2c047fda738d45f3d18bc999eb67ceb8400ce4e
2021-07-23gdb: make inferior::m_args an std::stringSimon Marchi6-35/+23
With the current code, both a NULL pointer and an empty string can mean "no arguments". We don't need this distinction. Changing to a string has the advantage that there is now a single state for that (an empty string), which makes the code a bit simpler in my opinion. Change-Id: Icdc622820f7869478791dbaa84b4a1c7fec21ced
2021-07-23gdb: add setter/getter for inferior cwdSimon Marchi4-26/+29
Add cwd/set_cwd to the inferior class, remove set_inferior_args. Keep get_inferior_args, because it is used from fork_inferior, in shared code. The cwd could eventually be passed as a parameter eventually, though, I think that would be cleaner. Change-Id: Ifb72ea865d7e6f9a491308f0d5c1595579d8427e
2021-07-23gdb: add setter/getter for inferior argumentsSimon Marchi6-39/+40
Add args/set_args to the inferior class, remove the set_inferior_args and get_inferior_args functions, that would just be wrappers around them. Change-Id: If87d52f3402ce08be26c32897ae8915d9f6d1ea3
2021-07-23gdb: remove inferior::{argc,argv}Simon Marchi2-28/+5
There are currently two states that the inferior args can be stored. The main one is the `args` field, where they are stored as a single string. The other one is the `argc`/`argv` fields. This last one is only used for arguments passed in GDB's command line. And the only outcome is that when get_inferior_args is called, `argc`/`argv` are serialized into `args`. So really, `argc`/`argv` is just a staging area before moving the arguments in `args`. Simplify this by only keeping the `args` field. Change set_inferior_args_vector to immediately serialize the arguments into `args`, work that would be done in get_inferior_args later anyway. The only time where this work would be "wasted" is when the user passes some arguments on the command line, but does not end up running the program. But that just seems unlikely. And it's not that much work. Change-Id: Ica0b9859397c095f6530350c8fb3c36905f2044a
2021-07-23gdb: un-share set_inferior_cwd declarationSimon Marchi4-7/+8
The declaration of set_inferior_cwd is currently shared between gdb and gdbserver, in gdbsupport/common-inferior.h. It doesn't need to be, as set_inferior_cwd is not called from common code. Only get_inferior_cwd needs to. The motivation for this is that a future patch will change the prototype of set_inferior_cwd in gdb, and I don't want to change it for gdbserver unnecessarily. I see this as a good cleanup in any case, to reduce to just the essential what is shared between GDB and GDBserver. Change-Id: I3127d27d078f0503ebf5ccc6fddf14f212426a73
2021-07-23gdb.base/setshow.exp: fix duplicate test nameSimon Marchi1-2/+4
Fix: DUPLICATE: gdb.base/setshow.exp: test_setshow_args: show args by giving some explicit test names. Change-Id: I2a738d3d3675ab9b45929e71f5aee0ea6bf92072
2021-07-23gdb.base/setshow.exp: split in procsSimon Marchi1-294/+435
Split in multiple procs, one per topic, and start with a fresh GDB in each. I find it easier to work on a test with multiple smaller independent test procedures. For example, it's possible to comment all but one when working on one. It's also easier to add things without having to think about the impact on existing tests, and vice-versa. Change-Id: I19691eed8f9bcb975b2eeff7577cac66251bcbe2
2021-07-23gdb.base/setshow.exp: use save_vars to save/restore gdb_promptSimon Marchi1-17/+16
Using save_vars is a bit better than what we have now, as it ensures the variable gets restored if the code within it throws an error. Change-Id: I3bd6836e5b7efb61b078acadff1a1c8182c19a27
2021-07-23gdb/testsuite: split gdb.python/py-parameter.exp in procsSimon Marchi1-100/+137
Split the file into multiple independent test procs, where each proc starts with a fresh GDB. I find it easier to understand what a test is doing when each part of the test is isolated and self-contained. It makes it easier to comment out some parts of the test while working / debugging a specific part. It also makes it easier to add new things (which a subsequent patch will do) without fear of impacting another part of the test. Change-Id: I8b4d52ac82b1492d79b679e13914ed177d8a836d
2021-07-23Fix for gdb.python/py-breakpoint.expCarl Love1-0/+3
Not all systems have hardware breakpoint support. Add a check to see if the system supports hardware breakpoints. gdb/testsuite/ChangeLog * gdb.python/py-breakpoint.exp (test_hardware_breakpoints): Add check for hardware breakpoint support.
2021-07-23gdb/testsuite: don't error when trying to unset last_spawn_tty_nameAndrew Burgess1-2/+12
In spawn_capture_tty_name (lib/gdb.exp) we either set or unset last_spawn_tty_name depending on whether spawn_out(slave,name) exists or not. One situation that might cause spawn_out(slave,name) to not exists is if the spawn function is called with the argument -leaveopen, which is how it is called when processes are created as part of a pipeline, the created process has no tty, instead its output is written to a file descriptor. If a pipeline is created consisting of multiple processes then there will be multiple sequential calls to spawn, all using -leaveopen. The first of these calls is fine, spawn_out(slave,name) is not set, and so in spawn_capture_tty_name we unset last_spawn_tty_name. However, on the second call to spawn, spawn_out(slave,name) is still not set and so in spawn_capture_tty_name we again try to unset last_spawn_tty_name, this now throws an error (as last_spawn_tty_name is already unset). Fix this issue by using -nocomplain with the call to unset in spawn_capture_tty_name. Before this commit I was seeing gdb.base/gnu-debugdata.exp report 1 pass, and 1 unsupported test. After this commit I now see 16 passes from this test script. I have also improved the code that used to do this: if { [info exists spawn_out] } { set ::last_spawn_tty_name $spawn_out(slave,name) } else { ... } The problem here is that we check for the existence of spawn_out, and then unconditionally read spawn_out(slave,name). A situation could arise where some other element of spawn_out is set, e.g. spawn_out(foo), in which case we would enter the if block and try to read a non-existent variable. After this commit we now check specifically for spawn_out(slave,name). Finally, it is worth noting that before this issue was fixed runtest itself, or rather the expect process behind runtest, would segfault while exiting. I haven't looked at all into what the problem is here that caused expect to crash, as fixing the bug in GDB's testing scripts made the segfault go away.
2021-07-23x86: express unduly set rounding control bits in disassemblyJan Beulich7-63/+81
While EVEX.L'L are indeed ignored when EVEX.b stands for just SAE, EVEX.b itself is not ignored when an insn permits neither rounding control nor SAE. While changing this aspect of EVEX.b handling, also alter unduly set embedded broadcast: Don't call BadOp(), screwing up subsequent disassembly, but emit "{bad}" instead.
2021-07-23Automatic date update in version.inGDB Administrator1-1/+1
2021-07-22[gdb/testsuite] Fix FAILs due to PR gcc/101575Tom de Vries3-5/+71
When running test-case gdb.ada/formatted_ref.exp with gcc-11 and target board unix/gdb:debug_flags=-gdwarf-4 we run into: ... (gdb) print/x s^M No definition of "s" in current context.^M (gdb) FAIL: gdb.ada/formatted_ref.exp: print/x s ... which is caused by "runto defs.adb:20" taking us to defs__struct1IP: ... (gdb) break defs.adb:20^M Breakpoint 1 at 0x402cfd: defs.adb:20. (2 locations)^M (gdb) run ^M Starting program: formatted_ref ^M ^M Breakpoint 1, defs__struct1IP () at defs.adb:20^M 20 return s.x; -- Set breakpoint marker here.^M (gdb) print s1'access^M ... instead of the expected defs.f1: ... (gdb) break defs.adb:20^M Breakpoint 1 at 0x402d0e: file defs.adb, line 20.^M (gdb) run ^M Starting program: formatted_ref ^M ^M Breakpoint 1, defs.f1 (s=...) at defs.adb:20^M 20 return s.x; -- Set breakpoint marker here.^M ... This is caused by incorrect line info due to gcc PR 101575 - "[gcc-11, -gdwarf-4] Missing .file <n> directive causes invalid line info". Fix this by when landing in defs__struct1IP: - xfailing the runto, and - issuing a continue to land in defs.f1. Likewise in a few other test-cases. Tested on x86_64-linux, with: - system gcc. - gcc-11 and target boards unix/gdb:debug_flags=-gdwarf-4 and unix/gdb:debug_flags=-gdwarf-5. gdb/testsuite/ChangeLog: 2021-07-22 Tom de Vries <tdevries@suse.de> * gdb.ada/formatted_ref.exp: Add xfail for PR gcc/101575. * gdb.ada/iwide.exp: Same. * gdb.ada/pkd_arr_elem.exp: Same.
2021-07-22x86: drop dq{b,d}_modeJan Beulich6-114/+97
Their sole use is for {,V}EXTRACTPS / {,V}P{EXT,INS}RB respectively; for consistency also limit use of dqw_mode to Jdqw. 64-bit disassembly reflecting REX.W / VEX.W is not in line with the assembler's opcode table having NoRex64 / VexWIG in all respective templates, i.e. assembly input isn't being honored there either. Obviously the 0FC5 encodings of {,V}PEXTRW then also need adjustment for consistency reasons.
2021-07-22x86: drop vex_scalar_w_dq_modeJan Beulich3-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.
2021-07-22x86: drop xmm_m{b,w,d,q}_modeJan Beulich4-164/+91
They're effectively redundant with {b,w,d,q}_mode.
2021-07-22x86: fold duplicate vector register printing codeJan Beulich1-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.
2021-07-22x86: drop vex_mode and vex_scalar_modeJan Beulich1-11/+7
These are fully redundant with, respectively, x_mode and scalar_mode.
2021-07-22x86: correct EVEX.V' handling outside of 64-bit modeJan Beulich2-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.)
2021-07-22x86: fold duplicate code in MOVSXD_Fixup()Jan Beulich1-16/+10
There's no need to have two paths printing the "xd" mnemonic suffix.
2021-07-22x86: fold duplicate register printing codeJan Beulich1-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.
2021-07-22x86-64: properly bounds-check %bnd<N> in OP_G()Jan Beulich3-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.
2021-07-22x86-64: generalize OP_G()'s EVEX.R' handlingJan Beulich4-1/+14
EVEX.R' is invalid to be clear not only for mask registers, but also for GPRs - IOW everything handled in this function.
2021-07-22x86: correct VCVT{,U}SI2SD rounding mode handlingJan Beulich7-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.
2021-07-22x86: drop OP_Mask()Jan Beulich4-48/+28
By moving its vex.r check there it becomes fully redundant with OP_G().
2021-07-22Automatic date update in version.inGDB Administrator1-1/+1
2021-07-21[gdb/testsuite] Fix gdb.cp/step-and-next-inline.exp with gcc-11Tom de Vries3-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.
2021-07-21Updated Russian translation for the bfd libraryNick Clifton1-1840/+2056
2021-07-21Allows linker scripts to set the SEC_READONLY flag.Luca Boccassi8-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.
2021-07-21[gdb/testsuite] Fix FAILs due to PR gcc/101452Tom de Vries6-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.
2021-07-21[gdb/testsuite] Add KFAILs for gdb.ada FAILs with gcc-11Tom de Vries3-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.
2021-07-21as_bad_subtractAlan Modra33-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.
2021-07-21Remove `netbsdpe` supportJohn Ericson8-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.
2021-07-21Automatic date update in version.inGDB Administrator1-1/+1
2021-07-20PR28106, build of 2.37 fails on FreeBSD and ClangAlan Modra2-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.
2021-07-20Fix printing of non-address types when memory tagging is enabledLuis Machado3-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
2021-07-20RISC-V: Minor updates for architecture parser.Nelson Chu3-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.
2021-07-20Automatic date update in version.inGDB Administrator1-1/+1
2021-07-19gdb: set current thread in btrace_compute_ftrace_{bts,pt}Simon Marchi1-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
2021-07-19Automatic date update in version.inGDB Administrator1-1/+1
2021-07-18Move pending-obsolesence targets onto the obsolete list.Nick Clifton2-6/+8
* config.bfd: Move pending obsoletion targets to obsolete list.
2021-07-18Update how-to-make-a-release checklist with latest changes from 2.37 releaseNick Clifton1-16/+35
2021-07-18PR28098 Skip R_*_NONE relocation entries with zero r_sym without countingMichael Krasnyk3-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.
2021-07-17gdb: convert nat/x86-dregs.c macros to functionsSimon Marchi1-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
2021-07-18Automatic date update in version.inGDB Administrator1-1/+1
2021-07-17Fix file-name handling regression with DWARF indexTom Tromey4-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
generated by cgit v1.1 at 2024-11-19 22:27:29 +0000