aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2025-07-06ubsan: gas resolve_symbol_valueAlan Modra1-2/+2
Avoid signed overflow when resolving constant +/- constant.
2025-07-05libsframe: fix error code in sframe_decodeIndu Bhagat1-1/+1
When sanity check of SFrame header fails, set error code to SFRAME_ERR_BUF_INVAL instead of the current SFRAME_ERR_NOMEM.
2025-07-06Automatic date update in version.inGDB Administrator1-1/+1
2025-07-05[gdb/tdep] Fix selftest scoped_mmap on freebsdTom de Vries1-2/+2
On x86_64-freebsd, I run into: ... $ gdb -q -batch -ex "maint selftest scoped_mmap" Running selftest scoped_mmap. Self test failed: self-test failed at scoped_mmap-selftests.c:50 Failures: scoped_mmap Ran 1 unit tests, 1 failed ... The problem is that this call: ... ::scoped_mmap smmap (nullptr, sysconf (_SC_PAGESIZE), PROT_WRITE, MAP_ANONYMOUS | MAP_PRIVATE, 0, 0); ... returns MAP_FAILED and sets errno to EINVAL because the argument fd == 0. If MAP_ANONYMOUS is used, fd == -1 should be used on freebsd. On linux, fd is ignored but -1 is recommended for portability. Fix this by using fd == -1 instead. Tested x86_64-freebsd and x86_64-linux.
2025-07-05[gdb/tdep] Fix doc string of kvm pcb/proc commandTom de Vries1-2/+2
On x86_64-freebsd, I ran into: ... $ gdb -q -batch -ex "maint selftest help_doc_invariants" Running selftest help_doc_invariants. help doc broken invariant: command 'kvm pcb' help doc first line is not \ terminated with a '.' character Self test failed: self-test failed at command-def-selftests.c:120 Failures: help_doc_invariants Ran 1 unit tests, 1 failed ... Fix this by adding the missing terminating dot. Likewise for the kvm proc command. Tested on x86_64-freebsd.
2025-07-05gdb: create gdb.sum/gdb.log summary after using check-all-boardsAndrew Burgess1-1/+11
Use the contrib/dg-extract-results.sh script to create a gdb.sum and gdb.log summary after running the check-all-boards make target. Having the results from all the boards merged into a single file isn't (maybe) the most useful, but it isn't a bad thing. However, the great thing about merge the results is that the totals are also merged. The 'check-all-boards' recipe can then extract these totals, just as we do for the normal 'check' recipe, this makes is much easier to spot if there are any unexpected failures when using 'check-all-boards'. Reviewed-By: Keith Seitz <keiths@redhat.com>
2025-07-05contrib: sync dg-extract-results.{sh,py} with GCCAndrew Burgess2-5/+10
Sync the dg-extract-results.{sh,py} scripts with GCC, up to commit 4e9104ae5455a3c02c2a7e07f52e6bc574cc761d. This extends the dg-extract-results scripts to handle GDB's 'unexpected core files' count. contrib/ChangeLog: * dg-extract-results.py: Handle GDB's unexpected core file count. * dg-extract-results.sh: Likewise. Reviewed-By: Keith Seitz <keiths@redhat.com>
2025-07-04sim: ppc: use correct macrosPietro Monteiro1-3/+3
AC_STRUCT_ST_* are the names of the autoconf macros, the C preprocessor macros defined by autoconf/authoeader are HAVE_STRUCT_STAT_ST_*. Approved-By: Andrew Burgess <aburgess@redhat.com>
2025-07-04sim: configury: fix obsolete macrosPietro Monteiro9-133/+35
Running `autoreconf -vf -Wall' in the sim directory shows errors about the use of obsolete macros. This patch fix the issues with macros used or defined in the sim directory. However, it doesn't fix all warnings. There's 1 autoconf warning from `config/pkg.m4', and many automake warnings about target shadowing. It cuts a lot of the noise down and makes an upgrade to autoconf 2.71+ easier. - Replace AC_CANONICAL_SYSTEM by AC_CANONICAL_TARGET https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/ Obsolete-Macros.html#index-AC_005fCANONICAL_005fSYSTEM-1997 - Replace AC_TRY_COMPILE by AC_COMPILE_IFELSE https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/ Obsolete-Macros.html#index-AC_005fTRY_005fCOMPILE-2203 - Replace AC_ERROR by AC_MSG_ERROR https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/ Obsolete-Macros.html#index-AC_005fERROR-2034 - Remove AC_TYPE_SIGNAL and replace `RETSIGTYPE' by `void' in the source https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/ Obsolete-Macros.html#index-AC_005fTYPE_005fSIGNAL-2213 - Remove AC_STRUCT_ST_BLKSIZE, it's already covered by a AC_CHECK_MEMBERS call https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/ Obsolete-Macros.html#index-AC_005fSTRUCT_005fST_005fBLKSIZE-2176 - Remove AC_STRUCT_ST_RDEV, it's already covered by a AC_CHECK_MEMBERS call https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/ Obsolete-Macros.html#index-AC_005fSTRUCT_005fST_005fRDEV-2180 - Remove AC_STRUCT_ST_BLOCKS. It is not obsolete, but it's already covered by a AC_CHECK_MEMBERS call. - Replace deprecated C macros HAVE_ST_${MEMBER} by HAVE_STRUCT_STAT_ST_${MEMBER} https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/ Particular-Structures.html#index-AC_005fSTRUCT_005fST_005fBLOCKS-693 Approved-By: Tom Tromey <tom@tromey.com>
2025-07-04gdb: add Pietro Monteiro to gdb/MAINTAINERSPietro Monteiro1-0/+1
2025-07-05Automatic date update in version.inGDB Administrator1-1/+1
2025-07-04gas: introduce .errif and .warnifJan Beulich8-0/+112
Rather than having people resort to indirect means to issue a certain kind of diagnostic conditionally upon an expression which can (or should) only be evaluated when all sections were sized and all symbols had their final values established, provide directives to directly achieve this.
2025-07-04gas: add a means to programmatically determine the assembler versionJan Beulich10-2/+115
It has been more than once that I would have wanted to have a way to know the gas version in assembly sources, perhaps for use with .if. Add such a pre-defined symbol, introducing the common pattern GAS(<symbol>) for any such symbols. The use of parentheses is to keep the risk of collisions with users' symbols as low as possible. (Possible future arch-specific symbols may want to use GAS(<arch>:<symbol>).) Similarly permit determining whether the assembler is a released version. The exact value probably isn't of much use, it's more the defined-ness that one might care about. Yet the symbol needs to have some value anyway. While by default pre-defined symbols won't be emitted to the symbol table, introduce -emit-local-absolute to allow requesting this. Re- purpose flag_strip_local_absolute to become tristate, with a negative value indicating to also emit pre-defined symbols.
2025-07-04cris/testsuite: don't use --em=Jan Beulich254-254/+254
Using such abbreviations is fine when written on an interactive command line by a human. In scripts and alike, doing so risks colliding with later option additions, as is about to occur for gas: Shortly there'll be --emit-local-absolute.
2025-07-04Automatic date update in version.inGDB Administrator1-1/+1
2025-07-03gdb/linux-nat: initialize lwp_info::syscall_stateSimon Marchi1-6/+6
When running gdb.base/foll-fork-syscall.exp with a GDB built with UBSan, I get: /home/simark/src/binutils-gdb/gdb/linux-nat.c:1906:28: runtime error: load of value 3200171710, which is not a valid value for type 'target_waitkind' ERROR: GDB process no longer exists GDB process exited with wait status 3026417 exp9 0 1 UNRESOLVED: gdb.base/foll-fork-syscall.exp: follow-fork-mode=child: detach-on-fork=on: test_catch_syscall: continue to breakpoint after fork The error happens here: #0 __sanitizer::Die () at /usr/src/debug/gcc/gcc/libsanitizer/sanitizer_common/sanitizer_termination.cpp:50 #1 0x00007ffff600d8dd in __ubsan::__ubsan_handle_load_invalid_value_abort (Data=<optimized out>, Val=<optimized out>) at /usr/src/debug/gcc/gcc/libsanitizer/ubsan/ubsan_handlers.cpp:551 #2 0x00005555636d37b6 in linux_handle_syscall_trap (lp=0x7cdff1eb1b00, stopping=0) at /home/simark/src/binutils-gdb/gdb/linux-nat.c:1906 #3 0x00005555636e0991 in linux_nat_filter_event (lwpid=3030627, status=1407) at /home/simark/src/binutils-gdb/gdb/linux-nat.c:3044 #4 0x00005555636e407f in linux_nat_wait_1 (ptid=..., ourstatus=0x7bfff0d6cf18, target_options=...) at /home/simark/src/binutils-gdb/gdb/linux-nat.c:3381 #5 0x00005555636e7795 in linux_nat_target::wait (this=0x5555704d35e0 <the_amd64_linux_nat_target>, ptid=..., ourstatus=0x7bfff0d6cf18, target_options=...) at /home/simark/src/binutils-gdb/gdb/linux-nat.c:3607 #6 0x000055556378fad2 in thread_db_target::wait (this=0x55556af42980 <the_thread_db_target>, ptid=..., ourstatus=0x7bfff0d6cf18, options=...) at /home/simark/src/binutils-gdb/gdb/linux-thread-db.c:1398 #7 0x0000555564811327 in target_wait (ptid=..., status=0x7bfff0d6cf18, options=...) at /home/simark/src/binutils-gdb/gdb/target.c:2593 I believe the problem is that lwp_info::syscall_state is never initialized. Fix that by initializing it with TARGET_WAITKIND_IGNORE. This is the value we use elsewhere when resetting this field to mean "not stopped at a syscall". Change-Id: I5b76c63d1466d6e63448fced03305fd5ca8294eb Approved-By: Tom Tromey <tom@tromey.com>
2025-07-03bfd/aarch64-linux: Support reading and writing the GCS core file noteThiago Jung Bauermann2-0/+34
Reviewed-By: Luis Machado <luis.machado@arm.com>
2025-07-03gdb/testsuite: remove spurious whitespace in gdb.python/py-symbol.expSimon Marchi1-1/+0
Change-Id: I15e307e6910ecbea5a5852e07757f892ea799536
2025-07-03gdb/alpha-tdep: add empty lineSimon Marchi1-0/+1
This was suggested in review, to separate the comment from the following code. Change-Id: I077ad4545ee5ef1d362dcfacf585400e26dfdb29
2025-07-03Automatic date update in version.inGDB Administrator1-1/+1
2025-07-02gdb/alpha: Redefine fpcr with fpcr_flags typeYodel Eldar2-2/+77
This commit adds fpcr_flags and dyn_rm_enum types to define the fpcr. For details on the floating-point control register (fpcr), please see the Alpha Architecture Reference Manual, 4th Ed. [1]; in brief, it consists of a 64-bit bitfield with most bits reserved/unused. All but a pair of the used bits are boolean flags; the exception, DYN_RM, is a 2-bit enum indicating the IEEE rounding mode and is defined as a dyn_rm_enum type in the target description annex. [1] https://archive.org/details/dec-alpha_arch_ref Approved-By: Simon Marchi <simon.marchi@efficios.com> Change-Id: Iea54c9e201faae6147a03de124b0368752bce060
2025-07-02gdb/alpha: Add target description supportYodel Eldar7-39/+276
This commit adds target description support for Alpha. The target description obviates the alpha_register_type and alpha_register_name functions in alpha-tdep.c. Removal of alpha_register_reggroup_p was considered but ultimately abandoned, because the "info regs" command would no longer omit the zero, fpcr, and unique registers from its output (they are neither vector nor float types). Register types in the target description annex match the types that the alpha_register_type function returned. The locally defined register_names array was moved out of alpha_register_name and renamed to alpha_register_names as a static global; calls to alpha_register_name have been replaced with direct access of the array. The patch follows the code pattern outlined in the following GDB Internals Wiki entry: https://sourceware.org/gdb/wiki/Internals%20Adding-Target-Described-Register-Support Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Simon Marchi <simon.marchi@efficios.com> Change-Id: If4b25a891228388519074a31a682e33358c71063
2025-07-02[gdb/testsuite] Use support_displaced_stepping in ↵Tom de Vries1-1/+1
gdb.arch/amd64-disp-step-avx.exp In commit 8e73fddeb0d ("[gdb/testsuite] Fix gdb.arch/amd64-disp-step-avx.exp on x86_64-freebsd") I added a "require {istarget *-*-linux*}", but since then I found support_displaced_stepping, which seems more appropriate and descriptive. Fix this by requiring support_displaced_stepping instead. Tested on x86_64-freebsd.
2025-07-02[gdb/testsuite] Fix gdb.arch/amd64-disp-step-avx.exp on x86_64-freebsdTom de Vries1-0/+1
With test-case gdb.arch/amd64-disp-step-avx.exp on x86_64-freebsd I run into: ... (gdb) continue Continuing. Breakpoint 3, test_rip_vex2_end () at amd64-disp-step-avx.S:35 35 nop (gdb) FAIL: $exp: vex2: continue to test_rip_vex2_end ... This happens while executing this bit of the test-case: ... # Turn "debug displaced" on to make sure a displaced step is actually # executed, not an inline step. gdb_test_no_output "set debug displaced on" gdb_test "continue" \ "Continuing.*prepared successfully .*Breakpoint.*, ${test_end_label} ().*" \ "continue to ${test_end_label}" ... The problem is that on x86_64, displaced stepping is only supported for linux. Consequently, the "prepared successfully" message is missing. Fix this by requiring linux. Approved-by: Kevin Buettner <kevinb@redhat.com> Tested on x86_64-freebsd.
2025-07-02Automatic date update in version.inGDB Administrator1-1/+1
2025-07-01Fix handling of terminal escape sequences in TUITom Tromey9-29/+243
A user noticed that if the remote sends terminal escape sequences from the "monitor" command, then these will not be correctly displayed when in TUI mode. I tracked this down to remote.c emitting one character at a time -- something the TUI output functions did not handle correctly. I decided in the end to fix in this in the ui-file layer, because the same bug seems to affect logging and, as is evidenced by the test case in this patch, Python output in TUI mode. The idea is simple: buffer escape sequences until they are either complete or cannot possibly be recognized by gdb. Regression tested on x86-64 Fedora 40. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=14126 Approved-By: Andrew Burgess <aburgess@redhat.com>
2025-07-01x86: ld: sframe: Remove SFrame NULL FRE templateJens Remus1-15/+16
A SFrame NULL FRE template is used as NULL value in some but not all instances to initialize unused elements of SFrame FRE pointer arrays of fixed size. Additionally it is erroneously used as SFrame FRE template for PLT GOT entries. Define a separate SFrame FRE template for PLT GOT entries with the same properties as the SFrame NULL FRE and use that for all PLT GOT entries. Remove the SFrame NULL FRE template, as initialization of unused array elements is not required, as demonstrated by the instances where it was not done. bfd/ * elf64-x86-64.c (elf_x86_64_sframe_null_fre): Remove. (elf_x86_64_sframe_pltgot_fre1): New SFrame FRE template for PLT GOT entries. (elf_x86_64_sframe_non_lazy_plt, elf_x86_64_sframe_non_lazy_ibt_plt): Do not initialize unused FRE array elements with elf_x86_64_sframe_null_fre. Use elf_x86_64_sframe_pltgot_fre1 for PLT GOT. (elf_x86_64_sframe_plt, elf_x86_64_sframe_ibt_plt): Use elf_x86_64_sframe_pltgot_fre1 for PLT GOT. Signed-off-by: Jens Remus <jremus@linux.ibm.com>
2025-07-01libctf: doc: add __float128 and SIMD vector classification to spec.Bruce McCulloch1-2/+9
This patch adds two additional distinct types (__float128 and the SIMD vector type generated from the vector_size attribute) to the umbrella of two existing types (long double and array, respectively). These types were previously invalid, producing CTF_K_UNKNOWN in the case of __float128 or a float in the case of the SIMD vector. This patch will cleanly allow these types to be represented more accurately without breaking back-compat. Signed-off-by: Bruce McCulloch <bruce.mcculloch@oracle.com> Reviewed-by: Nick Alcock <nick.alcock@oracle.com>
2025-07-01libctf: add root-visibility-addition testNick Alcock2-0/+39
libctf/ * testsuite/libctf-writable/ctf-nonroot-addition.*: New test.
2025-07-01libctf: create: check the right root-visible flag when adding enumerandsNick Alcock1-1/+1
The root-visible flag we're dealing with here is directly out of the dict, not a flag passed in to the API, so it does not have the values CTF_ADD_ROOT or CTF_ADD_NONROOT: instead it's simply zero for non-root-visible, nonzero otherwise. Fix the test. libctf/ * ctf-create.c (ctf_add_enumerator): Fix root-visibility test.
2025-07-01libctf: create: addition of non-root types should not return root typesNick Alcock1-3/+3
If you add a non-root type to a dict, you should always get a new, unique type ID back, even if a root-visible type with the same name already exists. Unfortunately, if the root-visible type is a forward, and you're adding a non-root-visible struct, union, or enum, the machinery to detect forwards and promote them to the concrete type fires in this case and returns the root-visible type! If this is an enum being inserted hidden because its enumerands conflict with some other enum, this will lead to failure later on: in any case, it's seriously counterintuitive to add a non-root- visible type and get a root-visible one instead. Fix this by checking the root-visible flag properly and only checking for forwards if this type is root-visible. (This may lead to a certain degree of proliferation of non-root-visible forwards: we can add a cleanup pass for those later if needed.) libctf/ * ctf-create.c (ctf_add_struct_sized): Check the root-visible flag when doing forward promotion. (ctf_add_union_sized): Likewise. (ctf_add_enum): Likewise. Reviewed-by: Bruce McCulloch <bruce.mcculloch@oracle.com>
2025-07-01MIPS: Fix addend handling with rela R_MIPS16_GOT16 and R_MICROMIPS_GOT16Alan Modra2-4/+4
In rela howtos these relocations should not be using _bfd_mips_elf_got16_reloc. That special function is for extracting addends from section contents, and only for that (ie. it doesn't subtract gp). Make these rela howtos like the corresponding R_MIPS_GOT16 rela howto. * elf64-mips.c (mips16_elf64_howto_table_rela <R_MIPS16_GOT16>): Use _bfd_mips_elf_generic_reloc. (micromips_elf64_howto_table_rela <R_MICROMIPS_GOT16>): Likewise. * elfn32-mips.c (elf_mips16_howto_table_rela <R_MIPS16_GOT16>): Likewise. (elf_micromips_howto_table_rela <R_MICROMIPS_GOT16>): Likewise.
2025-07-01Automatic date update in version.inGDB Administrator1-1/+1
2025-06-30RISC-V: [gprofng] Allow building gprofng without asm/hwprobe.hWANG Xuerui4-2/+26
The code is actually able to gracefully fallback if the syscall number of riscv_hwprobe is not available at build time, but it still depended on the <asm/hwprobe.h> header unconditionally. In certain environments such as one of crosstool-NG's Canadian Cross build step (binutils for host), or one with very outdated kernel headers, the header will not be present, causing the build to fail. While the relevant projects/environments should be fixed nevertheless, a configure-time check for <asm/hwprobe.h> is helpful for fixing gprofng builds with released versions of ct-ng etc. Signed-off-by: WANG Xuerui <git@xen0n.name>
2025-06-30Fix typos in binutils/dwarf.cVladimir Mezentsev1-3/+3
binutils/ChangeLog 2025-06-29 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> * dwarf.c: Change "/usrlib64/debug/usr" to "/usr/lib64/debug/usr/" and .gun_debugaltlink to .gnu_debugaltlink.
2025-06-30Automatic date update in version.inGDB Administrator1-1/+1
2025-06-28gdb/solib-target: move make_target_solib_ops out of HAVE_LIBEXPATSimon Marchi1-8/+8
When building without expat, we get a missing make_target_solib_ops error: /usr/bin/ld: arch-utils.o: in function `gdbarch::gdbarch()': /home/simark/src/binutils-gdb/gdb/gdbarch-gen.c:30:(.text+0x15be): undefined reference to `make_target_solib_ops()' Fix it by moving make_target_solib_ops out of HAVE_LIBEXPAT. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33118 Change-Id: I76fe4698c6b71bd76096e6cdcbacf8de42a3eb43 Tested-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
2025-06-29Automatic date update in version.inGDB Administrator1-1/+1
2025-06-29x86-64.exp: Correct pr26808.dump to pr27708.dumpH.J. Lu1-1/+1
Change verbose "cmp tmpdir/pr27708.out $srcdir/$subdir/pr26808.dump" 1 to verbose "cmp tmpdir/pr27708.out $srcdir/$subdir/pr27708.dump" 1 * testsuite/binutils-all/x86-64/x86-64.exp: Correct pr26808.dump to pr27708.dump. Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
2025-06-28[gdb/tdep] Add "maint set console-translation-mode <binary|text>" commandTom de Vries4-0/+91
On MSYS2, say we record a brief gdb session using TERM=dumb script: ... $ gdb -q (gdb) print 1 $1 = 1 (gdb) q ... When looking at the resulting typescript, we notice something odd: ... $ gdb -q^M (gdb) print 1^M $1 = 1^M^M (gdb) q^M ... For some reason, we have "$1 = 1\r\r\n(gdb) ". Looking at the documentation of _setmode [1], it mentions translation mode _O_TEXT as a mode in which "\n" is translated into "\r\n" on output. So, it looks like this translation happens twice. Add a command "maint set console-translation-mode <binary|text>" command that allows us to set the translation mode of stdout/stderr to binary, such that we get instead: ... $ gdb -q -ex "maint set console-translation-mode binary"^M (gdb) print 1^M $1 = 1^M (gdb) q^M ... Since we run into this in the testsuite, add "maint set console-translation-mode binary" to INTERNAL_GDBFLAGS. Based on "maint set testsuite-mode on/off" from these patches [2][3] by Pierre Muller. Compared to that proposal, I dropped the name testsuite-mode, because the behaviour is not specific to the testsuite. Also I chose values binary/text instead of on/off because eventually there may be other translation mode values that we need [4]. Co-Authored-By: Pierre Muller <muller@sourceware.org> Reviewed-By: Eli Zaretskii <eliz@gnu.org> [1] https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/setmode [2] https://sourceware.org/legacy-ml/gdb-patches/2013-09/msg00939.html [3] https://sourceware.org/legacy-ml/gdb-patches/2013-09/msg00940.html [4] https://learn.microsoft.com/en-us/cpp/c-runtime-library/translation-mode-constants
2025-06-28Automatic date update in version.inGDB Administrator1-1/+1
2025-06-27GDB: maint: Fix build on FreeBSDThiago Jung Bauermann1-0/+2
While trying to build current trunk of GDB on FreeBSD 14.3 on aarch64, I hit this warning converted to an error: In file included from /home/bauermann/src/binutils-gdb/gdb/maint.c:37: /home/bauermann/src/binutils-gdb/gdb/maint.h:64:8: error: private field 'm_start_space' is not used [-Werror,-Wunused-private-field] 64 | long m_start_space; | ^ 1 error generated. gmake[2]: *** [Makefile:1973: maint.o] Error 1 I used the default compiler on this system: $ c++ --version FreeBSD clang version 19.1.7 (https://github.com/llvm/llvm-project.git llvmorg-19.1.7-0-gcd708029e0b2) Target: aarch64-unknown-freebsd14.3 Thread model: posix InstalledDir: /usr/bin The problem is that the only two places that use m_start_space are guarded by HAVE_USEFUL_SBRK, so also guard the member declaration with it. Build-tested on aarch64-unknown-freebsd14.3. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2025-06-27Automatic date update in version.inGDB Administrator1-1/+1
2025-06-26gdb/solib: C++ify solib_opsSimon Marchi97-887/+1220
Convert solib_ops into an abstract base class (with abstract methods, some of them with default implementations) and convert all the existing solib_ops instances to solib_ops derived classes / implementations. Prior to this patch, solib_ops is a structure holding function pointers, of which there are only a handful of global instances (in the `solib-*.c` files). When passing an `solib_ops *` around, it's a pointer to one of these instances. After this patch, there are no more global solib_ops instances. Instances are created as needed and stored in struct program_space. These instances could eventually be made to contain the program space-specific data, which is currently kept in per-program space registries (I have some pending patches for that). Prior to this patch, `gdbarch_so_ops` is a gdbarch method that returns a pointer to the appropriate solib_ops implementation for the gdbarch. This is replaced with the `gdbarch_make_solib_ops` method, which returns a new instance of the appropriate solib_ops implementation for this gdbarch. This requires introducing some factory functions for the various solib_ops implementation, to be used as `gdbarch_make_solib_ops` callbacks. For instance: solib_ops_up make_linux_ilp32_svr4_solib_ops () { return std::make_unique<linux_ilp32_svr4_solib_ops> (); } The previous code is full of cases of tdep files copying some base solib_ops implementation, and overriding one or more function pointer (see ppc_linux_init_abi, for instance). I tried to convert all of this is a class hierarchy. I like that it's now possible to get a good static view of all the existing solib_ops variants. The hierarchy looks like this: solib_ops ├── aix_solib_ops ├── darwin_solib_ops ├── dsbt_solib_ops ├── frv_solib_ops ├── rocm_solib_ops ├── svr4_solib_ops │ ├── ilp32_svr4_solib_ops │ ├── lp64_svr4_solib_ops │ ├── linux_ilp32_svr4_solib_ops │ │ ├── mips_linux_ilp32_svr4_solib_ops │ │ └── ppc_linux_ilp32_svr4_solib_ops │ ├── linux_lp64_svr4_solib_ops │ │ └── mips_linux_lp64_svr4_solib_ops │ ├── mips_nbsd_ilp32_svr4_solib_ops │ ├── mips_nbsd_lp64_svr4_solib_ops │ ├── mips_fbsd_ilp32_svr4_solib_ops │ └── mips_fbsd_lp64_svr4_solib_ops └── target_solib_ops └── windows_solib_ops The solib-svr4 code has per-arch specialization to provide a link_map_offsets, containing the offsets of the interesting fields in `struct link_map` on that particular architecture. Prior to this patch, arches would set a callback returning the appropriate link_map_offsets by calling `set_solib_svr4_fetch_link_map_offsets`, which also happened to set the gdbarch's so_ops to `&svr_so_ops`. I converted this to an abstract virtual method of `struct svr4_solib_ops`, meaning that all classes deriving from svr4_solib_ops must provide a method returning the appropriate link_map_offsets for the architecture. I renamed `set_solib_svr4_fetch_link_map_offsets` to `set_solib_svr4_ops`. This function is still necessary because it also calls set_gdbarch_iterate_over_objfiles_in_search_order, but if it was not for that, we could get rid of it. There is an instance of CRTP in mips-linux-tdep.c, because both mips_linux_ilp32_svr4_solib_ops and mips_linux_lp64_svr4_solib_ops need to derive from different SVR4 base classes (linux_ilp32_svr4_solib_ops and linux_lp64_svr4_solib_ops), but they both want to override the in_dynsym_resolve_code method with the same implementation. The solib_ops::supports_namespaces method is new: the support for namespaces was previously predicated by the presence or absence of a find_solib_ns method. It now needs to be explicit. There is a new progspace::release_solib_ops method, which is only needed for rocm_solib_ops. For the moment, rocm_solib_ops replaces and wraps the existing svr4_solib_ops instance, in order to combine the results of the two. The plan is to have a subsequent patch to allow program spaces to have multiple solib_ops, removing the need for release_solib_ops. Speaking of rocm_solib_ops: it previously overrode only a few methods by copying svr4_solib_ops and overwriting some function pointers. Now, it needs to implement all the methods that svr4_solib_ops implements, in order to forward the call. Otherwise, the default solib_ops method would be called, hiding the svr4_solib_ops implementation. Again, this can be removed once we have support for multiple solib_ops in a program_space. There is also a small change in how rocm_solib_ops is activated. Prior to this patch, it's done at the end of rocm_update_solib_list. Since it overrides the function pointer in the static svr4_solib_ops, and then overwrites the host gdbarch, so_ops field, it's something that happens only once. After the patch though, we need to set rocm_solib_ops in all the program spaces that appear. We do this in rocm_solib_target_inferior_created and in the new rocm_solib_target_inferior_execd. After this, I will explore doing a change where rocm_solib_ops is only set when we detect the ROCm runtime is loaded. Change-Id: I5896b5bcbf8bdb024d67980380feba1ffefaa4c9 Approved-By: Pedro Alves <pedro@palves.net>
2025-06-26gdb/progspace: add solib_ops pointer in program_spaceSimon Marchi10-37/+83
The subsequent C++ification patch in this series will allocate one instance of solib_ops per program space. That instance will be held in struct program_space. As a small step towards this, add an `solib_ops *` field to `struct program_space`. This field represents the solib_ops currently used to manage the solibs in that program space. Initialize it with the result of `gdbarch_so_ops` in `post_create_inferior`, and use it whenever we need to do some solib stuff, rather than using `gdbarch_so_ops` directly. The difficulty here is knowing when exactly to set and unset the solib ops. What I have here passes the testsuite on Linux, but with more testing we will probably discover more spots where it's needed. The C++ification patch will turn this field into a unique pointer. With this patch, the message we get when running "info linker-namespaces" becomes always the same, so update the test in gdb.base/dlmopen-ns-ids.exp. Change-Id: Ide8ddc57328895720fcd645d46dc34491f84c656 Approved-By: Pedro Alves <pedro@palves.net> Reviewed-By: Guinevere Larsen <guinevere@redhat.com>
2025-06-26gdb/solib: use solib::ops for operations that concern a single solibSimon Marchi1-21/+15
For operations that concern a single solib, use the solib_ops backlink added in the previous patch (solib::ops), instead of using the solib_ops from the gdbarch. This is a small / easy step towards not using gdbarch_so_ops, which is necessary for the C++ification patch later in this series. There is no change in behavior expected. Change-Id: If80e9ea717a2788bada1cf0940cda3c73933bcff Approved-By: Pedro Alves <pedro@palves.net>
2025-06-26gdb/solib: add solib -> solib_ops backlinkSimon Marchi8-8/+23
The subsequent C++ification commit makes it so that one struct solib_ops is instantiated for each program space. For some operations, it will then become necessary to be able to get the right solib_ops instance from a given solib. Add an solib -> solib_ops backlink for that. Change-Id: Ib95407b3fa5fcfba55cf874e0e9dcd2d43a402e4 Approved-By: Pedro Alves <pedro@palves.net>
2025-06-26gdb/solib: fix formatting of "info linker-namespaces" error messageSimon Marchi1-2/+2
Add spaces after the first period and add a period at the end, resulting in: (gdb) info linker-namespaces ❌️ Current inferior does not support linker namespaces. Use "info sharedlibrary" instead. Change-Id: Ib3f1647cedcdb68852a3c63df26ea3e6f791b1b1 Approved-By: Pedro Alves <pedro@palves.net>
2025-06-26gdb/testsuite: check that "info shared" and "info linker-namespaces" before ↵Simon Marchi2-0/+8
running don't crash While writing my solib_ops C++ification series, I broke this, and it didn't seem to be caught by the testsuite. Add a test for those. The exact message for "info linker-namespaces" varies depending on the solib_ops of the target architecture (whether ops->num_active_namespaces is nullptr or not). For now, just accept any message (a crash will still be caught). A later patch in this series will make the message consistent and update this test. Change-Id: I6bce2ff317447bbf321fc9cbd2d42c3dcea0c683 Approved-By: Pedro Alves <pedro@palves.net>
2025-06-26gprofng: need to know that experiment was created on big-endian machineVladimir Mezentsev10-6/+270
gprofng/ChangeLog 2025-06-25 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> * configure.ac: Add AC_C_BIGENDIAN. * common/config.h.in: Rebuild. * configure: Rebuild. * libcollector/collector.c (log_header_write): Save big-endian flag. * src/DbeSession.h (is_bigendian): New function. * src/DbeSession.cc: Likewise. * src/Experiment.cc: Set 'bigendian' and 'need_swap_endian'. * src/Experiment.h: New field 'bigendian'. * src/LoadObject.cc: Remove an unused variable. * src/LoadObject.h: Likewise.
generated by cgit v1.1 at 2025-08-03 02:46:34 +0000