aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2022-11-28gdb: fix assert when quitting GDB while a thread is steppingAndrew Burgess2-0/+57
This commit addresses one of the issues identified in PR gdb/28275. Bug gdb/28275 identifies a number of situations in which this assert: Assertion `!proc_target->commit_resumed_state' failed. could be triggered. There's actually a number of similar places where this assert is found in GDB, the two of interest in gdb/28275 are in target_wait and target_stop. In one of the comments: https://sourceware.org/bugzilla/show_bug.cgi?id=28275#c1 steps to trigger the assertion within target_stop were identified when using a modified version of the gdb.threads/detach-step-over.exp test script. In the gdb.threads/detach-step-over.exp test, we attach to a multi-threaded inferior, and continue the inferior in asynchronous (background) mode. Each thread is continuously hitting a conditional breakpoint where the condition is always false. While the inferior is running we detach. The goal is that we detach while GDB is performing a step-over for the conditional breakpoint in at least one thread. While detaching, if a step-over is in progress, then GDB has to complete the step over before we can detach. This involves calling target_stop and target_wait (see prepare_for_detach). As far as gdb/28275 is concerned, the interesting part here, is the the process_stratum_target::commit_resumed_state variable must be false when target_stop and target_wait are called. This is currently ensured because, in detach_command (infrun.c), we create an instance of scoped_disable_commit_resumed, this ensures that when target_detach is called, ::commit_resumed_state will be false. The modification to the test that I propose here, and which exposed the bug, is that, instead of using "detach" to detach from the inferior, we instead use "quit". Quitting GDB after attaching to an inferior will cause GDB to first detach, and then exit. When we quit GDB we end up calling target_detach via a different code path, the stack looks like: #0 target_detach #1 kill_or_detach #2 quit_force #3 quit_command Along this path there is no scoped_disable_commit_resumed created. ::commit_resumed_state can be true when we reach prepare_for_detach, which calls target_wait and target_stop, so the assertion will trigger. In this commit, I propose fixing this by adding the creation of a scoped_disable_commit_resumed into target_detach. This will ensure that ::commit_resumed_state is false when calling prepare_for_detach from within target_detach. I did consider placing the scoped_disable_commit_resumed in prepare_for_detach, however, placing it in target_detach ensures that the target's commit_resumed_state flag is left to false if the detached inferior was the last one for that target. It's the same rationale as for patch "gdb: disable commit resumed in target_kill" that comes later in this series, but for detach instead of kill. detach_command still includes a scoped_disable_commit_resumed too, but I think it is still relevant to cover the resumption at the end of the function. Co-Authored-By: Simon Marchi <simon.marchi@efficios.com> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28275 Change-Id: Ie128f7aba6ef0e018859275eca372e6ea738e96f
2022-11-28gdb/testsuite: refactor gdb.threads/detach-step-over.expAndrew Burgess1-100/+138
Factor out some bits of gdb.threads/detach-step-over.exp to procs in preparation to adding some new variations of the test. Rename the existing "test" proc and make it use proc_with_prefix. Co-Authored-By: Simon Marchi <simon.marchi@efficios.com> Change-Id: Ib4412545c81c8556029e0f7bfa9dd48d7a9f3189
2022-11-28gdb/testsuite: remove global declarations in gdb.threads/detach-step-over.expSimon Marchi1-23/+17
Before doing further changes to this file, change to use the :: notation instead of declaring global variables with the `global` keyword. Change-Id: I72301fd8f4693fea61aac054ba17245a1f4442fb Approved-By: Andrew Burgess <aburgess@redhat.com>
2022-11-28[gdb/testsuite] Fix gdb.arch/altivec-regs.exp with gcc 4.8.5Tom de Vries1-1/+1
On powerpc64le-linux, using gcc 4.8.5, I run into: ... (gdb) PASS: gdb.arch/altivec-regs.exp: next (1) next^M 11 c = vec_add (a, b);^M (gdb) PASS: gdb.arch/altivec-regs.exp: next (2) print/x a^M $67 = {0xfefefefe, 0xfefefefe, 0xfefefefe, 0xfefefefe}^M (gdb) FAIL: gdb.arch/altivec-regs.exp: print vector parameter a ... Looking at the disassembly and the debug info, it's clear why there's a FAIL. The debug info says that the variable can be found at some stack location, but the instructions don't seem to be writing there. We can work around this by marking variable a volatile. Likewise for b. Note that marking the variables as volatile doesn't change the location information. Tested on power64le-linux.
2022-11-28[gdb/tdep] Fix gdb.base/msym-bp-shl.exp for ppc64leTom de Vries1-0/+5
With test-case gdb.base/msym-bp-shl.exp on powerpc64le-linux, I run into: ... (gdb) PASS: gdb.base/msym-bp-shl.exp: debug=0: before run: break foo info breakpoint^M Num Type Disp Enb Address What^M 1 breakpoint keep y <MULTIPLE> ^M 1.1 y 0x00000000000008d4 <foo+12>^M 1.2 y 0x0000000000000a34 crti.S:88^M (gdb) FAIL: gdb.base/msym-bp-shl.exp: debug=0: before run: info breakpoint ... The problem is that the prologue skipper walks from foo@plt at 0xa28 to 0xa34: ... 0000000000000a28 <foo@plt>: a28: c0 ff ff 4b b 9e8 <__glink_PLTresolve> Disassembly of section .fini: 0000000000000a2c <_fini>: a2c: 02 00 4c 3c addis r2,r12,2 a30: d4 74 42 38 addi r2,r2,29908 a34: a6 02 08 7c mflr r0 ... This is caused by ppc_elfv2_elf_make_msymbol_special which marks foo@plt as having a local entry point, due to incorrectly accessing an asymbol struct using a (larger) elf_symbol_type. Fix this by simply ignoring artificial symbols in ppc_elfv2_elf_make_msymbol_special. Tested on powerpc64le. Approved-By: Ulrich Weigand <uweigand@de.ibm.com> Reviewed-By: Carl Love <cel@us.ibm.com> Tested-By: Carl Love <cel@us.ibm.com> PR tdep/29814 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29814
2022-11-28PR10368, ISO 8859 mentioned as 7bit encoding in strings documentationAlan Modra1-1/+1
PR 10368 * doc/binutils.texi (strings): Delete example of 7-bit encoding.
2022-11-28Use bfd_rename_section in msp430.emAlan Modra2-1/+7
* emultempl/msp430.em (add_region_prefix <REGION_EITHER>): Use bfd_rename_section. * testsuite/ld-msp430-elf/msp430-tiny-rom.ld: Handle varian data and bss input sections.
2022-11-28asan: pef: buffer overflowAlan Modra1-1/+1
* pef.c (bfd_pef_parse_traceback_table): Correct size moved when stripping leading dot.
2022-11-28regen gas/Makefile.inAlan Modra1-8/+9
2022-11-28RISC-V: Allow merging 'H' extensionTsukasa OI1-1/+1
Because riscv_merge_std_ext function did not merge the 'H' extension, linked executables lacked 'H' extension when multiple objects are merged. This issue is found while building OpenSBI with 'H' extension (resulting ELF files did not contain "h1p0" in "Tag_RISCV_arch" even if *all* linked object files contained it). This commit adds 'h' to standard_exts variable to merge 'H' extension. bfd/ChangeLog: * elfnn-riscv.c (riscv_merge_std_ext): Add 'H' extension merging.
2022-11-28RISC-V: Better support for long instructions (tests)Tsukasa OI4-1/+48
This commit tests both (assembler and disassembler) fixes of "Better support for long instructions". gas/ChangeLog: * testsuite/gas/riscv/insn.s: Add testcases such that big number handling is required and should be disassembled as long ".byte" sequence with correct instruction bits. * testsuite/gas/riscv/insn.d: Likewise. * testsuite/gas/riscv/insn-na.d: Likewise. * testsuite/gas/riscv/insn-dwarf.d: Likewise.
2022-11-28RISC-V: Better support for long instructions (assembler)Tsukasa OI1-9/+32
Commit bb996692bd96 ("RISC-V/gas: allow generating up to 176-bit instructions with .insn") tried to start supporting long instructions but it was insufficient. 1. It heavily depended on the bignum internals (radix of 2^16), 2. It generates "value conflicts with instruction length" even if a big number instruction encoding does not exceed its expected length and 3. Because long opcode was handled separately (from struct riscv_cl_insn), some information like DWARF line number correspondence was missing. To resolve these problems, this commit: 1. Handles bignum (and its encodings) precisely and 2. Incorporates long opcode handling into regular instruction handling. This commit will be tested on the separate commit. gas/ChangeLog: * config/tc-riscv.c (struct riscv_cl_insn): Add long opcode field. (create_insn) Clear long opcode marker. (install_insn) Install longer opcode as well. (s_riscv_insn) Likewise. (riscv_ip_hardcode): Make big number handling stricter. Length and the value conflicts only if the bignum size exceeds the expected maximum length.
2022-11-28RISC-V: Better support for long instructions (disassembler)Tsukasa OI1-5/+9
Commit bb996692bd96 ("RISC-V/gas: allow generating up to 176-bit instructions with .insn") tried to start supporting long instructions but it was insufficient. On the disassembler, correct ".byte" output was limited to the first 64-bits of an instruction. After that, zeroes are incorrectly printed. Note that, it only happens on ".byte" output (instruction part) and not on hexdump (data) part. For example, before this commit, hexdump and ".byte" produces different values: Assembly: .insn 22, 0xfedcba98765432100123456789abcdef55aa33cc607f objdump output example (before the fix): 10: 607f 33cc 55aa cdef .byte 0x7f, 0x60, 0xcc, 0x33, 0xaa, 0x55, 0xef, 0xcd, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 18: 89ab 4567 0123 3210 20: 7654 ba98 fedc Note that, after 0xcd (after first 64-bits of the target instruction), all ".byte" values are incorrectly printed as zero while hexdump prints correct instruction bits. To resolve this, this commit adds "packet" argument to support dumping instructions longer than 64-bits (to print correct instruction bits on ".byte"). This commit will be tested on the separate commit. Assembly: .insn 22, 0xfedcba98765432100123456789abcdef55aa33cc607f objdump output example (after the fix): 10: 607f 33cc 55aa cdef .byte 0x7f, 0x60, 0xcc, 0x33, 0xaa, 0x55, 0xef, 0xcd, 0xab, 0x89, 0x67, 0x45, 0x23, 0x01, 0x10, 0x32, 0x54, 0x76, 0x98, 0xba, 0xdc, 0xfe 18: 89ab 4567 0123 3210 20: 7654 ba98 fedc opcodes/ChangeLog: * riscv-dis.c (riscv_disassemble_insn): Print unknown instruction using the new argument packet. (riscv_disassemble_data): Add unused argument packet. (print_insn_riscv): Pass packet to the disassemble function.
2022-11-28Automatic date update in version.inGDB Administrator1-1/+1
2022-11-27Fix leak in the dwarf readerPhilippe Waroquiers1-1/+1
Valgrind reports a leak in the dwarf reader (see details below). The function dw2_get_file_names_reader is interning in the per_objfile all the file names it finds, except the name of 'fnd file name and directory'. Instead, it was xstrdup-ing the name. Fix the leaks by also interning the name. This was validated running the tests natively, and under valgrind. Leaks have decreased as mentionned below. Valgrind detected no error such as double free or use after free. Stack trace of the leak: ==4113266== 490,735 bytes in 17,500 blocks are definitely lost in loss record 7,061 of 7,074 ==4113266== at 0x483979B: malloc (vg_replace_malloc.c:393) ==4113266== by 0x25A454: xmalloc (alloc.c:57) ==4113266== by 0x7D1E1E: xstrdup (xstrdup.c:34) ==4113266== by 0x39D141: dw2_get_file_names_reader (read.c:2825) ==4113266== by 0x39D141: dw2_get_file_names(dwarf2_per_cu_data*, dwarf2_per_objfile*) (read.c:2851) ==4113266== by 0x39DD6C: dw_expand_symtabs_matching_file_matcher(dwarf2_per_objfile*, gdb::function_view<bool (char const*, bool)>) (read.c:4149) ==4113266== by 0x3BC8B5: cooked_index_functions::expand_symtabs_matching(objfile*, gdb::function_view<bool (char const*, bool)>, lookup_name_info const*, gdb::function_view<bool (char const*)>, gdb::function_view<bool (compunit_symtab*)>, enum_flags<block_search_flag_values>, domain_enum, search_domain) (read.c:18688) ==4113266== by 0x5DD1EA: objfile::map_symtabs_matching_filename(char const*, char const*, gdb::function_view<bool (symtab*)>) (symfile-debug.c:207) ==4113266== by 0x5F04CC: iterate_over_symtabs(char const*, gdb::function_view<bool (symtab*)>) (symtab.c:633) ==4113266== by 0x477EE3: collect_symtabs_from_filename(char const*, program_space*) (linespec.c:3712) ==4113266== by 0x477FC1: symtabs_from_filename(char const*, program_space*) (linespec.c:3726) ==4113266== by 0x47A9B8: convert_explicit_location_spec_to_linespec(linespec_state*, linespec*, char const*, char const*, symbol_name_match_type, char const*, line_offset) (linespec.c:2329) ==4113266== by 0x47E86E: convert_explicit_location_spec_to_sals (linespec.c:2388) ==4113266== by 0x47E86E: location_spec_to_sals(linespec_parser*, location_spec const*) (linespec.c:3104) ==4113266== by 0x47EDAC: decode_line_full(location_spec*, int, program_space*, symtab*, int, linespec_result*, char const*, char const*) (linespec.c:3149) ... Without the fix, the top 10 leaks are: ./gdb/testsuite/outputs/gdb.base/condbreak-bad/gdb.log:345:==3213924== definitely lost: 130,937 bytes in 5,409 blocks ./gdb/testsuite/outputs/gdb.base/hbreak2/gdb.log:619:==3758919== definitely lost: 173,323 bytes in 7,204 blocks ./gdb/testsuite/outputs/gdb.mi/mi-var-cp/gdb.log:1320:==4152873== definitely lost: 172,826 bytes in 7,207 blocks ./gdb/testsuite/outputs/gdb.base/advance-until-multiple-locations/gdb.log:398:==2992643== definitely lost: 172,965 bytes in 7,211 blocks ./gdb/testsuite/outputs/gdb.mi/mi-var-cmd/gdb.log:2302:==4159476== definitely lost: 173,129 bytes in 7,211 blocks ./gdb/testsuite/outputs/gdb.cp/gdb2384/gdb.log:222:==3811851== definitely lost: 218,106 bytes in 7,761 blocks ./gdb/testsuite/outputs/gdb.cp/mb-templates/gdb.log:310:==3787344== definitely lost: 290,311 bytes in 10,340 blocks ./gdb/testsuite/outputs/gdb.mi/mi-var-rtti/gdb.log:2568:==4158350== definitely lost: 435,427 bytes in 15,507 blocks ./gdb/testsuite/outputs/gdb.mi/mi-catch-cpp-exceptions/gdb.log:1704:==4119722== definitely lost: 435,405 bytes in 15,510 blocks ./gdb/testsuite/outputs/gdb.mi/mi-vla-fortran/gdb.log:768:==4113266== definitely lost: 508,585 bytes in 18,109 blocks With the fix: ./gdb/testsuite/outputs/gdb.base/fork-running-state/gdb.log:1536:==2924193== indirectly lost: 13,848 bytes in 98 blocks ./gdb/testsuite/outputs/gdb.base/fork-running-state/gdb.log:1675:==2928777== indirectly lost: 13,848 bytes in 98 blocks ./gdb/testsuite/outputs/gdb.python/py-inferior-leak/gdb.log:4729:==3353335== definitely lost: 3,360 bytes in 140 blocks ./gdb/testsuite/outputs/gdb.base/kill-detach-inferiors-cmd/gdb.log:210:==2746927== indirectly lost: 13,246 bytes in 154 blocks ./gdb/testsuite/outputs/gdb.base/inferior-clone/gdb.log:179:==3034984== indirectly lost: 12,921 bytes in 161 blocks ./gdb/testsuite/outputs/gdb.base/interrupt-daemon/gdb.log:209:==3006248== indirectly lost: 20,683 bytes in 174 blocks ./gdb/testsuite/outputs/gdb.threads/watchpoint-fork/gdb.log:714:==3512403== indirectly lost: 20,707 bytes in 175 blocks ./gdb/testsuite/outputs/gdb.threads/watchpoint-fork/gdb.log:962:==3514498== indirectly lost: 20,851 bytes in 178 blocks ./gdb/testsuite/outputs/gdb.base/multi-forks/gdb.log:336:==2585839== indirectly lost: 53,630 bytes in 386 blocks ./gdb/testsuite/outputs/gdb.base/multi-forks/gdb.log:1338:==2592417== indirectly lost: 100,008 bytes in 1,154 blocks Approved-By: Simon Marchi <simon.marchi@efficios.com>
2022-11-27fix leak in gdb_environPhilippe Waroquiers1-0/+2
valgrind reports a leak when assigning a gdb_environ to another gdb_environ. The memory allocated for the target gdb_environ env variables is not released. The gdb_environ selftest reproduces the leak (see below). Fix the leak by clearing the target gdb_environ before std::move-ing the members. Tested natively and re-running all tests under valgrind. ==3261873== 4,842 bytes in 69 blocks are definitely lost in loss record 6,772 of 6,839 ==3261873== at 0x483979B: malloc (vg_replace_malloc.c:393) ==3261873== by 0x25A454: xmalloc (alloc.c:57) ==3261873== by 0x7D1E4E: xstrdup (xstrdup.c:34) ==3261873== by 0x7E2A51: gdb_environ::from_host_environ() (environ.cc:56) ==3261873== by 0x66F1C8: test_reinit_from_host_environ (environ-selftests.c:78) ==3261873== by 0x66F1C8: selftests::gdb_environ_tests::run_tests() (environ-selftests.c:285) ==3261873== by 0x7EFC43: operator() (std_function.h:622) = Approved-By: Simon Marchi <simon.marchi@efficios.com>
2022-11-27Use false/true for some inferior class members instead of 0/1Philippe Waroquiers11-22/+22
Some class members were changed to bool, but there was still some assignments or comparisons using 0/1. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2022-11-27[gdb/server] Emit warning for SIGINT failureTom de Vries1-1/+4
Consider the executable from test-case gdb.base/interrupt-daemon.exp. When starting it using gdbserver: ... $ ./build/gdbserver/gdbserver localhost:2345 \ ./outputs/gdb.base/interrupt-daemon/interrupt-daemon ... and connecting to it using gdb: ... $ gdb -q -ex "target remote localhost:2345" \ -ex "set follow-fork-mode child" \ -ex "break daemon_main" -ex cont ... we are setup to do the same as in the test-case: interrupt a running inferior using ^C. So let's try: ... (gdb) continue Continuing. ^C ... After pressing ^C, nothing happens. This a known problem, filed as PR remote/18772. The problem is that in linux_process_target::request_interrupt, a kill is used to send a SIGINT, but it fails. And it fails silently. Make the failure verbose by adding a warning, such that the gdbserver output becomes more helpful: ... Process interrupt-daemon created; pid = 15068 Listening on port 2345 Remote debugging from host ::1, port 35148 Detaching from process 15068 Detaching from process 15085 gdbserver: Sending SIGINT to process group of pid 15068 failed: \ No such process ... Note that the failure can easily be reproduced using the test-case and target board native-gdbserver: ... (gdb) continue^M Continuing.^M PASS: gdb.base/interrupt-daemon.exp: fg: continue ^CFAIL: gdb.base/interrupt-daemon.exp: fg: ctrl-c stops process (timeout) ... as reported in PR server/23382. Tested on x86_64-linux. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2022-11-27Automatic date update in version.inGDB Administrator1-1/+1
2022-11-26[gdb/testsuite] Don't generate core in gdb.base/bt-on-fatal-signal.expTom de Vries2-1/+15
When running test-case gdb.base/bt-on-fatal-signal.exp on powerpc64le-linux I noticed: ... FAIL: gdb.base/bt-on-fatal-signal.exp: SEGV: scan for backtrace (timeout) ... The timeout is 10 seconds, but generating the core file takes more than a minute, probably due to slow NFS. I managed to reproduce this behaviour independently of gdb, by compiling "int main (void) { __builtin_abort (); }" and running it, which took 1.5 seconds for a core file 50 times smaller than the one for gdb. Fix this by preventing the core file from being generated, using a wrapper around gdb that does "ulimit -c 0". Tested on x86_64-linux.
2022-11-26[gdb/symtab] Handle failure to open .gnu_debugaltlink fileTom de Vries2-1/+58
If we instrument cc-with-tweaks.sh to remove the .gnu_debugaltlink file after dwz has created it, with test-case gdb.threads/access-mem-running-thread-exit.exp and target board cc-with-dwz-m we run into: ... (gdb) file access-mem-running-thread-exit^M Reading symbols from access-mem-running-thread-exit...^M could not find '.gnu_debugaltlink' file for access-mem-running-thread-exit^M ... followed a bit later by: ... (gdb) file access-mem-running-thread-exit^M Reading symbols from access-mem-running-thread-exit...^M gdb/dwarf2/read.c:7284: internal-error: create_all_units: \ Assertion `per_objfile->per_bfd->all_units.empty ()' failed.^M ... The problem is that create_units does not catch the error thrown by dwarf2_get_dwz_file. Fix this by catching the error and performing the necessary cleanup, getting the same result for the first and second file command. PR symtab/29805 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29805
2022-11-26Fix jump on uninit producer_is_clang bit of cu.h dwarf2_cu struct.Philippe Waroquiers1-0/+1
Valgrind reports a "jump on unitialised bit error" when running e.g. gdb.base/macro-source-path.exp (see details below). Fix this by initializing producer_is_clang member variable of dwarf2_cu. Tested on amd64/debian11 and re-running gdb.base/macro-source-path.exp under valgrind. ==2140965== Conditional jump or move depends on uninitialised value(s) ==2140965== at 0x5211F7: dwarf_decode_macro_bytes(dwarf2_per_objfile*, buildsym_compunit*, bfd*, unsigned char const*, unsigned char const*, macro_source_file*, line_header const*, dwarf2_section_info const*, int, int, unsigned int, dwarf2_section_info*, dwarf2_section_info*, gdb::optional<unsigned long>, htab*, dwarf2_cu*) (macro.c:676) ==2140965== by 0x52158A: dwarf_decode_macros(dwarf2_per_objfile*, buildsym_compunit*, dwarf2_section_info const*, line_header const*, unsigned int, unsigned int, dwarf2_section_info*, dwarf2_section_info*, gdb::optional<unsigned long>, int, dwarf2_cu*) (macro.c:967) ==2140965== by 0x523BC4: dwarf_decode_macros(dwarf2_cu*, unsigned int, int) (read.c:23379) ==2140965== by 0x552AB5: read_file_scope(die_info*, dwarf2_cu*) (read.c:9687) ==2140965== by 0x54F7B2: process_die(die_info*, dwarf2_cu*) (read.c:8660) ==2140965== by 0x5569C7: process_full_comp_unit (read.c:8429) ==2140965== by 0x5569C7: process_queue (read.c:7675) ==2140965== by 0x5569C7: dw2_do_instantiate_symtab (read.c:2063) ==2140965== by 0x5569C7: dw2_instantiate_symtab(dwarf2_per_cu_data*, dwarf2_per_objfile*, bool) (read.c:2085) ==2140965== by 0x55700B: dw2_expand_symtabs_matching_one(dwarf2_per_cu_data*, dwarf2_per_objfile*, gdb::function_view<bool (char const*, bool)>, gdb::function_view<bool (compunit_symtab*)>) (read.c:3984) ==2140965== by 0x557EA3: cooked_index_functions::expand_symtabs_matching(objfile*, gdb::function_view<bool (char const*, bool)>, lookup_name_info const*, gdb::function_view<bool (char const*)>, gdb::function_view<bool (compunit_symtab*)>, enum_flags<block_search_flag_values>, domain_enum, search_domain) (read.c:18781) ==2140965== by 0x778977: objfile::lookup_symbol(block_enum, char const*, domain_enum) (symfile-debug.c:276) .... ==2140965== Uninitialised value was created by a heap allocation ==2140965== at 0x4839F01: operator new(unsigned long) (vg_replace_malloc.c:434) ==2140965== by 0x533A64: cutu_reader::cutu_reader(dwarf2_per_cu_data*, dwarf2_per_objfile*, abbrev_table*, dwarf2_cu*, bool, abbrev_cache*) (read.c:6264) ==2140965== by 0x5340C2: load_full_comp_unit(dwarf2_per_cu_data*, dwarf2_per_objfile*, dwarf2_cu*, bool, language) (read.c:7729) ==2140965== by 0x548338: load_cu(dwarf2_per_cu_data*, dwarf2_per_objfile*, bool) (read.c:2021) ==2140965== by 0x55634C: dw2_do_instantiate_symtab (read.c:2048) ==2140965== by 0x55634C: dw2_instantiate_symtab(dwarf2_per_cu_data*, dwarf2_per_objfile*, bool) (read.c:2085) ==2140965== by 0x55700B: dw2_expand_symtabs_matching_one(dwarf2_per_cu_data*, dwarf2_per_objfile*, gdb::function_view<bool (char const*, bool)>, gdb::function_view<bool (compunit_symtab*)>) (read.c:3984) ==2140965== by 0x557EA3: cooked_index_functions::expand_symtabs_matching(objfile*, gdb::function_view<bool (char const*, bool)>, lookup_name_info const*, gdb::function_view<bool (char const*)>, gdb::function_view<bool (compunit_symtab*)>, enum_flags<block_search_flag_values>, domain_enum, search_domain) (read.c:18781) ==2140965== by 0x778977: objfile::lookup_symbol(block_enum, char const*, domain_enum) (symfile-debug.c:276) ....
2022-11-26remove the declared but undefined/unused method find_partial_diePhilippe Waroquiers1-2/+0
The method struct partial_die_info *find_partial_die (sect_offset sect_off); in cu.h is defined, but is used nowhere and not implemented.
2022-11-26Automatic date update in version.inGDB Administrator1-1/+1
2022-11-25Revert "readelf: Do not require EI_OSABI for IFUNC."Martin Liska1-3/+5
This reverts commit ffbbab0b3a1000f862b6d4ce3d9a76ed14f08801.
2022-11-25riscv: Add AIA extension support (Smaia, Ssaia)Christoph Müllner14-0/+954
This commit adds the AIA extensions (Smaia and Ssaia) CSRs. bfd/ChangeLog: * elfxx-riscv.c: Add 'smaia' and 'ssaia' to the list of known standard extensions. gas/ChangeLog: * config/tc-riscv.c (enum riscv_csr_class): (riscv_csr_address): Add CSR classes for Smaia/Ssaia. * testsuite/gas/riscv/csr-dw-regnums.d: Add new CSRs. * testsuite/gas/riscv/csr-dw-regnums.s: Likewise. * testsuite/gas/riscv/csr-version-1p10.d: Likewise. * testsuite/gas/riscv/csr-version-1p10.l: Likewise. * testsuite/gas/riscv/csr-version-1p11.d: Likewise. * testsuite/gas/riscv/csr-version-1p11.l: Likewise. * testsuite/gas/riscv/csr-version-1p12.d: Likewise. * testsuite/gas/riscv/csr-version-1p12.l: Likewise. * testsuite/gas/riscv/csr-version-1p9p1.d: Likewise. * testsuite/gas/riscv/csr-version-1p9p1.l: Likewise. * testsuite/gas/riscv/csr.s: Likewise. include/ChangeLog: * opcode/riscv-opc.h (CSR_MISELECT): New CSR macro. (CSR_MIREG): Likewise. (CSR_MTOPEI): Likewise. (CSR_MTOPI): Likewise. (CSR_MVIEN): Likewise. (CSR_MVIP): Likewise. (CSR_MIDELEGH): Likewise. (CSR_MIEH): Likewise. (CSR_MVIENH): Likewise. (CSR_MVIPH): Likewise. (CSR_MIPH): Likewise. (CSR_SISELECT): Likewise. (CSR_SIREG): Likewise. (CSR_STOPEI): Likewise. (CSR_STOPI): Likewise. (CSR_SIEH): Likewise. (CSR_SIPH): Likewise. (CSR_HVIEN): Likewise. (CSR_HVICTL): Likewise. (CSR_HVIPRIO1): Likewise. (CSR_HVIPRIO2): Likewise. (CSR_VSISELECT): Likewise. (CSR_VSIREG): Likewise. (CSR_VSTOPEI): Likewise. (CSR_VSTOPI): Likewise. (CSR_HIDELEGH): Likewise. (CSR_HVIENH): Likewise. (CSR_HVIPH): Likewise. (CSR_HVIPRIO1H): Likewise. (CSR_HVIPRIO2H): Likewise. (CSR_VSIEH): Likewise. (CSR_VSIPH): Likewise. (DECLARE_CSR): Add CSRs for Smaia and Ssaia. Changes for v3: - Imply ssaia for smaia - Imply zicsr for ssaia (and transitively smaia) - Move hypervisor CSRs to Ssaia+H - Rebase on upstream/master Changes for v2: - Add hypervisor and VS CSRs - Fix whitespace issue Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
2022-11-25Automatic date update in version.inGDB Administrator1-1/+1
2022-11-24sframe/doc: remove usage of xrefautomaticsectiontitleIndu Bhagat1-5/+2
xrefautomaticsectiontitle appears to be available from texinfo 5.0 or greater. As such, it is not worthwhile to add requirement for a minimum necessary makeinfo version. So remove the usage of it. Also align node name with section title where possible. ChangeLog: * libsframe/doc/sframe-spec.texi: Remove usage of xrefautomaticsectiontitle.
2022-11-24gdb: fix typo in debug output messageAndrew Burgess1-1/+1
Spotted a minor type, a missing ')', in a debug message.
2022-11-24gdb/testsuite/gdb.base/break.exp: split test_breakSimon Marchi1-307/+293
Move all the remaining tests to a single test_break proc. It's a bit big, but all of these are kind of tied together. The procs starts by setting breakpoints, checks that we can see them in "info breakpoints", and tries stopping on them. Move all the "set bp_locationX" calls together at the top. Change-Id: Id05f98957e1a3462532d2dbd577cd0a7c7263900 Approved-By: Kevin Buettner <kevinb@redhat.com>
2022-11-24gdb/testsuite/gdb.base/break.exp: split test_tbreakSimon Marchi1-46/+36
Leave setting bp_location11 in the global scope, so that it's accessible to other procs. Change-Id: I8928f01640d3a1e993649b2168b9eda0724ee1d9 Approved-By: Kevin Buettner <kevinb@redhat.com>
2022-11-24gdb/testsuite/gdb.base/break.exp: split test_no_break_on_catchpointSimon Marchi1-11/+17
Change-Id: Ifa7070943f1de22c2839fedf5f346d6591bb5a76 Approved-By: Kevin Buettner <kevinb@redhat.com>
2022-11-24gdb/testsuite/gdb.base/break.exp: split test_break_nonexistent_lineSimon Marchi1-5/+15
Change-Id: I4390dd5da23bae83ccc513ad0de0169ddff7df12 Approved-By: Kevin Buettner <kevinb@redhat.com>
2022-11-24gdb/testsuite/gdb.base/break.exp: split test_break_defaultSimon Marchi1-25/+37
One special thing here is that the part just above this one, that sets catchpoints and verifies they are not hit, requires that we resume execution to verify that the catchpoints are indeed not hit. I guess it was previously achieved by the until command, but it doesn't happen now that the until is moved into test_break_default. Add a gdb_continue_to_end after setting the catchpoints. If any catchpoint were to be hit, it would catch the problem. Change-Id: I5d4b43da91886b1beda9f6e56b05aa04331a9c05 Approved-By: Kevin Buettner <kevinb@redhat.com>
2022-11-24gdb/testsuite/gdb.base/break.exp: split test_break_silent_and_moreSimon Marchi1-56/+62
This one is a bit tricky. The clear tests seem to depend on the various breakpoints that have been set before, starting with the "silent" breakpoints. So, move all this in a single chunk, it can always be split later if needed. Change-Id: I7ba61a5b130ade63eda0c4790534840339f8a72f Approved-By: Kevin Buettner <kevinb@redhat.com>
2022-11-24gdb/testsuite/gdb.base/break.exp: split test_break_line_convenience_varSimon Marchi1-5/+11
Change-Id: I593002373da971a0a4d6b5355d3fe321873479ab Approved-By: Kevin Buettner <kevinb@redhat.com>
2022-11-24gdb/testsuite/gdb.base/break.exp: split test_break_user_callSimon Marchi1-22/+32
Change-Id: I9151ce9db9435722b758f41c6606b461bf15f320 Approved-By: Kevin Buettner <kevinb@redhat.com>
2022-11-24gdb/testsuite/gdb.base/break.exp: split test_finish_argumentsSimon Marchi1-22/+28
Change-Id: Id84babed1eeb3ce7d14b94ff332795964e8ead51 Approved-By: Kevin Buettner <kevinb@redhat.com>
2022-11-24gdb/testsuite/gdb.base/break.exp: use proc_with_prefix for ↵Simon Marchi1-1/+1
test_next_with_recursion This one is already in a proc, just make the proc use proc_with_prefix, for consistency. Change-Id: I313ecf5097ff04526c29396529baeba84e37df5a Approved-By: Kevin Buettner <kevinb@redhat.com>
2022-11-24gdb/testsuite/gdb.base/break.exp: split test_break_optimized_prologueSimon Marchi1-51/+48
Change-Id: Ibf17033c8ce72aa5cfe1b739be2902e84a5e945d Approved-By: Kevin Buettner <kevinb@redhat.com>
2022-11-24gdb/testsuite/gdb.base/break.exp: split test_rbreak_shlibSimon Marchi1-18/+18
Change-Id: I130e8914c2713095aab03e84aba1481b4c7af978 Approved-By: Kevin Buettner <kevinb@redhat.com>
2022-11-24gdb/testsuite/gdb.base/break.exp: split test_break_file_line_convenience_varSimon Marchi1-6/+8
Change-Id: I0c31b037669b2917e062bf431372fb6531f8f53c Approved-By: Kevin Buettner <kevinb@redhat.com>
2022-11-24gdb/testsuite/gdb.base/break.exp: split test_break_commands_clearSimon Marchi1-8/+16
Change-Id: Ia58f90117d52fc419fc494836d9b4ed5d902fe9b Approved-By: Kevin Buettner <kevinb@redhat.com>
2022-11-24Impport libiberty commit: 885b6660c17f from gcc mainline. Fix gas's ↵Nick Clifton4-6/+24
acinclude.m4 to stop a potwntial configure time warning message.
2022-11-24readelf: Do not require EI_OSABI for IFUNC.Martin Liska1-5/+3
PR 29718 binutils/ChangeLog: * readelf.c (get_symbol_type): Consider STT_GNU_IFUNC as reserved name.
2022-11-24x86: widen applicability and use of CheckRegSizeJan Beulich5-23/+79
First of all make operand_type_register_match() apply to all sized operands, i.e. in Intel Syntax also to respective memory ones. This addresses gas wrongly accepting certain SIMD insns where register and memory operand sizes should match but don't. This apparently has affected all templates with one memory-only operand and one or more register ones, both permitting at least two sizes, due to CheckRegSize not taking effect. Then also add CheckRegSize to a couple of non-SIMD templates matching that same pattern of memory-only vs register operands. This replaces bogus (for Intel Syntax) diagnostics referring to a wrong suffix (when none was used at all) by "type mismatch" ones, just like already emitted for insns where the template allows a register operand alongside a memory one at any particular position. This also is a prereq to limiting (ideally eliminating in the long run) suffix "derivation" in Intel Syntax mode. While making the code adjustment also flip order of checks to do the cheaper one first in both cases.
2022-11-24x86: add missing CheckRegSizeJan Beulich2-6/+6
To properly and predictably determine operand size encoding (operand size or REX.W prefixes), consistent operand sizes need to be specified. Add CheckRegSize where this was previously missing.
2022-11-24x86: correct handling of LAR and LSLJan Beulich9-26/+116
Both uniformly only ever take 16-bit memory operands while at the same time requiring matching (in size) register operands, which then also should disassemble that way. This in particular requires splitting each of the templates for the assembler and separating decode of the register and memory forms in the disassembler.
2022-11-24Tidy objdump printing of section sizeAlan Modra1-2/+2
* objdump.c (load_specific_debug_section): Use PRIx64 format.
2022-11-24Constify nm format arrayAlan Modra1-2/+2
* nm.c (formats, format): Make const.
generated by cgit v1.1 at 2025-09-23 05:05:44 +0000