aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2025-03-13Automatic date update in version.inGDB Administrator1-1/+1
2025-03-12gprofng: regenerate Makefile.inSam James1-0/+1
Needed after 90803ffdcc4d8c3d17566bf8dccadbad312f07a9. gprofng/ChangeLog * src/Makefile.in: Regenerate.
2025-03-12gprofng: Fix cross-compilation binary name.Zheng Junjie2-14/+10
commit d25ba4596e85da6d8af78c88b5917e14763afbe1 create symbolic link no care cross-compilation prefix. gprofng/ChangeLog 2025-02-10 Zheng Junjie <zhengjunjie@iscas.ac.cn> * src/Makefile.am: create symbolic link respect cross-compilation. * src/Makefile.in: Rebuild.
2025-03-12Use correct types in string-set.hTom Tromey1-2/+2
My earlier patch to introduce string-set.h used the wrong type in the hash functions. This patch fixes the error.
2025-03-12gdb: remove unused includes in exceptions.cSimon Marchi1-2/+0
These are reported as unused by clangd. Change-Id: I54b3fba4d7a73c955a9a26c0d340a384b2d37b32
2025-03-12gdb: remove trailing whitespaces in exceptions.cSimon Marchi1-1/+1
Change-Id: Icc7b468b85c09a9721fc9580892c9ad424e0a29a
2025-03-12gdb: remove include from process-stratum-target.hSimon Marchi1-1/+0
It is reported as unused by clangd. Change-Id: I73c03577c521c1b71128409b5cf085a4d1785080
2025-03-12Automatic date update in version.inGDB Administrator1-1/+1
2025-03-11Use gdb map in mi-cmds.cTom Tromey1-2/+2
This changes mi-cmds.c to use gdb::unordered_map. Approved-By: Simon Marchi <simon.marchi@efficios.com>
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-11Automatic date update in version.inGDB Administrator1-1/+1
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 Tromey3-13/+135
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 Marchi17-653/+421
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-10libiberty: move DW_LANG_* definitions to dwarf2.defSimon Marchi3-92/+109
In order to get a "DW_LANG_* to string" function: - move the "DW_LANG_*" definitions from dwarf2.h to dwarf2.def - add the necessary macros in dwarf2.h to generate the enumeration - add the necessary macros in dwarfnames.c to generate the "to string" function include/ChangeLog: * dwarf2.h (DW_LANG, DW_FIRST_LANG, DW_END_LANG): Define then undefine. (enum dwarf_source_language): Remove. (get_DW_LANG_name): Declare. * dwarf2.def: Define DW_LANG_* constants. libiberty/ChangeLog: * dwarfnames.c (DW_FIRST_LANG, DW_END_LANG, DW_LANG): Define then undefine. Change-Id: I440aa2b1f55c7585d7e44c8fa7c41310b0ef2b3a Cc: binutils@sourceware.org
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 Tromey9-30/+37
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-10gprof: Append -l to tst-gmon-gprof-l.sh data filesH.J. Lu1-3/+3
Append -l to tst-gmon-gprof-l.sh data files to avoid conflicts with tst-gmon-gprof.sh data files. * testsuite/tst-gmon-gprof-l.sh (actual): Append -l. (expected): Likewise. (expected_dot): Likewise. Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
2025-03-10gprof: Add a simple test for gprof -lH.J. Lu3-2/+90
Verify that "gprof -l" works properly. * testsuite/Makefile.am (check_SCRIPTS): Add tst-gmon-gprof-l.sh. * testsuite/Makefile.in: Regenerated. * testsuite/tst-gmon-gprof-l.sh: New. Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
2025-03-10meaningless p_offset for zero p_filesz PT_LOADAlan Modra1-1/+4
This patch avoids generating PT_LOAD segments that trip a bug in glibc's loader. PR 25237 PR 32763 * elf.c (assign_file_positions_for_load_sections): Don't put p_offset zero for empty PT_LOAD.
2025-03-10Further tidies to bed->p_align codeAlan Modra1-12/+11
align_pagesize was used for two things, reducing p->p_align from maxpagesize to the bed->p_align value (section alignment permitting), and increasing p->p_align above maxpagesize if section alignment required that. This patch untangles those two, making align_pagesize only do the former. p->p_align is set directly for the latter. I've made that change to p->p_align only when D_PAGED to keep things consistent with other early assignments to p->p_align. p->p_align is set later according to section alignment when not D_PAGED. I've also moved the place where align_pagesize adjusts p->p_align to be with other code setting p->p_align. That seemed better to me than leaving it until the last possible moment. Note that it isn't necessary to have this adjustment done inside a test for a PT_LOAD header, since we never set align_pagesize non-zero outside a PT_LOAD test. * elf.c (assign_file_positions_for_load_sections): Clear align_pagesize whenever we have a section alignment more than bed->p_align. Set p->p_align rather than align_pagesize when section alignment exceeds maxpagesize. Assign p->p_align from align_pagesize earlier.
2025-03-10Tidy code handling bed->p_align a little.Alan Modra1-19/+18
No functional changes here, just preparation for the next patch. * elf.c (assign_file_positions_for_load_sections): Replace p_align_p and p_align with align_pagesize. Revise comments on code handling bed->p_align.
2025-03-10ld: Cleanup sframe_decoder_init_func_bfdinfo use of reloc cookieJens Remus1-9/+8
The loop did set cookie->rel to the i-th relocation twice. At the beginning using the loop counter. At the end by incrementing. One approach is sufficient. Change cookie to pointer-to-const, replace cookie->rel by rel, initialize before the loop and increment at the end, and merge the two assertions (for cookie->rel) into one. While at it change sec to pointer-to-const. bfd/ * elf-sframe.c (sframe_decoder_init_func_bfdinfo): Cleanup use of relocation cookie. Signed-off-by: Jens Remus <jremus@linux.ibm.com>
2025-03-10gas: Use SFrame header and FDE field sizes when generating .sframeJens Remus1-16/+13
The use of SFRAME_RELOC_SIZE in generation of SFrame stack trace information from CFI directives erroneously suggested that this could be used to configure a different relocation size. But in practice it is tied to the SFrame field sizes it is used for and therefore cannot be changed. Replace the uses of SFRAME_RELOC_SIZE by the size of the respective SFrame header and FDE fields when emitting SFrame information. While at it enhance some comments. gas/ * gen-sframe.c (SFRAME_RELOC_SIZE): Delete. (sizeof_member): Define. (output_sframe_funcdesc): Use size of SFrame FDE fields instead of SFRAME_RELOC_SIZE. (output_sframe_internal): Use size of SFrame header fields instead of SFRAME_RELOC_SIZE. Signed-off-by: Jens Remus <jremus@linux.ibm.com>
2025-03-10Automatic date update in version.inGDB Administrator1-1/+1
2025-03-09RISC-V: PR32772, fixed segfault caused by the accidental removal of `h != NULL'Nelson Chu1-1/+1
bfd/ PR 32772 * elfnn-riscv.c (riscv_elf_relocate_section): Fixed segfault caused by the accidental removal of `h != NULL' when handling a call to an undefined weak function.
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-09Automatic date update in version.inGDB Administrator1-1/+1
2025-03-08bfd_elf_parse_attr_section_v1 buffer overflowAlan Modra1-7/+3
This function has a misleading parameter "contents", which usually means an entire section contents is passed. However in this case the actual sections contents plus one is passed, leading to miscalculating the end of the buffer. * elf-attrs.c (bfd_elf_parse_attr_section_v1): Delete hdr and contents param. Add p and p_end as params. (_bfd_elf_parse_attributes): Adjust to suit.
2025-03-08gprof: Compile tst-gmon.c with -O2 -fno-omit-frame-pointerH.J. Lu4-11/+13
Compile tst-gmon.c with -O2 -fno-omit-frame-pointer to ensure proper call graph generation. PR gprof/32768 * configure.ac: Compile tst-gmon.c with -fno-omit-frame-pointer. * configure: Regenerated. * testsuite/Makefile.am (GPROF_FLAGS): Add -O2 -fno-omit-frame-pointer. (AM_CFLAGS): Removed. (COMPILE): Append $(GPROF_FLAGS). (LINK): Likewise. * testsuite/Makefile.in: Regenerated. Signed-off-by: H.J. Lu <hjl.tools@gmail.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
generated by cgit v1.1 at 2025-09-24 05:06:06 +0000