aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
9 daysMove lnp_state_machine to new fileTom Tromey5-753/+815
This patch moves lnp_state_machine and some supporting code to a new file, dwarf2/line-program.c. The main benefit of this is shrinking dwarf2/read.c a bit. Approved-By: Simon Marchi <simon.marchi@efficios.com>
9 daysAutomatic date update in version.inGDB Administrator1-1/+1
9 daysUse type-specific lookups in cp-support.cTom Tromey1-2/+4
cp-support.c has code to substitute types for typedef names when canonicalizing a C++ name. I believe this code can use type-specific search domains; and doing this greatly speeds up some cases. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33081
9 daysAvoid symbol lookup for field names in C parserTom Tromey1-103/+193
Currently, the C parser looks up any name it finds -- at lex time. However, in an expression like "obj->field", looking up the field name is wasteful, and can sometimes even yield pathological symtab expansion behavior. This patch arranges to avoid the name lookup in this case. (It would be nice to really clean up this area, but I'm not convinced it can readily be done in a yacc parser.) Some special code is required for the C++ construct where a qualified name is used, like "obj->type1::type2::field". Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33081
9 daysChange how C parser looks up type tag namesTom Tromey1-58/+79
In an earlier version of this series, Simon noticed that something like "ptype struct type" was much slower. The deep problem here is the hack in best_symbol -- in this particular case the C parser is including SEARCH_VAR_DOMAIN, which means that a type is not "best". Fixing best_symbol would be good to do, but it's difficult and I already had many struggles getting this series to this point. So, rather than fix that, I elected to modify the parser. The key insight here is that the name lookup in classify_name is useless when a tag name is expected. This patch adds a flag so that this lookup is not done. (Incidentally, this kind of thing is much more straightforward in a recursive descent parser, something like classify_name would only be applied post-lexing where appropriate.) This change speeds up the lookup by avoiding the best_symbol hack, instead searching only for a type. Acked-By: Simon Marchi <simon.marchi@efficios.com> Reviewed-By: Guinevere Larsen <guinevere@redhat.com>
9 daysgdb: Add svr4-tls-tdep.o to list of objects of i*86 targetsSergio Durigan Junior1-1/+1
GDB currently fails to build from source on i386 if compiled with --enable-64-bit-bfd. This is happening because svr4-tls-tdep.o is missing from the gdb_target_obs variable, while amd64-linux-tdep.o is obviously there. Fix the problem by adding svr4-tls-tdep.o to the object list, but only when --enable-64-bit-bfd is provided. Signed-off-by: Sergio Durigan Junior <sergiodj@sergiodj.net> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33399
9 daysChange return value of _bfd_mmap_temporaryTom Tromey3-21/+19
_bfd_mmap_temporary will return MAP_FAILED in some cases, but only one caller was prepared for this. This caused a couple of issues in gdb. This patch chnages _bfd_mmap_temporary to always return NULL on failure. It also changes the logic to fall back to bfd_malloc if mmap fails. I took the opportunity to change some "(void *) -1" to MAP_FAILED where appropriate. Tested by "make check" in binutils, and also by applying a hack from bug 33354 to gdb and testing something approximating the original report. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32542 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33354
9 daysRequire Tcl 8.6.2Tom Tromey2-53/+7
This changes the gdb test suite to require Tcl 8.6.2. This allows the removal of some more compatibility code. I wrote this as a separate patch so make it simpler to drop if some platform only provides Tcl 8.5. According to research in the bug, though, it seems like this isn't likely. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33205 Approved-By: Simon Marchi <simon.marchi@efficios.com>
9 daysRewrite tcl_version_at_leastTom Tromey1-15/+3
tcl_version_at_least can more easily be expressed using the built-in "package" command. Approved-By: Simon Marchi <simon.marchi@efficios.com>
9 daysRequire Tcl 8.5Tom Tromey1-17/+2
This patch changes the gdb test suite to require Tcl 8.5. It also removes the one pre-8.5 compatibility function. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33205 Approved-By: Simon Marchi <simon.marchi@efficios.com>
9 daysvms-alpha: sections array index sanity checksAlan Modra1-1/+7
Adds a couple of missing bound checks. * vms-alpha.c (alpha_vms_fix_sec_rel): Sanity check relocation section index. (alpha_vms_bfd_final_link): Assert that section index is sane.
9 daysvms-alpha: ehdr checksAlan Modra1-29/+28
I noticed that _bfd_vms_slurp_ehdr wrongly used buf_size (rather than rec_size) when sanity checking. * vms-alpha.c (_bfd_vms_slurp_ehdr): Don't allow access to uninitialised buffer memory. Tidy code generally, using remaining record length for sanity checks.
9 daysPR 33385 vms archivesAlan Modra3-0/+14
Commit 5c4ce239a3ab "Tidy bfdio to consistenly use containing archive" broke vms archive handling, which has some horrible hacks involving use of a special iovec for archive elements. Modify the generic archive handling code to not use the archive iovec when it differs from the element iovec. Also, various commits involving seek optimisation broke the vms archive handling, which needs to see a rewind on an archive element. * bfdio.c (bfd_read, bfd_write, bfd_tell, bfd_flush), (bfd_stat, bfd_seek, bfd_mmap): Do not use the archive bfd for IO when the archive and element iovec differ. * plugin.c (bfd_plugin_open_input), (bfd_plugin_close_file_descriptor): Likewise. * vms-lib.c (vms_lib_bopen): Force bfd_seek to call iovec seek.
9 daysPR 33385 unsupported relocsAlan Modra1-2/+2
Commit 96d3b80f5498 changed a couple of reloc functions to return false, and propagated the error. They previously did nothing, so revert to that sad state. * vms-alpha.c (alpha_vms_add_lw_reloc): Return true. (alpha_vms_add_qw_reloc): Likewise.
9 daysPR 33385 DST handlingAlan Modra1-23/+31
Commit 816995444667, a fix for a fuzzer testcase resulting in a buffer overflow, broke reading of DST. DST is a special case where a first pass over the section just sizes it. Commit a3c0896d80d2, another buffer overflow fix, wrongly removed a line incrementing DST record length. * vms-alpha.c (image_write): Don't do bounds check for sections in memory without contents. (evax_bfd_print_dst): Add one to length.
9 daysPR 33385 EOMAlan Modra1-2/+2
Another PR 21813 modification. * vmd-alpha.c (_bfd_vms_slurp_eeom): Allow 10 byte EOM. Don't set has_transfer or access fields past 10 bytes unless the entire EEOM is there.
9 daysPR 33385, Extended Image HeaderAlan Modra2-19/+17
This modifies some of the PR 21813 fixes, allowing for smaller EIHD. Not knowing any better, I chose to use EIHD__C_LENGTH as the minimum length. include/ * vms/eihd.h (EIHD__C_LENGTH): Comment. bfd/ * vms-alpha.c (_bfd_vms_slurp_eihd): Remove size check duplicating that done by the caller of this function. (alpha_vms_object_p): Allow smaller EIHD. (evax_bfd_print_image): Likewise. Don't print fields past the record size.
9 daysbinutils: Require GNU tail for 'objdump -Wi' testH.J. Lu7-4/+76
testsuite/binutils-all/objdump.exp has set got [remote_exec host "tail -n +4 tmpdir/objdump.out" "" "/dev/null" "tmpdir/objdump.tail"] But the default Solaris tail doesn't support "tail -n +4". Add ACX_PROG_GNU_TAIL to use GNU tail for 'objdump -Wi' test. Tested on Linux and Solaris. binutils/ PR binutils/33396 * Makefile.am (check-DEJAGNU): Also export TAIL. * Makefile.in: Regenerated. * aclocal.m4: Likewise. * configure: Likewise. * configure.ac: Add ACX_PROG_GNU_TAIL. * testsuite/binutils-all/objdump.exp: Require GNU tail for 'objdump -Wi' test and replace tail with $env(TAIL). config/ PR binutils/33396 * acx.m4 (ACX_PROG_GNU_TAIL): New. Signed-off-by: H.J. Lu <hjl.tools@gmail.com> Reviewed-by: Collin Funk <collin.funk1@gmail.com>
9 daysobjdump: Check the SEC_CODE bit for codeH.J. Lu1-0/+1
If a shared library has $ readelf -D -sW x.so | grep _PROCEDURE_LINKAGE_TABLE_ 3: 00000000000002c0 0 OBJECT GLOBAL DEFAULT 5 _PROCEDURE_LINKAGE_TABLE_ $ Disassembler treats PLT0 as data: $ objdump -dw x.so x.so: file format elf64-x86-64 Disassembly of section .plt: 00000000000002c0 <_PROCEDURE_LINKAGE_TABLE_>: 2c0: ff 35 7a 01 10 00 ff 25 7c 01 10 00 0f 1f 40 00 .5z....%|.....@. 00000000000002d0 <foo@plt>: 2d0: ff 25 7a 01 10 00 jmp *0x10017a(%rip) # 100450 <foo> 2d6: 68 00 00 00 00 push $0x0 2db: e9 e0 ff ff ff jmp 2c0 <_PROCEDURE_LINKAGE_TABLE_> Disassembly of section .text: 00000000000002e0 <func>: 2e0: e8 eb ff ff ff call 2d0 <foo@plt> 2e5: c3 ret Check the SEC_CODE bit on section for code. PR binutils/33389 * objdump.c (disassemble_section): Check SEC_CODE for code. Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
10 daysgdb/testsuite: small fix for amd64-extended-prologue-analysis.expAndrew Burgess1-2/+6
I noticed I was sometimes getting this failure: FAIL: gdb.arch/amd64-extended-prologue-analysis.exp: offset \ initialization: ASM source: gdb_breakpoint: set breakpoint \ at *0x0000000000401151 The problem was introduced in commit: commit f9aa48dc545ef511e19f4dfab88a196b820fd2da Date: Thu Aug 28 11:50:13 2025 +0000 gdb, amd64: extend the amd64 prologue analyzer to skip register pushes A gdb_test_multiple exits early when processing the results of a 'disassemble' command, without waiting for the prompt to be seen. This can leave unhandled output in expect's input buffer, which will then throw off the next test. Update the gdb_test_multiple to wait for the prompt before declaring the test passed. After this I'm no longer seeing the above failure. There should be no change in what is tested after this commit.
10 daysx86: constrain and fix use of the "nojumps" .arch modifierJan Beulich7-21/+84
As said by the paragraph of the description that isn't modified here (a few lines up), this was only ever supposed to be used with 16-bit architectures. Actually enforcing this allows code in md_estimate_size_before_relax() to move to a less frequently used code path. (For backwards compatibility, keep accepting "jumps" also with 32- or 64-bit architectures.) Repeat the constraint also in the 2nd paragraph of the doc on this subject. And while there also insert a missing insn in the related i386-Jumps section. Furthermore checking a global variable during late processing is wrong. We need to record the state in the fragment, and use that rather than the state of the variable at the end of parsing all input. Seeing that there's no testing of the functionality at all, add a testcase as well.
10 daysx86: make TC_FRAG_INIT() resolve to a function callJan Beulich2-37/+25
This way we can avoid making various global variables non-static. Their set is to only ever grow, really.
10 daysbfd: Add i386_pe_big_vec vector to win64 targetsJeffrey Knockel1-1/+1
251dae91074170036c1a76c5e5df1f45197d7feb added i386_pe_big_vec to win32 targets but did not add it to win64 ones. Adding i386_pe_big_vec vector to win64 targets fixes an issue where a 64-bit assembler on windows would fail to create bigobj files when operating with 32-bit word size. E.g., before this change, with a 64-bit toolchain: $ echo 'int main(void) { return 100; }' \ | gcc -m32 -Wa,-mbig-obj -x c -c -o main.o - $ objdump.exe -f main.o main.o: file format pe-i386 architecture: i386, flags 0x00000039: HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x00000000 But after this change, the output file format is correctly bigobj: $ echo 'int main(void) { return 100; }' \ | gcc -m32 -Wa,-mbig-obj -x c -c -o main.o - $ objdump.exe -f main.o main.o: file format pe-bigobj-i386 architecture: i386, flags 0x0000003d: HAS_RELOC, HAS_LINENO, HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x00000000 Although the above multilib compilation issue was the motivation for this patch, this change has other positive consequences, such as allowing the 64-bit windows build of objdump to disassemble pe-bigobj-i386 format object files, etc. Signed-off-by: Jeffrey Knockel <jeff@jeffreyknockel.com>
10 daysMicroBlaze: Add microblaze_get_next_pcsGopi Kumar Bulusu1-0/+94
This patch enables software single stepping for gdbserver target Includes fix for Bug 33381 using core_addr_to_string_nz * gdb/microblaze-tdep.c: Add microblaze_get_next_pcs Signed-off-by: David Holsgrove <david.holsgrove@petalogix.com> Signed-off-by: Nathan Rossi <nathan.rossi@petalogix.com> Signed-off-by: Mahesh Bodapati <mbodapat@xilinx.com> Signed-off-by: Gopi Kumar Bulusu <gopi@sankhya.com> Approved-By: Simon Marchi <simon.marchi@efficios.com>
10 daysAutomatic date update in version.inGDB Administrator1-1/+1
10 daysld: Limit "readelf --got-contents" testsH.J. Lu2-46/+63
Since "readelf --got-contents" tests use -melf_i386, -melf_x86_64 and -melf32_x86_64 emulations, limit theses tests to linker supporting those emulations, pass --rosegment to linker and output libgot-1-i386.so, libgot-1-x64.so, libgot-1-x32.so. PR ld/33350 * testsuite/ld-i386/binutils.exp: Limit tests to linker with -melf_i386 support, pass --rosegment to linker and output libgot-1-i386.so. * testsuite/ld-x86-64/binutils.exp: Limit -melf_x86_64 tests to linker with -melf_x86_64 support, limit -melf32_x86_64 tests to linker with -melf32_x86_64 support, pass --rosegment to linker and output libgot-1-x64.so/libgot-1-x32.so. Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
10 dayself: Define more SHT_SUNW_XXXH.J. Lu2-21/+59
binutils/ * readelf.c (get_solaris_section_type): Use SHT_SUNW_XXX and add SHT_SUNW_phname and SHT_SUNW_symtabnsort. include/ * elf/common.h (SHT_SUNW_symtabnsort): New. (SHT_SUNW_ancillary): Likewise. (SHT_SUNW_capchain): Likewise. (SHT_SUNW_capinfo): Likewise. (SHT_SUNW_symsort): Likewise. (SHT_SUNW_tlssort): Likewise. (SHT_SUNW_LDYNSYM): Likewise. (SHT_SUNW_dof): Likewise. (SHT_SUNW_cap): Likewise. (SHT_SUNW_SIGNATURE): Likewise. (SHT_SUNW_ANNOTATE): Likewise. (SHT_SUNW_DEBUGSTR): Likewise. (SHT_SUNW_DEBUG): Likewise. (SHT_SUNW_verdef): Likewise. (SHT_SUNW_verneed): Likewise. (SHT_SUNW_versym): Likewise. Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
11 days[gdb/testsuite] Error out on clean_restart <absolute filename>Tom de Vries2-0/+7
Error out in proc clean_restart if the argument is an absolute filename. Likewise in proc mi_clean_restart. Tested on x86_64-linux.
11 daysREADME: don't talk about libg++Sam James1-3/+3
Gone since 2001 or so.
11 daysgdb: Add i386-gnu-tdep to the list of objects for x86_64-*-gnu*Sergio Durigan Junior1-1/+1
When starting GDB on Hurd amd64, one will currently see the following warning: # gdb -q gdb: warning: A handler for the OS ABI "GNU/Hurd" is not built into this configuration of GDB. Attempting to continue with the default i386 settings. (gdb) This happens because, in gdb/configure.tgt, the "x86_64-*-gnu*" target is not pulling in the i386-gnu-tdep.o object, which means that only 64-bit debugging is currently supported. The fix here is to add i386-gnu-tdep.o to the gdb_target_obs for Hurd amd64. Signed-off-by: Sergio Durigan Junior <sergiodj@sergiodj.net> Suggested-by: Andrew Burgess <aburgess@redhat.com> Reported-by: Mark Wielaard <mark@klomp.org> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33377 Approved-by: Kevin Buettner <kevinb@redhat.com>
11 daysAutomatic date update in version.inGDB Administrator1-1/+1
11 daysUpdate gdb/NEWS after GDB 17 branch creation.Joel Brobecker1-1/+3
This commit a new section for the next release branch, and renames the section of the current branch, now that it has been cut.
11 daysBump version to 18.0.50.DATE-git.Joel Brobecker1-1/+1
Now that the GDB 17 branch has been created, this commit bumps the version number in gdb/version.in to 18.0.50.DATE-git For the record, the GDB 17 branch was created from commit 46ada32fc979550ad4f46792b74c182bb7232aeb.
11 daysUpdate x86: Add GLIBC_ABI_GNU2_TLS version dependencygdb-17-branchpointH.J. Lu1-1/+1
commit 0d1e88f8bfb0e62f37bf8a89172cd91373ace5e6 Author: H.J. Lu <hjl.tools@gmail.com> Date: Fri Jul 4 08:39:03 2025 +0800 x86: Add GLIBC_ABI_GNU2_TLS version dependency added solaris2-x86-64.em to accommodate moving x86-64 specific extra emulation bits to elf-x86-64.em. Update emulparams/elf_x86_64_sol2.sh to use it. * emulparams/elf_x86_64_sol2.sh (EXTRA_EM_FILE): Set to "solaris2-x86-64". Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
12 daysRe: tekhex test for commit bf0f85df1254Alan Modra1-1/+1
* testsuite/binutils-all/objcopy.exp (objcopy_tek2bin): Correct isremote to is_remote.
12 daysAutomatic date update in version.inGDB Administrator1-1/+1
12 daysbfd: configure.ac: Fix mention of flag to enable 64-bit BFD in commentThiago Jung Bauermann2-2/+2
It was changed back in 1994. Fixing because it misled me into using the wrong flag in a build.
12 daysAllow conversion of 128-bit integers to PythonTom Tromey2-6/+58
Currently, trying to convert a 128-bit integer from a gdb.Value to a Python integer will fail. This is surprising because Python uses bigints internally. The bug here is that valpy_long uses value_as_long, which fails for anything wider than LONGEST. This patch fixes the problem by using the recommended Python API. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33366 Approved-By: Simon Marchi <simon.marchi@efficios.com>
12 days[gdb/testsuite] Fix clean_restart <absolute filename> in gdb.base, part 3Tom de Vries6-9/+16
Fix fallout in gdb.base from erroring out on clean_restart <absolute filename>. Tested on x86_64-linux.
12 days[gdb/testsuite] Fix clean_restart <absolute filename> in gdb.base, part 2Tom de Vries31-42/+69
Manually fix the test-cases found by: ... $ find gdb/testsuite/gdb.base -name *.exp* \ | xargs grep -l 'clean_restart[^;]*binfile' $ find gdb/testsuite/gdb.base -name *.exp* \ | xargs grep -l 'prepare_for_testing.*bin' ... except for gdb.base/foll-vfork.exp and gdb.base/solib-overlap.exp. Tested on x86_64-linux.
12 days[gdb/testsuite] Fix clean_restart <absolute filename> in gdb.base, part 1Tom de Vries192-250/+500
Run: ... $ find gdb/testsuite/gdb.base/ -name *.exp* \ | xargs sed -i 's/^\([ \t]*\)clean_restart $binfile$/\1clean_restart\n\1gdb_load $binfile/' $ find gdb/testsuite/gdb.base/ -name *.exp* \ | xargs sed -i 's/^\([ \t]*\)clean_restart ${binfile}$/\1clean_restart\n\1gdb_load $binfile/' $ find gdb/testsuite/gdb.base/ -name *.exp* \ | xargs sed -i 's/^\([ \t]*\)clean_restart $::binfile$/\1clean_restart\n\1gdb_load $::binfile/' $ find gdb/testsuite/gdb.base/ -name *.exp* \ | xargs sed -i 's/^\([ \t]*\)clean_restart ${::binfile}$/\1clean_restart\n\1gdb_load $::binfile/' ... Revert the change in test-case gdb.base/foll-vfork.exp, which does 'set binfile $testfile'. Tested on x86_64-linux. The only modified test-case I was not able to test is gdb.base/dtrace-probe.exp (filed PR testsuite/33379 about this). The change in the test-case is trivial though.
13 daysreadelf: Handle 0 sh_entsize of GOT sectionsH.J. Lu1-0/+19
Gold, lld and mold set sh_entsize to 0 on .got and .got.plt sections. If sh_entsize of GOT sections is 0, assume 8 for ELFCLASS64 and 4 for ELFCLASS32, except for x32 which uses 8. PR binutils/33368 * readelf.c (process_got_section_contents): Handle 0 sh_entsize of GOT sections. Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
13 daysRevert "MicroBlaze: Add microblaze_get_next_pcs"Gopi Kumar Bulusu1-93/+0
This reverts commit c6df5d79aac5c4a77c06314fd26c837470360f70. Causes buildbot failure. Bug 33381
13 daysgdb: ensure bp_location::section is set correct to avoid an assertAndrew Burgess2-1/+11
While reviewing and testing another patch I set a breakpoint on an gnu ifunc function, then restarted the inferior, and this assert triggered: ../../src/gdb/breakpoint.c:14747: internal-error: breakpoint_free_objfile: Assertion `loc->symtab == nullptr' failed. The backtrace at the time of the assert is: #6 0x00000000005ffee0 in breakpoint_free_objfile (objfile=0x4064b30) at ../../src/gdb/breakpoint.c:14747 #7 0x0000000000c33ff2 in objfile::~objfile (this=0x4064b30, __in_chrg=<optimized out>) at ../../src/gdb/objfiles.c:478 #8 0x0000000000c38da6 in std::default_delete<objfile>::operator() (this=0x7ffc1a49d538, __ptr=0x4064b30) at /usr/include/c++/9/bits/unique_ptr.h:81 #9 0x0000000000c3782a in std::unique_ptr<objfile, std::default_delete<objfile> >::~unique_ptr (this=0x7ffc1a49d538, __in_chrg=<optimized out>) at /usr/include/c++/9/bits/unique_ptr.h:292 #10 0x0000000000caf1bd in owning_intrusive_list<objfile, intrusive_base_node<objfile> >::erase (this=0x3790d68, i=...) at ../../src/gdb/../gdbsupport/owning_intrusive_list.h:111 #11 0x0000000000cacd0c in program_space::remove_objfile (this=0x3790c80, objfile=0x4064b30) at ../../src/gdb/progspace.c:192 #12 0x0000000000c33e1c in objfile::unlink (this=0x4064b30) at ../../src/gdb/objfiles.c:408 #13 0x0000000000c34fb9 in objfile_purge_solibs (pspace=0x3790c80) at ../../src/gdb/objfiles.c:729 #14 0x0000000000edf6f7 in no_shared_libraries (pspace=0x3790c80) at ../../src/gdb/solib.c:1359 #15 0x0000000000fb3f6c in target_pre_inferior () at ../../src/gdb/target.c:2466 #16 0x0000000000a724d7 in run_command_1 (args=0x0, from_tty=0, run_how=RUN_NORMAL) at ../../src/gdb/infcmd.c:390 #17 0x0000000000a72a97 in run_command (args=0x0, from_tty=0) at ../../src/gdb/infcmd.c:514 #18 0x00000000006bbb3d in do_simple_func (args=0x0, from_tty=0, c=0x39124b0) at ../../src/gdb/cli/cli-decode.c:95 #19 0x00000000006c1021 in cmd_func (cmd=0x39124b0, args=0x0, from_tty=0) at ../../src/gdb/cli/cli-decode.c:2827 The function breakpoint_free_objfile is being called when an objfile representing a shared library is being unloaded ahead of the inferior being restarted, the function is trying to remove references to anything that could itself reference the objfile that is being deleted. The assert is making the claim that, for a bp_location, which has a single address, the objfile of the symtab associated with the location will be the same as the objfile associated with the section of the location. This seems reasonable to me now, as it did when I added the assert in commit: commit 5066f3680667ec0f2d1745847a2372d85973a1e7 Date: Mon Nov 11 21:45:17 2024 +0000 gdb: do better in breakpoint_free_objfile The bp_location::section is maintained, according to the comments in breakpoint.h, to aid overlay debugging (is that even used any more), and looking at the code, this does appear to be the case. The problem in the above case arises when we are dealing with an ifunc function. What happens is that we end up with a section from one objfile, but a symtab from a different objfile. This problem originates from minsym_found (in linespec.c). The user asked for 'break gnu_ifunc' where 'gnu_ifunc' is an ifunc function. What this means is that gnu_ifunc is actually a resolver function that returns the address of the actual function to use. In this particular test case, the resolver function is in a shared library, and the actual function to use is in the main executable. So, when GDB looks for 'gnu_ifunc' is finds the minimal_symbol with that name, and spots that this has type mst_text_gnu_ifunc. GDB then uses this to figure out the actual address of the function that will be run. GDB then creates the symtab_and_line using the _real_ address and the symtab in which that address lies, in our case this will all be related to the main executable objfile. But, finally, in minsym_found, GDB fills in the symtab_and_line's section field, and this is done using the section containing the original minimal_symbol, which is from the shared library objfile. The minimal symbol and section are then use to initialise the bp_location object, and this is how we end up in, what I think, is an unexpected state. So what to do about this? The symtab_and_line::msymbol field is _only_ set within minsym_found, and is then _only_ used to initialise the bp_location::msymbol field. The bp_location::msymbol field is _only_ used in the function set_breakpoint_location_function, and we only really care about the msymbol type, we check to see if it's an ifunc symbol or not. This allows us to set the name of the function correctly. The bp_location::section is used, as far as I can tell, extensively for overlay handling. It would seem to me, that this section should be the section containing the actual breakpoint address. If the question we're asking is, is this breakpoint mapped in or not? Then surely we need to ask about the section holding the breakpoint's address, and not the section holding some other code (e.g. the resolver function). In fact, in a memory constrained environment, you'd expect the resolver functions to get mapped out pretty early on, but while the actual functions might still be mapped in. Finally, symtab_and_line::section. This is mostly set using calls to find_pc_overlay. The minsym_found function is one of the few places where we do things differently. In the places where the section is used, it is (almost?) always used in conjunction with the symtab_and_line::pc to lookup information, e.g. calls to block_for_pc_sect, or find_pc_sect_containing_function. In all these cases, it appears to me that the assumption is that the section will be the section that contains the address. So, where does this leave us? I think what we need to do is update minsym_found to just use find_pc_overlay, which is how the symtab_and_line::section is set in most other cases. What this actually means in practise is that the section field will be set to NULL (see find_pc_overlay in symfile.c). But given that this is how the section is computed in most other cases, I don't see why it should be especially problematic for this case. In reality, I think this just means that the section is calculated via a call to find_pc_section when it's needed, as an example, see lookup_minimal_symbol_by_pc_section (minsyms.c). I do wonder if we should be doing better when creating the symtab_and_line, and insist that the section be calculated correctly at that point, but I really don't want to open that can of worms right now, so I think just changing minsym_found to "do it just like everyone else" should be good enough. I've extended the existing ifunc test to expose this issue, the updated test fails without this patch, and passes with. Approved-By: Simon Marchi <simon.marchi@efficios.com>
13 daysgdb: pass core file to gdbarch_core_read_x86_xsave_layoutAndrew Burgess8-16/+18
Continuing the removal of 'current_program_space->core_bfd ()' from GDB, this commit updates the gdbarch method 'gdbarch_core_read_x86_xsave_layout' to take the core file BFD as a reference parameter. For now this just moves the 'current_program_space->core_bfd ()' calls up the program stack into core_target::fetch_x86_xsave_layout. In the future I plan to move the core file BFD object out of the program_space and into the core_target, at which point these new global accesses can also be removed. There should be no user visible changes after this commit. Approved-By: Simon Marchi <simon.marchi@efficios.com>
13 daysgdb: pass core file to gdbarch_core_thread_name methodAndrew Burgess5-13/+17
Continuing the removal of 'current_program_space->core_bfd ()' from GDB, this commit updates the gdbarch method 'gdbarch_core_thread_name' to take the core file BFD as a reference parameter. For now this just moves the 'current_program_space->core_bfd ()' calls up the program stack into core_target::thread_name. In the future I plan to move the core file BFD object out of the program_space and into the core_target, at which point these new global accesses can also be removed. There should be no user visible changes after this commit. Approved-By: Simon Marchi <simon.marchi@efficios.com>
13 daysgdb: pass core file through gdbarch API when loading shared librariesAndrew Burgess7-24/+32
Continuing the removal of 'current_program_space->core_bfd ()' from GDB, this commit updates two gdbarch methods: gdbarch_core_xfer_shared_libraries gdbarch_core_xfer_shared_libraries_aix to take the core file BFD as a reference parameter. For now this just moves the 'current_program_space->core_bfd ()' calls up the program stack into core_target::xfer_partial. In the future I plan to move the core file BFD object out of the program_space and into the core_target, at which point these new global accesses can also be removed. There should be no user visible changes after this commit. Approved-By: Simon Marchi <simon.marchi@efficios.com>
13 days[gdb/testsuite] Fix gdb.base/fileio.exp for local-remote-host-nativeTom de Vries2-1/+5
When running test-case gdb.base/fileio.exp with host/target board local-remote-host-native I run into: ... gdb compile failed, fileio.c: In function 'test_open': <command-line>:0:8: error: expected expression before '.' token fileio.c:89:15: note: in expansion of macro 'OUTDIR' ret = open (OUTDIR FILENAME, O_CREAT | O_TRUNC | O_RDWR, S_IWUSR | S_IRUSR); ^~~~~~ ... Fix this by using: - quote_for_host to pass -DOUTDIR to the compilation, and - STRINGIFY to stringify OUTDIR in fileio.c. Tested on x86_64-linux, with target board unix and host/target board local-remote-host-native.
13 daysMicroBlaze: Add microblaze_get_next_pcsGopi Kumar Bulusu1-0/+93
This patch enables software single stepping for gdbserver target * gdb/microblaze-tdep.c: Add microblaze_get_next_pcs Signed-off-by: David Holsgrove <david.holsgrove@petalogix.com> Signed-off-by: Nathan Rossi <nathan.rossi@petalogix.com> Signed-off-by: Mahesh Bodapati <mbodapat@xilinx.com> Signed-off-by: Gopi Kumar Bulusu <gopi@sankhya.com> Approved-By: Simon Marchi <simon.marchi@efficios.com>
13 days[gdb/testsuite] Fix clean_restart <absolute filename> in allow_aarch64_sme_testsTom de Vries1-1/+2
Fix fallout on aarch64-linux with test-case gdb.testsuite/gdb-caching-proc-consistency.exp from erroring out on clean_restart <absolute filename>.
generated by cgit v1.1 at 2025-09-18 00:04:10 +0000