aboutsummaryrefslogtreecommitdiff
path: root/gdb
AgeCommit message (Collapse)AuthorFilesLines
2025-03-11Use gdb map in py-connection.cTom Tromey1-4/+3
This changes py-connection.c to use gdb::unordered_map. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2025-03-11Use gdb set in dwarf2/aranges.cTom Tromey1-1/+1
This changes dwarf2/aranges.c to use gdb::unordered_set. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2025-03-11Use gdb set in all_non_exited_process_targetsTom Tromey2-4/+5
This changes all_non_exited_process_targets to return gdb::unordered_set. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2025-03-11Use gdb set and map in remote.cTom Tromey1-3/+2
This changes remote.c to use gdb::unordered_set and gdb::unordered_map. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2025-03-11Use gdb set and map in mi-main.cTom Tromey1-7/+7
This changes mi-main.c to use gdb::unordered_set and gdb::unordered_map. this may change the order of core ids that are emitted, but that seems fine as MI generally doesn't guarantee ordering. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2025-03-11Use gdb::function_view in iterate_over_threadsTom Tromey9-128/+66
This C++-ifies iterate_over_threads, changing it to accept a gdb::function_view and to return bool. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2025-03-11Use gdb set and map in TUITom Tromey2-5/+4
This changes the TUI to use gdb::unordered_map and gdb::unordered_set rather than the std:: variants. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2025-03-11Use gdb set and map in source_cacheTom Tromey1-4/+4
This changes source_cache to use gdb::unordered_map and gdb::unordered_set rather than the std:: variants. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2025-03-11[gdb/testsuite] Fix gdb.base/step-over-syscall.exp with glibc 2.41Tom de Vries1-7/+17
On openSUSE Tumbleweed, with glibc 2.41, when running test-case gdb.base/step-over-syscall.exp I run into: ... (gdb) stepi^M 0x00007ffff7cfd09b in __abort_lock_rdlock () from /lib64/libc.so.6^M 1: x/i $pc^M => 0x7ffff7cfd09b <__abort_lock_rdlock+29>: syscall^M (gdb) p $eax^M $1 = 14^M (gdb) FAIL: $exp: fork: displaced=off: syscall number matches FAIL: $exp: fork: displaced=off: find syscall insn in fork (timeout) ... We're stepi-ing through fork trying to find the fork syscall, but encounter another syscall. The test-case attempts to handle this: ... gdb_test_multiple "stepi" "find syscall insn in $syscall" { -re ".*$syscall_insn.*$gdb_prompt $" { # Is the syscall number the correct one? if {[syscall_number_matches $syscall]} { pass $gdb_test_name } else { exp_continue } } -re "x/i .*=>.*\r\n$gdb_prompt $" { incr steps if {$steps == $max_steps} { fail $gdb_test_name } else { send_gdb "stepi\n" exp_continue } } } ... but fails to do so because it issues an exp_continue without issuing a new stepi command, and consequently the "find syscall insn in fork" test times out. Also, the call to syscall_number_matches produces a PASS or FAIL, so skipping one syscall would produce: ... FAIL: $exp: fork: displaced=off: syscall number matches PASS: $exp: fork: displaced=off: syscall number matches DUPLICATE: $exp: fork: displaced=off: syscall number matches ... Fix this by: - not producing PASS or FAIL in syscall_number_matches, and - issuing stepi when encountering another syscall. While we're at it, fix indentation in syscall_number_matches. Tested on x86_64-linux, specifically: - openSUSE Tumbleweed (glibc 2.41), and - openSUSE Leap 15.6 (glibc 2.38). PR testsuite/32780 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32780
2025-03-10Remove pid from test name in gcore-memory-usage.expTom Tromey1-1/+1
The new gcore-memory-usage.exp test puts a PID into a test case name, causing spurious comparison failures. This patch changes the test name to avoid this.
2025-03-10Add string cache and use it in cooked indexTom Tromey2-13/+6
The cooked index needs to allocate names in some cases -- when canonicalizing or when synthesizing Ada package names. This process currently uses a vector of unique_ptrs to manage the memory. Another series I'm writing adds another spot where this allocation must be done, and examining the result showed that certain names were allocated multiple times. To clean this up, this patch introduces a string cache object and changes the cooked indexer to use it. I considered using bcache here, but bcache doesn't work as nicely with string_view -- because bcache is fundamentally memory-based, a temporary copy of the contents must be made to ensure that bcache can see the trailing \0. Furthermore, writing a custom class lets us avoid another copy when canonicalizing C++ names. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2025-03-10Revert past commitsSimon Marchi14-544/+329
I accidentally pushed my work-in-progress branch... revert that. Sorry for the noise :(. The list of commits reverted are: ae2a50a9ae15 attempt to revamp to the CU/TU list e9386435c94f gdb/dwarf: print DWARF CUs/TUs in "maint print objfiles" 6cbd64aa3eb0 gdb/dwarf: add dwarf_source_language_name 32a187da7622 libiberty: move DW_LANG_* definitions to dwarf2.def b3fa38aef59d gdb/dwarf: move index unit vectors to debug names reader and use them 30ba74418982 gdb/dwarf: track comp and type units count bedb4e09f292 gdb/dwarf: remove unnecessary braces b4f18de12c77 gdb/dwarf: use ranged for loop in some pots Change-Id: I80aed2847025f5b15c16c997680783b39858a703
2025-03-10attempt to revamp to the CU/TU listSimon Marchi11-224/+394
Change-Id: I1c8214413583d540c10c9a2322ef2a21f8bb54e7
2025-03-10gdb/dwarf: print DWARF CUs/TUs in "maint print objfiles"Simon Marchi2-7/+55
This was useful to me, to debug some problems. Before printing cooked index entries, print a list of CUs and TUs. The information printed for each is a bit arbitrary, I took a look at the types and printed what seemed relevant. An example of output for a CU: [0] ((dwarf2_per_cu_data *) 0x50f000007840) type: DW_UT_compile offset: 0x0 size: 0x1bff artificial: false GDB lang: c++ DWARF lang: DW_LANG_C_plus_plus And for a TU: [2] ((signatured_type *) 0x511000040000) type: DW_UT_type offset: 0x0 size: 0x94 signature: 0x2e966c0dc94b065b I moved the call to cooked_index_functions::wait before printing the CU/TU list, otherwise trying to call "maint print objfiles" quickly, like this, would lead to an internal error: $ ./gdb -nx -q --data-directory=data-directory testsuite/outputs/gdb.dwarf2/struct-with-sig/struct-with-sig -ex "maint print objfiles" This is because dwarf2_per_cu_data::m_unit_type was not yet set, when trying to read it. Waiting for the index to be built ensures that it is set, since setting the unit type is done as a side-effect somewhere. Change-Id: Ic810ec3bb4d3f5abb481cf1cee9b2954ff4f0874
2025-03-10gdb/dwarf: add dwarf_source_language_nameSimon Marchi2-0/+16
Add dwarf_source_language_name, to convert a DW_LANG_* constant to string. This will be used in a following patch. Change-Id: I552ebd318e2e770d590de5920edbd0b75075c1b7 Approved-By: Tom Tromey <tom@tromey.com>
2025-03-10gdb/dwarf: move index unit vectors to debug names reader and use themSimon Marchi2-87/+72
Since these vectors contain the CU and TU lists as found in the .debug_names header, it seems like they are meant to be used by the .debug_names reader when handling a DW_IDX_compile_unit or DW_IDX_type_unit attribute. The value of the attribute would translate directly into an index into one of these vectors. However there's something fishy: it looks like these vectors aren't actually used in practice. They are used in the dwarf2_per_bfd::get_index_{c,t}u methods, which in turn aren't used anywhere. The handlers of DW_IDX_compile_unit and DW_IDX_type_unit use the dwarf2_per_bfd::get_cu method, assuming that all compile units are placed before type units in the dwarf2_per_bfd::all_units vector. I see several problems with that: 1. I found out [1] that the dwarf2_per_bfd::all_units didn't always have the CUs before the TUs. So indexing dwarf2_per_bfd::all_units with that assumption will not work. 2. The dwarf2_find_containing_comp_unit function assumes an ordering of units by section offset (among other criteria) in order to do a binary search. Even though it's probably commonly the case, nothing guarantees that the order of CUs and TUs in the .debug_names header (which defines the indices used to refer to them) will be sorted by section offset. It's not possible to make dwarf2_find_containing_comp_unit (assuming it wants to do a binary search by section offset) and the DW_IDX_compile_unit / DW_IDX_type_unit handlers use the same vector. 3. I have not tested this, but in the presence of a dwz supplementary file, the .debug_names reader should probably not put the units from the main and dwz files in the same vectors to look them up by index. Presumably, if both the main and dwz files have a .debug_names index, they have distinct CU / TU lists. So, an CU index of 1 in an index entry in the main file would refer to a different CU than an index of 1 in an index entry in the dwz file. The current code doesn't seem to account for that, it just indexes dwarf2_per_bfd::all_units. Since those vectors are kind of specific to the .debug_names reader, move them there, in the mapped_debug_names_reader struct. Then, update the handlers of DW_IDX_compile_unit and DW_IDX_type_unit to use them. [1] https://inbox.sourceware.org/gdb-patches/87a5ab5i5m.fsf@tromey.com/T/#mbdcfe35f94db33e59500eb0d3d225661cab016a4 Change-Id: I3958d70bb3875268143471da745aa09336ab2500
2025-03-10gdb/dwarf: track comp and type units countSimon Marchi2-8/+11
A subsequent commit will remove the all_comp_units and all_type_units array views, since the all_units vector will no longer be segmented between comp and type units. Some callers still need to know the number of each kind, so track that separately. Change-Id: I6ef184767a96e5be095bbf9142aa850adbb083ac
2025-03-10gdb/dwarf: remove unnecessary bracesSimon Marchi1-9/+8
Change-Id: If0b38b860e79771a16ea914af3e337fca0ee3a7d
2025-03-10gdb/dwarf: use ranged for loop in some potsSimon Marchi2-13/+7
I noticed that these loops could be written to avoid the iteration variable `i`. Change-Id: Ia3717acbbf732f0337870d35ac60fe6400383324
2025-03-10gdb/dwarf: save DWARF version in dwarf2_loclist_baton, remove it from ↵Simon Marchi4-38/+12
dwarf2_per_cu When running: $ make check TESTS="gdb.cp/cpexprs-debug-types.exp" RUNTESTFLAGS="--target_board=fission" I get: (gdb) break -qualified main /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.h:295: internal-error: version: Assertion `m_dwarf_version != 0' failed. The problem is that dwarf2_per_cu objects created in the read_cutu_die_from_dwo code path never have their DWARF version set. A seemingly obvious solution would be to add a call to dwarf2_per_cu::set_version in there (there's a patch in the referenced PR that does that). However, this comment in read_comp_units_from_section is a bit scary: /* Init this asap, to avoid a data race in the set_version in cutu_reader::cutu_reader (which may be run in parallel for the cooked index case). */ this_cu->set_version (cu_header.version); I don't know if a DWO file can be read while the cooked indexer runs, so if it would be a problem here, but I prefer to be safe than sorry. This patch side-steps the problem by deleting the DWARF version from dwarf2_per_cu. The only users of dwarf2_per_cu::version are the loclists callbacks in `loc.c`. Add the DWARF version to dwarf2_loclist_baton and modify those callbacks to get the version from there instead. Initialize that new field in fill_in_loclist_baton. I like this approach because there is no version field that is possibly unset now. I wasn't keen on doing this at first because I thought it would waste space, but the dwarf2_loclist_baton has 7 bytes of padding at the end anyway, so we might as well use that. Cc: Ricky Zhou <ricky@rzhou.org> Cc: Tom de Vries <tdevries@suse.de> Cc: Tom Tromey <tom@tromey.com> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32309 Change-Id: I30d4ede7d67da5d80ff65c6122f5868e1098ec52 Approved-By: Tom Tromey <tom@tromey.com>
2025-03-10Use flags enum for cooked_index_entry::full_nameTom Tromey5-30/+50
I found a small bug coming from a couple of recent patches of mine for cooked_index_entry::full_name. First, commit aab26529b30 (Add "Ada linkage" mode to cooked_index_entry::full_name) added a small hack to optionally compute the Ada linkage name. Then, commit aab2ac34d7f (Avoid excessive CU expansion on failed matches) changed the relevant expand_symtabs_matching implementation to use this feature. However, the feature was used unconditionally, causing a bad side effect: the non-canonical name is now used for all languages, not just Ada. But, for C++ this is wrong. Furthermore, consider the declaration of full_name: const char *full_name (struct obstack *storage, bool for_main = false, bool for_ada_linkage = false, const char *default_sep = nullptr) const; ... and then consider this call in cooked_index::dump: gdb_printf (" qualified: %s\n", entry->full_name (&temp_storage, false, "::")); Oops! The "::" is silently converted to 'true' here. To fix both of these problems, this patch changes full_name to accept a flags enum rather than booleans. This avoids the type-safety problem. Then, full_name is changed to remove the "Ada" flag when the entry is not in fact an Ada symbol. Regression tested on x86-64 Fedora 40. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2025-03-10Remove eval_op_scopeTom Tromey2-30/+20
eval_op_scope is very similar to scope_operation::evaluate_for_address. This patch combines the two into a single method of scope_operation. Regression tested on x86-64 Fedora 40. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2025-03-10gdb/dwarf: rename comp_unit_die to top_level_dieSimon Marchi3-42/+42
The name "comp_unit_die" is a bit misleading, because it can also represent a type unit (DW_TAG_type_unit). I think that "top_level_die" is clear. Change-Id: Ibaac99897f0ac7499f0f82caeed3385e1e6ee870 Approved-By: Tom Tromey <tom@tromey.com>
2025-03-10gdb/dwarf: add doc for cutu_reader::is_dummySimon Marchi1-0/+5
Change-Id: Ifb80557187c12822bdea7ad400c32c3dce968a7f Approved-By: Tom Tromey <tom@tromey.com>
2025-03-10Fix check-include-guards.pyTom Tromey8-27/+34
I noticed that check-include-guards.py doesn't error in certain situations -- but in situations where the --update flag would cause a file to be changed. This patch changes the script to issue an error for any discrepancy. It also fixes the headers that weren't correct. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2025-03-09Fix segfault if target_fileio_read_alloc failsBrandon Belew1-5/+5
Check for target_fileio_read_alloc failure in linux_fill_prpsinfo before dereferencing buffer. This fixes a segfault in the 'gcore' command when attached to certain remote targets. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32441 Approved-By: Andrew Burgess <aburgess@redhat.com>
2025-03-08[gdb/testsuite] Fix gdb.base/step-over-syscall.exp with -m32 for AMDTom de Vries1-1/+1
When running test-case gdb.base/step-over-syscall.exp with target board unix/-m32 on an AMD processor, I run into: ... (gdb) x/2i $pc^M => 0xf7fc9575 <__kernel_vsyscall+5>: syscall^M 0xf7fc9577 <__kernel_vsyscall+7>: int $0x80^M (gdb) PASS: $exp: fork: displaced=off: pc before/after syscall instruction stepi^M [Detaching after fork from child process 65650]^M 0xf7fc9579 in __kernel_vsyscall ()^M 1: x/i $pc^M => 0xf7fc9579 <__kernel_vsyscall+9>: pop %ebp^M (gdb) $exp: fork: displaced=off: stepi fork insn print /x $pc^M $2 = 0xf7fc9579^M (gdb) PASS: gdb.base/step-over-syscall.exp: fork: displaced=off: pc after stepi FAIL: $exp: fork: displaced=off: pc after stepi matches insn addr after syscall ... The problem is that the syscall returns at the "pop %ebp" insn, while the test-case expects it to return at the "int $0x80" insn. This is similar to the problem I fixed in commit 14852123287 ("[gdb/testsuite] Fix gdb.base/step-over-syscall.exp with -m32"), just that the syscall sequence used there used the "sysenter" insn instead of the "syscall" insn. Fix this by extending the fix for commit 14852123287 to also handle the "syscall" insn. Tested on x86_64-linux, both using an AMD and Intel processor. PR testsuite/32439 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32439
2025-03-07gdb/dwarf: call other cutu_reader constructor in ensure_lang and ↵Simon Marchi2-13/+14
dw2_get_file_names PR 32742 shows this failing: $ make check TESTS="gdb.ada/access_to_unbounded_array.exp" RUNTESTFLAGS="--target_board=fission" Running /home/simark/src/binutils-gdb/gdb/testsuite/gdb.ada/access_to_unbounded_array.exp ... FAIL: gdb.ada/access_to_unbounded_array.exp: scenario=all: gdb_breakpoint: set breakpoint at foo.adb:23 (GDB internal error) Or, interactively: $ ./gdb -q -nx --data-directory=data-directory testsuite/outputs/gdb.ada/access_to_unbounded_array/foo-all -ex 'b foo.adb:23' -batch /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:19567: internal-error: set_lang: Assertion `old_value == language_unknown || old_value == language_minimal || old_value == lang' failed. The symptom is that for a given dwarf2_per_cu, the language gets set twice. First, set to `language_ada`, and then, to `language_minimal`. It's unexpected for the language of a CU to get changed like this. The CU at offset 0x0 in the main file looks like: 0x00000000: Compile Unit: length = 0x00000030, format = DWARF32, version = 0x0004, abbr_offset = 0x0000, addr_size = 0x08 (next unit at 0x00000034) 0x0000000b: DW_TAG_compile_unit DW_AT_low_pc [DW_FORM_addr] (0x000000000000339a) DW_AT_high_pc [DW_FORM_data8] (0x0000000000000432) DW_AT_stmt_list [DW_FORM_sec_offset] (0x00000000) DW_AT_GNU_dwo_name [DW_FORM_strp] ("b~foo.dwo") DW_AT_comp_dir [DW_FORM_strp] ("/home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.ada/access_to_unbounded_array") DW_AT_GNU_pubnames [DW_FORM_flag_present] (true) DW_AT_GNU_addr_base [DW_FORM_sec_offset] (0x00000000) DW_AT_GNU_dwo_id [DW_FORM_data8] (0x277aee54e7bd47f7) This refers to the DWO file b~foo.dwo, whose top-level DIE is: .debug_info.dwo contents: 0x00000000: Compile Unit: length = 0x00000b63, format = DWARF32, version = 0x0004, abbr_offset = 0x0000, addr_size = 0x08 (next unit at 0x00000b67) 0x0000000b: DW_TAG_compile_unit DW_AT_producer [DW_FORM_GNU_str_index] ("GNU Ada 14.2.1 20250207 -fgnat-encodings=minimal -gdwarf-4 -fdebug-types-section -fuse-ld=gold -gnatA -gnatWb -gnatiw -gdwarf-4 -gsplit-dwarf -ggnu-pubnames -gnatws -mtune=generic -march=x86-64") DW_AT_language [DW_FORM_data1] (DW_LANG_Ada95) DW_AT_name [DW_FORM_GNU_str_index] ("/home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.ada/access_to_unbounded_array/b~foo.adb") DW_AT_comp_dir [DW_FORM_GNU_str_index] ("/home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.ada/access_to_unbounded_array") DW_AT_GNU_dwo_id [DW_FORM_data8] (0xdbeffefab180a2cb) The thing to note is that the language attribute is only present in the DIE in the DWO file, not on the DIE in the main file. The first time the language gets set is here: #0 dwarf2_per_cu::set_lang (this=0x50f0000044b0, lang=language_ada, dw_lang=DW_LANG_Ada95) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:20788 #1 0x0000555561666af6 in cutu_reader::prepare_one_comp_unit (this=0x7ffff10bf2b0, cu=0x51700008e000, pretend_language=language_minimal) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:21029 #2 0x000055556159f740 in cutu_reader::cutu_reader (this=0x7ffff10bf2b0, this_cu=0x50f0000044b0, per_objfile=0x516000066080, abbrev_table=0x510000004640, existing_cu=0x0, skip_partial=false, pretend_language=language_minimal, cache=0x7ffff11b95e0) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:3371 #3 0x00005555615a547a in process_psymtab_comp_unit (this_cu=0x50f0000044b0, per_objfile=0x516000066080, storage=0x7ffff11b95e0) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:3799 #4 0x00005555615a9292 in cooked_index_worker_debug_info::process_cus (this=0x51700008dc80, task_number=0, first=std::unique_ptr<dwarf2_per_cu> = {...}, end=std::unique_ptr<dwarf2_per_cu> = {...}) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:4122 In this code path (particularly this specific cutu_reader constructir), the work is done to find and read the DWO file. So the language is properly identifier as language_ada, all good so far. The second time the language gets set is: #0 dwarf2_per_cu::set_lang (this=0x50f0000044b0, lang=language_minimal, dw_lang=0) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:20788 #1 0x0000555561666af6 in cutu_reader::prepare_one_comp_unit (this=0x7ffff0f42730, cu=0x517000091b80, pretend_language=language_minimal) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:21029 #2 0x00005555615a1822 in cutu_reader::cutu_reader (this=0x7ffff0f42730, this_cu=0x50f0000044b0, per_objfile=0x516000066080, pretend_language=language_minimal, parent_cu=0x0, dwo_file=0x0) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:3464 #3 0x000055556158c850 in dw2_get_file_names (this_cu=0x50f0000044b0, per_objfile=0x516000066080) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:1956 #4 0x000055556158f4f5 in dw_expand_symtabs_matching_file_matcher (per_objfile=0x516000066080, file_matcher=...) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:2157 #5 0x00005555616329e2 in cooked_index_functions::expand_symtabs_matching (this=0x50200002ab50, objfile=0x516000065780, file_matcher=..., lookup_name=0x0, symbol_matcher=..., expansion_notify=..., search_flags=..., domain=..., lang_matcher=...) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:15912 #6 0x0000555562ca8a14 in objfile::map_symtabs_matching_filename (this=0x516000065780, name=0x50200002ad90 "break pck.adb", real_path=0x0, callback=...) at /home/smarchi/src/binutils-gdb/gdb/symfile-debug.c:207 #7 0x0000555562d68775 in iterate_over_symtabs (pspace=0x513000005600, name=0x50200002ad90 "break pck.adb", callback=...) at /home/smarchi/src/binutils-gdb/gdb/symtab.c:727 Here, we use the other cutu_reader constructor, the one that does not look up the DWO file for the passed CU. If a DWO file exists for this CU, the caller is expected to pass it as a parameter. That cutu_reader constructor also ends up setting the language of the CU. But because it didn't read the DWO file, it didn't figure out the language is language_ada, so it tries to set the language to the default, language_minimal. A question is: why do we end up trying to set the CU's language is this context. This is completely unrelated to what we're trying to do, that is get the file names from the line table. Setting the language is a side-effect of just constructing a cutu_reader, which we need to look up attributes in dw2_get_file_names_reader. There are probably some cleanups to be done here, to avoid doing useless work like looking up and setting the CU's language when all we need is an object to help reading the DIEs and attributes. But that is future work. The same cutu_reader constructor is used in `dwarf2_per_cu::ensure_lang`. Since this is the version of cutu_reader that does not look up the DWO file, it will conclude that the language is language_minimal and set that as the CU's language. In other words, `dwarf2_per_cu::ensure_lang` will get the language wrong, pretty ironic. Fix this by using the other cutu_reader constructor in those two spots. Pass `per_objfile->get_cu (this_cu)`, as the `existing_cu` parameter. I think this is necessary, because that constructor has an assert to check that if `existing_cu` is nullptr, then there must not be an existing `dwarf2_cu` in the per_objfile. To avoid getting things wrong like this, I think that the second cutu_reader constructor should be reserved for the spots that do pass a non-nullptr dwo_file. The only spot at the moment in create_cus_hash_table, where we read multiple units from the same DWO file. In this context, I guess it makes sense for efficiency to get the dwo_file once and pass it down to cutu_reader. For that constructor, make the parameters non-optional, add "non-nullptr" asserts, and update the code to assume the passed values are not nullptr. What I don't know is if this change is problematic thread-wise, if the functions I have modified to use the other cutu_reader constructor can be called concurrently in worker threads. If so, I think it would be problematic. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32742 Change-Id: I980d16875b9a43ab90e251504714d0d41165c7c8 Approved-By: Tom Tromey <tom@tromey.com>
2025-03-07Avoid excessive CU expansion on failed matchesTom Tromey2-22/+66
PR symtab/31010 points out that something like "ptype INT" will expand all CUs in a typical program. The OP further points out that the original patch for PR symtab/30520: https://sourceware.org/pipermail/gdb-patches/2024-January/205924.html ... did solve the problem, but the patch changed after (my) review and reintroduced the bug. In cooked_index_functions::expand_symtabs_matching, the final component of a split name is compared with the entry's name using the usual method of calling get_symbol_name_matcher. This code iterates over languages and tries to split the original name according to each style. But, the Ada splitter uses the decoded name -- "int". This causes every C or C++ CU to be expanded. Clearly this is wrong. And, it seems to me that looping over languages and trying to guess the splitting style for the input text is probably bad. However, fixing the problem is not so easy (again due to Ada). I've filed a follow-up bug, PR symtab/32733, for this. Meanwhile, this patch changes the code to be closer to the originally-submitted patch. This works because the comparison is now done between the full name and the "lookup_name_without_params" object, which is a less adulterated variant of the original input. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31010 Tested-By: Simon Marchi <simon.marchi@efficios.com>
2025-03-07Use wild matching for lookup_name_info::match_anyTom Tromey1-1/+1
Currently, lookup_name_info::match_any symbol_name_match_type::FULL. However, this seems wrong. Consider the expand_symtabs_matching implementation of the cooked index: it compares name components, and then if all the components match, it checks: if ((match_type == symbol_name_match_type::FULL || (lang != language_ada && match_type == symbol_name_match_type::EXPRESSION))) { if (parent != nullptr) continue; That is, if the component-matching loop did not finish, and a full match is requested, then fail to match. This handles cases where the index is asked to look up "b::c" but finds "a::b::c". However, match_any should match, well, any. So, it seems to me that checking any parent matches is irrelevant -- and therefore this should use wild matching.
2025-03-07Handle ">>" in cp-name-parser.yTom Tromey2-0/+24
I noticed that a certain name didn't work correctly when trying to remove the parameters. I put this into lookup_name_info-selftests.c. I tracked this down to the fact that cp-name-parser.y doesn't handle ">>" to end templates. This patch fixes this in a simple way -- accepting the "RSH" token where appropriate and then un-pushing a ">".
2025-03-07Minor cleanups to cpname_stateTom Tromey1-9/+11
This changes cpname_state to have a constructor and some inline initializers.
2025-03-07gdb/dwarf: move cooked_indexer to cooked-indexer.{h,c}Simon Marchi5-825/+914
Move the cooked_indexer class declaration to a new cooked-indexer.h file, and the implementation to cooked-indexer.c. Change-Id: Ibff3b06045b2af65fa9516097acf732d7c2d9414 Approved-By: Tom Tromey <tom@tromey.com>
2025-03-07gdb/dwarf: move cooked_index_storage to cooked-index-storage.{h,c}Simon Marchi5-137/+194
cooked_index_storage is currently declared in `cooked-index.h` and implemented in `read.c`. Move all that to new `cooked-index-storage.{h,c}` files. Change-Id: I2a07eb446d8a07b15c5664dfe01e3a820cdd45be Approved-By: Tom Tromey <tom@tromey.com>
2025-03-07gdb/dwarf: move cutu_reader to read.hSimon Marchi2-146/+148
In order to move some things outside of read.c, cutu_reader needs to be in a header file. Change-Id: Ib26d7949c55867848d109332caf2efb1a6e72923 Approved-By: Tom Tromey <tom@tromey.com>
2025-03-07[gdb/tdep] Support REX2 and EVEX prefixTom de Vries1-1/+109
The following amd64 insn: ... 0: 67 d5 44 8d 3d 00 00 00 00 lea 0x0(%eip),%r31d ... uses the REX2 prefix [1], which is currently not supported in amd64_get_insn_details. Add the missing support in amd64_get_insn_details, as well as a corresponding unit test. Likewise for an amd64 insn using an EVEX prefix [2]: ... 0: 62 f1 7c 48 28 05 00 fc ff ff vmovaps -0x400(%rip),%zmm0 ... Tested on x86_64-linux. PR tdep/32725 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32725 [1] https://en.wikipedia.org/wiki/VEX_prefix [2] https://en.wikipedia.org/wiki/EVEX_prefix
2025-03-07[gdb/tdep] Fix vmovdqu decodingTom de Vries1-6/+77
PR tdep/31952 reports that displaced stepping over an instruction pointer relative insn "vmovdqu 0x20(%rip),%ymm1" gives the wrong results. This is caused by misclassification of the insn in amd64_get_insn_details, which results in details.modrm_offset == -1, while the instruction in fact does have a modrm byte. The instruction is encoded as follows: ... 400557: c5 fe 6f 0d 20 00 00 00 vmovdqu 0x20(%rip),%ymm1 ... where: - "0xc5 0xfe" is the vex2 prefix, - "0x6f" is the opcode, - "0x0d" is the modrm byte, and - "0x20 0x00 0x00 0x00" is a 32-bit displacement. The problem is related to details.opcode_len, which is 1. While it is true that the length of the opcode in the insn (0x6f) is 1 byte, the vex2 prefix implies that we're encoding an 2-byte opcode beginnning with 0x0f [1]. Consequently, we should be using the twobyte_has_modrm map rather than the onebyte_has_modrm map. Fix this in amd64_get_insn_details, and add a selftest to check this. Tested on x86_64-linux. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31952 [1] https://en.wikipedia.org/wiki/VEX_prefix
2025-03-07[gdb/tdep] Make amd64_get_insn_details more regularTom de Vries1-4/+7
In amd64_get_insn_details, I found this code with a comment explaining why enc_prefix_offset is not set: ... else if (vex2_prefix_p (*insn)) { /* Don't record the offset in this case because this prefix has no REX.B equivalent. */ insn += 2; } ... which I didn't understand until I looked at the only use of enc_prefix_offset, in fixup_riprel: ... /* REX.B should be unset (VEX.!B set) as we were using rip-relative addressing, but ensure it's unset (set for VEX) anyway, tmp_regno is not r8-r15. */ if (insn_details->enc_prefix_offset != -1) { gdb_byte *pfx = &dsc->insn_buf[insn_details->enc_prefix_offset]; if (rex_prefix_p (pfx[0])) pfx[0] &= ~REX_B; else if (vex3_prefix_p (pfx[0])) pfx[1] |= VEX3_NOT_B; else gdb_assert_not_reached ("unhandled prefix"); } ... Fix this by: - setting enc_prefix_offset for the vex2 case in amd64_get_insn_details, making the function more regular and easier to understand, and - handling the vex2 case in the "enc_prefix_offset != -1" clause in fixup_riprel. Tested on x86_64-linux.
2025-03-07[gdb/tdep] Add vzeroupper and vzeroall in amd64-insn-decode selftestTom de Vries1-0/+34
After I posted a tentative patch for PR31952, Alexander Monakov pointed out that the patch broke instruction decoding for instructions vzeroall and vzeroupper. Add selftests for these two instructions in amd64-insn-decode, both using vex2 and vex3 prefixes. Tested on x86_64-linux.
2025-03-07[gdb/tdep] Add vex2_to_vex3Tom de Vries1-0/+40
I noticed here [1] that the vex2 prefix is essentially a special case of the vex3 prefix, meaning it's possible to rewrite any insn with a vex2 prefix into an equivalent one with a vex3 prefix. Add function vex2_to_vex3 that does precisely that, in the selftests namespace. Add a selftest that exercises this function. Tested on x86_64-linux. [1] https://en.wikipedia.org/wiki/VEX_prefix
2025-03-07[gdb/tdep] Factor out part of fixup_riprelTom de Vries1-22/+37
Factor out the part of fixup_riprel that patches the insn, and use it in a unit test. Tested on x86_64-linux.
2025-03-07[gdb/tdep] Fix rip-relative insn handling in amd64_get_used_input_int_regTom de Vries1-1/+12
I wanted to add a unit test for an an rip-relative amd64 insn, so I did: ... $ gcc -fPIE hello.c ... and used an rip-relative insn from main: ... 4005db: 48 8d 3d 1e 00 00 00 lea 0x1e(%rip),%rdi ... While writing the unit test, I found that amd64_get_used_input_int_reg returns rbp as input register. Fix this by using rip_relative_p in amd64_get_used_input_int_reg to handle this case. Tested on x86_64-linux.
2025-03-07[gdb/tdep] Factor out rip_relative_pTom de Vries1-2/+14
Factor out rip_relative_p, and rewrite it to use MODRM_MOD_FIELD and MODRM_RM_FIELD. No functional changes. Tested on x86_64-linux.
2025-03-07[gdb/tdep] Add amd64-insn-decode selftestTom de Vries1-8/+63
Add a selftest that checks the results of amd64_get_insn_details and related functions for two basic instructions. Add a parameter assumptions to amd64_get_used_input_int_regs, to make sure that this selftest: ... /* INSN: add %eax,(%rcx). */ ... SELF_CHECK (amd64_get_used_input_int_regs (&details, false) == ((1 << EAX_REG_NUM) | (1 << ECX_REG_NUM))); ... passes because it found the "%eax" in the insn, rather than passing because of this assumption: ... /* Assume RAX is used. If not, we'd have to detect opcodes that implicitly use RAX. */ used_regs_mask |= 1 << EAX_REG_NUM; ... Tested on x86_64-linux.
2025-03-07[gdb/tdep] Factor out amd64_get_used_input_int_regsTom de Vries1-6/+17
The function amd64_get_unused_input_int_reg consists of two parts: - finding the used int registers in an insn, and - picking an unused int register. Factor out the first part as new function amd64_get_used_input_int_regs. No functional changes. Tested on x86_64-linux.
2025-03-07[gdb/tdep] Refactor amd64_get_unused_input_int_reg, part 3Tom de Vries1-21/+22
While reading amd64_get_unused_input_int_reg, I noticed that it avoids picking RSP, which has to do with how the result of the only call to it is going to be used. Likewise for picking a register in the RAX ... RDI range. Fix this by: - adding an allowed_regs_mask parameter to amd64_get_unused_input_int_reg, and - properly documenting the value of the corresponding argument in fixup_riprel. No functional changes. Tested on x86_64-linux.
2025-03-07[gdb/tdep] Refactor amd64_get_unused_input_int_reg, part 2Tom de Vries1-2/+2
I noticed that amd64_get_unused_input_int_reg uses a signed int for a bit mask: ... /* 1 bit for each reg */ int used_regs_mask = 0; ... There's an assert: ... gdb_assert (used_regs_mask < 256); ... which is meant to assert on register numbers >= 8, but if for instance sizeof (used_regs_mask) == 4 and used_regs_mask == (1 << 31), then that is not caught because of the signedness. We could fix this by changing the type to unsigned int, but that only guarantees 16 bits in the reg mask. Intel CPUs with the APX extension support 32 int registers. The implementation of amd64_get_unused_input_int_reg doesn't support analyzing registers with register number >= 8 yet, but now that we're changing the type, it seems like a good idea to anticipate this. Fix this by using uint32_t. Likewise, update the loop over the reg mask: ... for (i = 0; i < 8; ++i) { if (! (used_regs_mask & (1 << i))) return i; ... to handle any used_regs_mask value rather than just those for register number < 8. Tested on x86_64-linux.
2025-03-07[gdb/tdep] Refactor amd64_get_unused_input_int_reg, part 1Tom de Vries1-10/+19
While reading amd64_get_unused_input_int_reg, I noticed that it first asserts, then throws an internal_error if no unused register can be found. Looking at the documentation of gdbarch_displaced_step_copy_insn, it seems that a failure can be indicated less abruptly, by returning a nullptr. Fix this by: - returning -1 in case of failure to find an unused register in amd64_get_unused_input_int_reg, and - propagating this to amd64_displaced_step_copy_insn. Tested on x86_64-linux.
2025-03-06[gdb] Fix typos in NEWSTom de Vries1-12/+12
Fix typos: ... mainenance ==> maintenance epilgoue ==> epilogue commnds ==> commands readibility ==> readability informations ==> information throwed ==> threw compiletime ==> compile time namepace ==> namespace reqired ==> required explicity ==> explicitly reqired ==> required ...
2025-03-06[gdb/python] Fix typosTom de Vries3-5/+5
Fix typos: ... gdb/python/py-framefilter.c:749: indention ==> indentation gdb/python/py-framefilter.c:837: indention ==> indentation gdb/python/py-lazy-string.c:35: sting ==> string gdb/python/py-progspace.c:119: Retun ==> Return gdb/python/py-progspace.c:139: Retun ==> Return ...
generated by cgit v1.1 at 2025-04-13 15:21:59 +0000