aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2025-05-26Automatic date update in version.inGDB Administrator1-1/+1
2025-05-25Automatic date update in version.inGDB Administrator1-1/+1
2025-05-24gdb/solib-svr4: check that solib is SVR4 in tls_maybe_fill_slot and ↵Simon Marchi1-2/+8
tls_maybe_erase_slot Functions tls_maybe_fill_slot and tls_maybe_erase_slot blindly assume that the passe solibs come from solib-svr4. This is not always the case, because they are called even on the systems where the solib implementation isn't solib-svr4. Add some checks to return early in that case. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32990 Change-Id: I0a281e1f4826aa1914460c2213f0fae1bdc9af7c Tested-By: Hannes Domani <ssbssa@yahoo.de> Approved-By: Andrew Burgess <aburgess@redhat.com>
2025-05-24gdb: use local addrmap_mutable in addrmap selftestSimon Marchi1-14/+13
There is no need to allocate the addrmap_mutable on the heap. Change-Id: Ia6ec17101a44ae5eaffbf3382c9639414ce5343e Approved-By: Andrew Burgess <aburgess@redhat.com>
2025-05-24gdb: turn CHECK_ADDRMAP_FIND into a functionSimon Marchi1-23/+23
Replace the macro with a function. I don't see a need to use a macro here, a function is easier to read. Change-Id: I22370040cb546470498d64939b246b03700af398 Approved-By: Andrew Burgess <aburgess@redhat.com>
2025-05-24[gdb/build] Fix unused var in lookup_dwo_unit_in_dwpTom de Vries1-1/+1
On x86_64-linux, with gcc 7.5.0 I ran into a build breaker: ... gdb/dwarf2/read.c: In function ‘dwo_unit* lookup_dwo_unit_in_dwp()’: gdb/dwarf2/read.c:7403:22: error: unused variable ‘inserted’ \ [-Werror=unused-variable] auto [it, inserted] = dwo_unit_set.emplace (std::move (dwo_unit)); ^ ... Fix this by dropping the unused variable. Tested on x86_64-linux, by completing a build.
2025-05-23gdb: guard <mutex> include with CXX_STD_THREADSimon Marchi1-0/+2
Change-Id: I4335fbfdabe49778fe37b08689eec59be94c424b
2025-05-24Automatic date update in version.inGDB Administrator1-1/+1
2025-05-23gdb/NEWS: minor white space fixAndrew Burgess1-1/+1
Spotted a small white space mistake in the NEWS file. Fixed.
2025-05-23gdb: include <mutex> in dwarf2/read.hSimon Marchi1-0/+1
The buildbot pointed out this compilation failure on AlmaLinux, with g++ 8.5.0, which is not seen on more recent systems: CXX gdbtypes.o In file included from ../../binutils-gdb/gdb/gdbtypes.c:39: ../../binutils-gdb/gdb/dwarf2/read.h:639:8: error: ‘mutex’ in namespace ‘std’ does not name a type std::mutex dwo_files_lock; ^~~~~ ../../binutils-gdb/gdb/dwarf2/read.h:639:3: note: ‘std::mutex’ is defined in header ‘<mutex>’; did you forget to ‘#include <mutex>’? ../../binutils-gdb/gdb/dwarf2/read.h:35:1: +#include <mutex> ../../binutils-gdb/gdb/dwarf2/read.h:639:3: std::mutex dwo_files_lock; ^~~ Fix it by including <mutex> in dwarf2/read.h. Change-Id: Iba334a3dad217c86841a5e804d0f386876f5ff2f
2025-05-23[gdb] Make make-init-c more robustTom de Vries1-2/+2
In commit 2711e4754fc ("Ensure cooked_index_entry self-tests are run"), we rewrite the function definition of _initialize_dwarf2_entry into a normal form that allows the make-init-c script to detect it: ... void _initialize_dwarf2_entry (); -void _initialize_dwarf2_entry () +void +_initialize_dwarf2_entry () ... Update make-init-c to also detect the "void _initialize_dwarf2_entry ()" variant. Tested on x86_64-linux, by reverting commit 2711e4754fc, rebuilding and checking that build/gdb/init.c doesn't change.
2025-05-23[gdb/testsuite] Add gdb.dwarf2/fission-dw-form-strx.expTom de Vries3-8/+117
Add a dwarf assembly test-case using a DW_FORM_strx in a .dwo file. Tested on x86_64-linux. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2025-05-23gdb/dwarf: split dwo_lock in more granular locksSimon Marchi2-33/+64
The dwo_lock mutex is used to synchronize access to some dwo/dwp-related data structures, such as dwarf2_per_bfd::dwo_files and dwp_file::loaded_{cus,tus}. Right now the scope of the lock is kind of coarse. It is taken in the top-level lookup_dwo_unit function, and held while the thread: - looks up an existing dwo_file in the per-bfd hash table for the given id/signature - if there's no existing dwo_file, attempt to find a .dwo file, open it, build the list of units it contains - if a new dwo_file was created, insert it in the per-bfd hash table - look up the desired unit in the dwo_file And something similar for the dwp code path. This means that two indexing thread can't read in two dwo files simultaneously. This isn't ideal in terms of parallelism. This patch breaks this lock into 3 more fine grained locks: - one lock to access dwarf2_per_bfd::dwo_files - one lock to access dwp_file::loaded_{cus,tus} - one lock in try_open_dwop_file, where we do two operations that aren't thread safe (bfd_check_format and gdb_bfd_record_inclusion) Unfortunately I don't see a clear speedup on my computer with 8 threads. But the change shouldn't hurt, in theory, and hopefully this can be a piece that helps in making GDB scale better on machines with many cores (if we ever bump the max number of worker threads). This patch uses "double-checked locking" to avoid holding the lock(s) for the whole duration of reading in dwo files. The idea is, when looking up a dwo with a given name: - with the lock held, check for an existing dwo_file with that name in dwarf2_per_bfd::dwo_files, if found return it - if not found, drop the lock, load the dwo file and create a dwo_file describing it - with the lock held, attempt to insert the new dwo_file in dwarf2_per_bfd::dwo_files. If an entry exists, it means another thread simultaneously created an equivalent dwo_file, but won the race. Drop the new dwo_file and use the existing one. The new dwo_file is automatically deleted, because it is help by a unique_ptr and the insertion into the unordered_set fails. Note that it shouldn't normally happen for two threads to look up a dwo file with the same name, since different units will point to different dwo files. But it were to happen, we handle it. This way of doing things allows two threads to read in two different dwo files simulatenously, which in theory should help get better parallelism. The same technique is used for dwp_file::loaded_{cus,tus}. I have some local CI jobs that run the fission and fission-dwp boards, and I haven't seen regressions. In addition to the regular testing, I ran a few tests using those boards on a ThreadSanitizer build of GDB. Change-Id: I625c98b0aa97b47d5ee59fe22a137ad0eafc8c25 Reviewed-By: Andrew Burgess <aburgess@redhat.com>
2025-05-23gdb/dwarf: allocate DWP dwarf2_section_info with newSimon Marchi2-2/+9
For the same reason as explained in the previous patch (allocations on obstacks aren't thread-safe), change the allocation of dwarf2_section_info object for dwo files within dwp files to use "new". The dwo_file::section object is not always owned by the dwo_file, so introduce a new "dwo_file::section_holder" object that is only set when the dwo_file owns the dwarf2_section_info. Change-Id: I74c4608573c7a435bf3dadb83f96a805d21798a2 Approved-By: Tom Tromey <tom@tromey.com>
2025-05-23gdb/dwarf: allocate dwo_unit with newSimon Marchi1-29/+31
The following patch reduces the duration where the dwo_lock mutex is taken. One operation that is not thread safe is the allocation on dwo_units on the per_bfd obstack: dwo_unit *dwo_unit = OBSTACK_ZALLOC (&per_bfd->obstack, struct dwo_unit); We could take the lock around this allocation, but I think it's just easier to avoid the problem by having the dwo_unit objects allocated with "new". Change-Id: Ida04f905cb7941a8826e6078ed25dbcf57674090 Approved-By: Tom Tromey <tom@tromey.com>
2025-05-23Handle an argument-less operator in the C++ name parserTom Tromey3-0/+43
While debugging a new failure in my long-suffering "search-in-psyms" series, I found that the C++ name canonicalizer did not handle a case like "some_name::operator new []". This should remove the space, resulting in "some_name::operator new[]" -- but does not. This happens because the parser requires an operator to be followed by argument types. That is, it's expected. However, it seems to me that we do want to be able to canonicalize a name like this. It will appear in the DWARF as a DW_AT_name, and furthermore it could be entered by the user. This patch fixes this problem by changing the grammar to supply the "()" itself, then removing the trailing "()" when changing to string form (in the functions that matter). This isn't ideal -- it might miss a very obscure case involving the gdb extension of providing fully-qualified names for function-local statics -- but it improves the situation at least. It's possible a better solution might be to rewrite the name canonicalizer. I was wondering if this could perhaps be done without reference to the grammar -- just by examining the tokens. However, that's much more involved. Let me know what you think. Regression tested on x86-64 Fedora 40. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32939 Reviewed-By: Keith Seitz <keiths@redhat.com>
2025-05-23libctf: archive, open: when opening, always set errp to somethingNick Alcock4-2/+28
ctf_arc_import_parent, called by the cached-opening machinery used by ctf_archive_next and archive-wide lookup functions like ctf_arc_lookup_symbol, has an err-pointer parameter like all other opening functions. Unfortunately it unconditionally initializes it whenever provided, even if there was no error, which can lead to its being initialized to an uninitialized value. This is not technically an API-contract violation, since we don't define what happens to the error value except when an error happens, but it is still unpleasant. Initialize it only when there is an actual error, so we never initialize it to an uninitialized value. While we're at it, improve all the opening pathways: on success, set errp to 0, rather than leaving it what it was, reducing the likelihood of uninitialized error param returns in callers too. (This is inconsistent with the treatment of ctf_errno(), but the err value being a parameter passed in from outside makes the divergence acceptable: in open functions, you're never going to be overwriting some old error value someone might want to keep around across multiple calls, some of which are successful and some of which are not.) Soup up existing tests to verify all this. Thanks to Bruce McCulloch for the original patch, and Stephen Brennan for the report. libctf/ PR libctf/32903 * ctf-archive.c (ctf_arc_open_internal): Zero errp on success. (ctf_dict_open_sections): Zero errp at the start. (ctf_arc_import_parent): Intialize err. * ctf-open.c (ctf_bufopen): Zero errp at the start. * testsuite/libctf-lookup/add-to-opened.c: Make sure one-element archive opens update errp. * testsuite/libctf-writable/ctf-compressed.c: Make sure real archive opens update errp.
2025-05-23RISC-V: Add support for RISC-V Profiles 23.Jiawei3-0/+28
This patch adds support for RISC-V RVA23 and RVB23 Profiles[1]. [1] https://github.com/riscv/riscv-profiles/releases/tag/rva23-rvb23-ratified bfd/ChangeLog: * elfxx-riscv.c: New profiles. gas/ChangeLog: * testsuite/gas/riscv/attribute-19.d: New test. * testsuite/gas/riscv/attribute-20.d: New test.
2025-05-23RISC-V: Add support for RISC-V Profiles 20/22.Jiawei9-13/+110
This patch introduces support for RISC-V Profiles RV20 and RV22 [1], enabling developers to utilize these profiles through the -march option. [1] https://github.com/riscv/riscv-profiles/releases/tag/v1.0 bfd/ChangeLog: * elfxx-riscv.c (struct riscv_profiles): New struct. (riscv_parse_extensions): New argument. (riscv_find_profiles): New checking function. (riscv_parse_subset): Add Profiles handler. gas/ChangeLog: * NEWS: Add RISC-V Profiles. * doc/as.texi: Update -march input type. * doc/c-riscv.texi: Ditto. * testsuite/gas/riscv/option-arch-fail.l: Modify hint info. * testsuite/gas/riscv/attribute-17.d: New test. * testsuite/gas/riscv/attribute-18.d: New test. * testsuite/gas/riscv/march-fail-rvi20u64v.d: New test. * testsuite/gas/riscv/march-fail-rvi20u64v.l: New test.
2025-05-23Automatic date update in version.inGDB Administrator1-1/+1
2025-05-23PR 3298 Fix SuperH relaxation overriding wrong intructionQBos071-2/+2
when doing load store switching it wrongly adjusts the address of the R_SH_USES reloc and not the actual offset from that instruction. This is an issue if the pc-relative function call relaxation gets done in a later pass wich will result in overriding the wrong instruction.
2025-05-23rs_fill_nop and md_generate_nopsAlan Modra6-61/+25
Make rs_fill_nop behave like rs_fill in using a repeat count (fr_offset) to emit fr_var length repeated nop patterns. Besides being more elegant, this reduces memory required for large .nops directives. * as.h (rs_fill_nop): Update comment. * config/tc-i386.c (i386_generate_nops): Handle rs_fill_nop as for rs_align_code. * config/tc-i386.h (MAX_MEM_FOR_RS_SPACE_NOP): Define. * listing.c (calc_hex): Handle rs_fill_nop as for rs_fill. * read.c (MAX_MEM_FOR_RS_SPACE_NOP): Define. (s_nops): Use MAX_MEM_FOR_RS_SPACE_NOP setting up frag. * write.c (write_contents): Call md_generate_nops for rs_fill_nop before the fr_fix part is written, so that rs_fill_nop can be handled as for rs_fill.
2025-05-23Re: gas .align limitAlan Modra2-8/+2
Now that rs_align_code has been corrected for all targets, put the .align limit back to bits_per_address-1. Also fix a comment. * frags.h (fr_var): Correct comment. * read.c (TC_ALIGN_LIMIT): Revert commit ff4c03516c change.
2025-05-23tidy x86 HANDLE_ALIGNAlan Modra39-2342/+2326
Reduce memory requirement for .align in code. I've changed some of the tests to use "clc" rather than "nop", so that code emitted by .p2align can be clearly seen. * config/tc-i386.c (i386_output_nops): Merge into.. (i386_generate_nops): ..here. Put shorter nop first. For rs_align_code make use of the fact that the last fr_var bytes are output repeatedly rather than repeating them here. * config/tc-i386.h (HANDLE_ALIGN): Don't test max_bytes. (MAX_MEM_FOR_RS_ALIGN_CODE): Update. * testsuite/gas/i386/nops-1.s, * testsuite/gas/i386/nops-2.s, * testsuite/gas/i386/nops-3.s, * testsuite/gas/i386/nops-4.s, * testsuite/gas/i386/nops16-1.s: Replace "nop" with "clc". * testsuite/gas/i386/align-branch-6.d, * testsuite/gas/i386/nop-1-suffix.d, * testsuite/gas/i386/nop-1.d, * testsuite/gas/i386/nop-1.l, * testsuite/gas/i386/nop-2.d, * testsuite/gas/i386/nop-4.d, * testsuite/gas/i386/nop-5.d, * testsuite/gas/i386/nops-1-core2.d, * testsuite/gas/i386/nops-1.d, * testsuite/gas/i386/nops-10.d, * testsuite/gas/i386/nops-2.d, * testsuite/gas/i386/nops-3.d, * testsuite/gas/i386/nops-4.d, * testsuite/gas/i386/nops-4a-i686.d, * testsuite/gas/i386/nops-5.d, * testsuite/gas/i386/nops-6.d, * testsuite/gas/i386/nops-7.d, * testsuite/gas/i386/nops-9.d, * testsuite/gas/i386/nops16-1.d, * testsuite/gas/i386/x86-64-align-branch-6.d, * testsuite/gas/i386/x86-64-nop-1.d, * testsuite/gas/i386/x86-64-nop-5.d, * testsuite/gas/i386/x86-64-nops-1-core2.d, * testsuite/gas/i386/x86-64-nops-1-pentium.d, * testsuite/gas/i386/x86-64-nops-1.d, * testsuite/gas/i386/x86-64-nops-2.d, * testsuite/gas/i386/x86-64-nops-3.d, * testsuite/gas/i386/x86-64-nops-4-core2.d, * testsuite/gas/i386/x86-64-nops-4.d, * testsuite/gas/i386/x86-64-nops-5.d, * testsuite/gas/i386/x86-64-nops-6.d, * testsuite/gas/i386/x86-64-nops-7.d: Adjust to suit.
2025-05-23tidy target HANDLE_ALIGNAlan Modra23-202/+106
avr, kvx, metag, mn10300, nds32, v850, visium, and wasm32 targets defined HANDLE_ALIGN without defining MAX_MEM_FOR_RS_ALIGN_CODE. This can result in a rather large chunk of memory being allocated. Fix that by a combination of changing the default allocation to one byte and/or defining a target MAX_MEM_FOR_RS_ALIGN_CODE. arm wanted to write out the entire set of nops, and limited allowed code alignment to 64 bytes to prevent large memory allocations. Fix that by making use of the fact that rs_align_code frags repeat fr_var bytes at fr_literal + fr_fix to fill out the required area. Fix metag, nds32 and kvx too, which it seems copied either arm or x86 in similarly not making use of repeating patterns. It's worth mentioning that my tidy to kvx changed the order of nop bundles, placing a short bundle first rather than last. epiphany was totally broken in that uninitialised data was written out for any alignment requiring more than three bytes of fill. ppc created a new frag to handle a branch over a large number of nops. This saves 4 bytes per rs_align_code frag, and most times the branch isn't used so it is generally a win for memory usage, but I figured the extra code complexity wasn't worth it. So that code of mine goes. visium copied the same scheme, so that goes too. This leaves x86 as the only target making large allocations for alignment frags. * frags.c (MAX_MEM_FOR_RS_ALIGN_CODE): Default to 1. * config/tc-aarch64.c (aarch64_handle_align): Remove always true condition. * config/tc-aarch64.h (MAX_MEM_FOR_RS_ALIGN_CODE): Move to be adjacent to HANDLE_ALIGN define. * config/tc-arm.c (arm_handle_align): Allow alignment of more than MAX_MEM_FOR_RS_ALIGN_CODE bytes. Just write one repeat of nop pattern to frag. (arm_frag_align_code): Delete function. * config/tc-arm.h (MAX_MEM_ALIGNMENT_BYTES): Don't define. (MAX_MEM_FOR_RS_ALIGN_CODE): Set to 7. (md_do_align): Don't define. (arm_frag_align_code): Don't declare. * config/tc-epiphany.c (epiphany_handle_align): Correct frag so that nop_pattern repeats rather than random data. * config/tc-epiphany.h (MAX_MEM_FOR_RS_ALIGN_CODE): Define. * config/tc-kvx.c (kvx_make_nops): Merge into.. (kvx_handle_align): ..here. Put short nop bundle first, followed by repeated full nop bundle. * config/tc-kvx.h (MAX_MEM_FOR_RS_ALIGN_CODE): Define. * config/tc-m32c.h (HANDLE_ALIGN, MAX_MEM_FOR_RS_ALIGN_CODE): Don't define. * config/tc-metag.c (metag_handle_align): Just write one repeat of nop pattern to frag. * config/tc-metag.h (MAX_MEM_FOR_RS_ALIGN_CODE): Define. * config/tc-nds32.c (nds32_handle_align): Just write one repeat of nop pattern to frag. * config/tc-nds32.h (MAX_MEM_FOR_RS_ALIGN_CODE): Define. * config/tc-ppc.c (ppc_handle_align): Don't make a new frag for branch. * config/tc-ppc.h (MAX_MEM_FOR_RS_ALIGN_CODE): Increase to 8. * config/tc-visium.c (visium_handle_align): Don't make a new frag for branch. * config/tc-visium.h (MAX_MEM_FOR_RS_ALIGN_CODE): Define. * config/tc-wasm32.h (HANDLE_ALIGN): Don't define. * testsuite/gas/epiphany/nop.d, * testsuite/gas/epiphany/nop.s: New test. * testsuite/gas/epiphany/allinsn.exp: Run it. * testsuite/gas/kvx/nop-align.d: Adjust.
2025-05-22gdb: reorder checks in validate_exec_fileAndrew Burgess1-13/+17
While reviewing another patch I was briefly confused by a call to target_pid_to_exec_file coming from validate_exec_file while attaching to a process when I had not previously set an executable. The current order of actions in validate_exec_file is: 1. Get name of current executable. 2. Get name of executable from the current inferior. 3. If either of (1) or (2) return NULL, then there's nothing to check, early return. I think it would be cleaner if we instead did this: 1. Get name of current executable. 3. If (1) returned NULL then there's nothing to check, early return. 3. Get name of executable from the current inferior. 4. If (3) returned NULL then there's nothing to check, early return. This does mean there's an extra step, but I don't think the code is any more complex really, and we now avoid trying to extract the name of the executable from the current inferior unless we really need it. This avoids the target_pid_to_exec_file call that I was seeing, which for remote targets does avoid a packet round trip (not that I'm selling this as an "optimisation", just noting the change). There should be no user visible changes after this commit. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2025-05-22Ensure cooked_index_entry self-tests are runTom Tromey1-1/+2
While looking at code coverage for gdb, I noticed that the cooked_index_entry self-tests were not run. I tracked this down to a formatting error in cooked-index-entry.c. I suspect it might be better to use a macro to define these initialization functions. That would probably remove the possibility for this kind of error.
2025-05-21gprofng: fix 32892 source line level information not available with "-g -O2"Vladimir Mezentsev8-94/+442
gprofng did not read the .debug_rnglists section for dwarf-5. Another problem was that gprofng ignored DW_AT_abstract_origin As a result, gprofng skiped Dwarf for all functions declared as: <1><e18b>: Abbrev Number: 43 (DW_TAG_subprogram) <e18c> DW_AT_abstract_origin: <0xe168> <e190> DW_AT_linkage_name: _ZN10Bool_ArrayD2Ev gprofng/ChangeLog 2025-05-19 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> PR 32892 * src/Dwarf.cc: Read the .debug_rnglists section. Support DW_AT_abstract_origin. * src/Dwarf.h: Likewise. * src/DwarfLib.cc: Likewise. * src/DwarfLib.h: Likewise. * src/LoadObject.cc (dump_functions): Print mangled names for aliases. * src/Stabs.cc (fixSymtabAlias): Set 'alias' correctly. * src/Symbol.cc (find_symbols): Add argument where to collect symbols. * src/Symbol.h: Likewise.
2025-05-22RISC-V: Add support for Smcdeleg and Ssccfg extensions.Jiawei16-1/+46
This patch rebases the original patch from Nelson's implement[1]. Added new extension Smcdeleg and Ssccfg with a new CSR, scountinhibit.[2] Co-Authored-By: Nelson Chu <nelson@rivosinc.com> Co-Authored-By: Jiawei Chen <jiawei@iscas.ac.cn> [1] https://patchwork.sourceware.org/project/binutils/patch/20240620045359.47513-1-nelson@rivosinc.com/ [2] https://github.com/riscvarchive/riscv-smcdeleg-ssccfg/releases/tag/v1.0.0 bfd/ChangeLog: * elfxx-riscv.c: New extensions. gas/ChangeLog: * NEWS: Mention new extensions. * config/tc-riscv.c (enum riscv_csr_class): New CSR class. (riscv_csr_address): Add support for Ssccfg. * testsuite/gas/riscv/csr-version-1p10.d: New test for Ssccfg CSR. * testsuite/gas/riscv/csr-version-1p10.l: New warning for Ssccfg CSR. * testsuite/gas/riscv/csr-version-1p11.d: New test for Ssccfg CSR. * testsuite/gas/riscv/csr-version-1p11.l: New warning for Ssccfg CSR. * testsuite/gas/riscv/csr-version-1p12.d: New test for Ssccfg CSR. * testsuite/gas/riscv/csr-version-1p12.l: New warning for Ssccfg CSR. * testsuite/gas/riscv/csr-version-1p13.d: New test for Ssccfg CSR. * testsuite/gas/riscv/csr-version-1p13.l: New warning for Ssccfg CSR. * testsuite/gas/riscv/csr.s: New Ssccfg CSR. * testsuite/gas/riscv/imply.d: New imply check. * testsuite/gas/riscv/imply.s: New implies. * testsuite/gas/riscv/march-help.l: New helping info. include/ChangeLog: * opcode/riscv-opc.h (CSR_SCOUNTINHIBIT): New CSR address. (DECLARE_CSR): Add Ssccfg CSR.
2025-05-22LoongArch: Warning about incorrect 3rd argument of .alignLulu Cai3-2/+13
344b1e0f5f7 Introduced range-check 3rd argument of .align, incorrect value are not converted silently. added warning message to fix regression.
2025-05-22Automatic date update in version.inGDB Administrator1-1/+1
2025-05-22ubsan: integer overflow in tc-i386.c:offset_in_rangeAlan Modra1-1/+1
or $9223372036854775808,%eax runtime error: negation of -9223372036854775808 cannot be represented in type 'offsetT' (aka 'long'); cast to an unsigned type to negate this value to itself * config/tc-i386.c (offset_in_range): Avoid signed overflow.
2025-05-21Minor spelling fixes in gdb directoryTom Tromey14-22/+23
I ran codespell on the gdb directory and fixed a number of minor problems. In a couple cases I replaced a "gdb spelling" (e.g., "readin") with an English one ("reading") where it seemed harmless. I also added "Synopsis" as an accepted spelling. gdb is nowhere near codespell-clean. Approved-By: Tom de Vries <tdevries@suse.de>
2025-05-21Automatic date update in version.inGDB Administrator1-1/+1
2025-05-20[gdb/testsuite] Fix gdb.dwarf2/dw-form-strx-out-of-bounds.exp with ↵Tom de Vries3-1/+13
make-check-all.sh I forgot to run test-case gdb.dwarf2/dw-form-strx-out-of-bounds.exp with make-check-all.sh, and consequently failed to notice that it fails with for instance target board fission-dwp. The test-case does: ... source $srcdir/$subdir/dw-form-strx.exp.tcl ... and in that tcl file, prepare_for_testing fails, so a -1 is returned, but that is ignored by the source command. Fix this by using require, but rather that testing the result of the source command, communicate success by setting a global variable prepare_for_testing_done. Likewise in gdb.dwarf2/dw-form-strx.exp. Also, the test-case gdb.dwarf2/dw-form-strx-out-of-bounds.exp fails for target board readnow, because the DWARF error occurs during a different command than expected. Fix this by just skipping the test-case in that case. Tested on x86_64-linux. Reported-by: Simon Marchi <simark@simark.ca> Approved-By: Tom Tromey <tom@tromey.com>
2025-05-20[gdb/testsuite] Make gdb.debuginfod codespell-cleanTom de Vries4-5/+5
Make gdb.debuginfod codespell-clean and add the dir to the pre-commit configuration. Approved-By: Tom Tromey <tom@tromey.com>
2025-05-20[gdb/testsuite] Make gdb.guile codespell-cleanTom de Vries2-2/+2
Make gdb.guile codespell-clean and add the dir to the pre-commit configuration. Approved-By: Tom Tromey <tom@tromey.com>
2025-05-20[gdb/testsuite] Make gdb.mi codespell-cleanTom de Vries5-6/+6
Make gdb.mi codespell-clean and add the dir to the pre-commit configuration. Approved-By: Tom Tromey <tom@tromey.com>
2025-05-20[gdb/testsuite] Make gdb.opt codespell-cleanTom de Vries2-2/+2
Make gdb.opt codespell-clean and add the dir to the pre-commit configuration. Approved-By: Tom Tromey <tom@tromey.com>
2025-05-20[gdb/testsuite] Make gdb.pascal codespell-cleanTom de Vries2-2/+2
Make gdb.pascal codespell-clean and add the dir to the pre-commit configuration. Approved-By: Tom Tromey <tom@tromey.com>
2025-05-20[gdb/testsuite] Make gdb.reverse codespell-cleanTom de Vries4-4/+4
Make gdb.reverse codespell-clean and add the dir to the pre-commit configuration. Approved-By: Tom Tromey <tom@tromey.com>
2025-05-20[gdb/testsuite] Make gdb.rocm codespell-cleanTom de Vries2-2/+2
Make gdb.rocm codespell-clean and add the dir to the pre-commit configuration. Approved-By: Tom Tromey <tom@tromey.com>
2025-05-20[gdb/testsuite] Make gdb.stabs codespell-cleanTom de Vries2-2/+2
Make gdb.stabs codespell-clean and add the dir to the pre-commit configuration. Approved-By: Tom Tromey <tom@tromey.com>
2025-05-20[gdb/testsuite] Make gdb.xml codespell-cleanTom de Vries3-3/+3
Make gdb.xml codespell-clean and add the dir to the pre-commit configuration. Approved-By: Tom Tromey <tom@tromey.com>
2025-05-20[gdb/testsuite] Make gdb.tui codespell-cleanTom de Vries3-4/+4
Make gdb.tui codespell-clean and add the dir to the pre-commit configuration. Approved-By: Tom Tromey <tom@tromey.com>
2025-05-20[gdb/testsuite] Fix gdbsever typoTom de Vries4-2/+4
I noticed a typo in the testsuite, twice: gdbsever. Fix these. Codespell doesn't detect it, so add a new file gdb/contrib/codespell-dictionary.txt that contains a gdbsever->gdbserver entry, and update gdb/contrib/setup.cfg to use it. Approved-By: Tom Tromey <tom@tromey.com>
2025-05-20[pre-commit] Add codespell-clean gdb/testsuite dirsTom de Vries1-1/+1
The following gdb/testsuite subdirs are codespell-clean: ... $ for d in gdb/testsuite/gdb.*; do \ echo -n "$d:"; \ codespell --config ./gdb/contrib/setup.cfg $d \ | wc -l; \ done 2>&1 \ | grep :0 gdb/testsuite/gdb.ctf:0 gdb/testsuite/gdb.dap:0 gdb/testsuite/gdb.gdb:0 gdb/testsuite/gdb.go:0 gdb/testsuite/gdb.modula2:0 gdb/testsuite/gdb.objc:0 gdb/testsuite/gdb.opencl:0 gdb/testsuite/gdb.perf:0 gdb/testsuite/gdb.replay:0 gdb/testsuite/gdb.server:0 gdb/testsuite/gdb.testsuite:0 ... Add them to the pre-commit configuration. Approved-By: Tom Tromey <tom@tromey.com>
2025-05-20libiberty: sync with gccAndreas Schwab12-17/+261
Import the following commits from GCC as of r16-614-g9d039eff453f77: 31dd621796f libiberty: add ldirname function f3d07779fdb libiberty: Append <libgen.h> to AC_CHECK_DECLS [PR119218]. 90183362524 libiberty, gcc: Add memrchr to libiberty and use it [PR119283]. 43717ee9064 libiberty: Fix off-by-one when collecting range expression
2025-05-20ubsan: undefined shift in loongarch_elf_add_sub_reloc_uleb128Alan Modra1-6/+9
An oss-fuzz testcase found: runtime error: shift exponent 140 is too large for 32-bit type 'int' OK, that's just a completely silly uleb, but we ought to be able to handle 64 bits here. * elfxx-loongarch.c (loongarch_elf_add_sub_reloc_uleb128): Formatting. Don't left shift int. Avoid shifts larger than bits in a bfd_vma.
2025-05-20Automatic date update in version.inGDB Administrator1-1/+1
generated by cgit v1.1 at 2025-09-24 08:37:56 +0000