aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2024-10-14gdb/testsuite: fix gdb.multi/inferior-specific-bp.expGuinevere Larsen1-1/+2
A recent commit, "16a6f7d2ee3 gdb: avoid breakpoint::clear_locations calls in update_breakpoint_locations", started checking if GDB correctly relocates a breakpoint from inferior 1's declaration of the function "bar" to inferior 2's declaration. Unfortunately, inferior 2 never calls bar in its regular execution, and because of that, clang would optimize that whole function away, making it so there is no location for the breakpoint to be relocated to. This commit changes the .c file so that the function is not optimized away and the test fully passes with clang. It is important to actually call bar instead of using __attribute__((used)) because the latter causes the breakpoint locations to be inverted, 3.1 belongs to inferior 2 and 3.2 belongs to inferior 1, which will cause an unrelated failure. Approved-By: Andrew Burgess <aburgess@redhat.com>
2024-10-14ia64/ELF: fix HPUX testsuite falloutJan Beulich3-13/+13
... from 1f1b5e506bf0 ("bfd/ELF: restrict file alignment for object files"), as noticed / reported by Alan.
2024-10-14x86: also template-expand trailing mnemonic partJan Beulich1-60/+72
So far template expansion was limited to fields other than the insn mnemonic. In order to be able to use <fop> also for AVX10.2 we want the trailing mnemonic part to also be expanded. Split out the respective piece of code into a helper function, which is then invoked twice.
2024-10-14gas: drop SKIP_WHITESPACE_AFTER_NAME()Jan Beulich21-98/+85
Exclusively all users should use restore_line_pointer() instead, at which point SKIP_WHITESPACE() suffices as a check afterwards.
2024-10-14gdb: make frame_unwind_try_unwinder return boolGuinevere Larsen1-6/+6
Before this commit, the function frame_unwind_try_unwinder would return an int, where 1 meant the unwinder works, and 0 it doesn't. This is just a boolean with extra steps, so this commit updates the function to return bool instead.
2024-10-14LoongArch: Fixed R_LARCH_[32/64]_PCREL generation bugLulu Cai4-2/+22
The enum BFD_RELOC_[32/64] was mistakenly used in the macro instead of the relocation in fixp. This can cause the second relocation of a pair to be deleted when -mthin-add-sub is enabled. Apply the correct macro to fix this. Also sets the initial value of -mthin-add-sub.
2024-10-14Automatic date update in version.inGDB Administrator1-1/+1
2024-10-13Fix 32110 gprofng segfaults on parsing DWARF of clang++ 18.1.3 produced binaryVladimir Mezentsev1-5/+33
gprofng does not handle DW_FORM_strx1* forms correctly. gprofng/ChangeLog 2024-10-10 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> PR 32110 * src/DwarfLib.cc: Handle DW_FORM_strx* forms.
2024-10-13Automatic date update in version.inGDB Administrator1-1/+1
2024-10-12Add to GDB manual information about building index with 'gold'Robert Guthrie1-0/+13
* gdb/doc/gdb.texinfo (Index Files): New subsection about building the index using 'gold'. Copyright-paperwork-exempt: yes
2024-10-12Automatic date update in version.inGDB Administrator1-1/+1
2024-10-11gdbserver: remove declaration of init_registers_arm_with_neonAndrew Burgess1-1/+0
The last use of init_registers_arm_with_neon was removed in this commit: commit 7cc17433020a62935e4d91053251fe900d83c7f0 Date: Fri Jul 19 15:04:48 2019 +0100 Arm: Use read_description funcs in gdbserver But the declaration was left around. Remove the declaration now.
2024-10-11Revert "gdbserver: pass osabi to GDB in target description"Andrew Burgess16-41/+18
This reverts commit 98bcde5e268ea7cd54186c5f2c27c65103218fc3. This commit was causing build problems on at least sparc, ppc, and s390, though I suspect some other targets might be impacted too.
2024-10-11x86: bring 64-bit-only cmdline option handling in syncJan Beulich1-2/+8
--64 and --x32 are already suppressed in --help output when BFD64 is not defined. Also avoid recognizing these options in such configurations.
2024-10-11bfd/ELF: drop align_file_position()Jan Beulich1-10/+1
Switch the sole user to BFD_ALIGN() instead. (It's comment was partly wrong [stale?] anyway, talking of some maximum that was nowhere in sight.)
2024-10-11bfd/ELF: restrict file alignment for object filesJan Beulich12-54/+70
While for executables properly aligning sections within the file can be quite relevant, the same is of pretty little importance for relocatable object files. Avoid passing "true" into _bfd_elf_assign_file_position_for_section() when dealing with object files, but compensate minimally by applying log_file_align in such cases as a cap to the alignment put in place.
2024-10-11Support Intel AVX10.2 media instructionsHaochen Jiang25-702/+2497
In disassembler part, for vnni instructions, we extended previous VEX part using %XE in disassembler to promote them to EVEX by reusing the original VEX table. For vmpsadbw, we will also use %XE. However, it is hard to reuse the VEX table, so we are using new ones. In assmbler part, we put the vnni table entries with previous vnni instructions since they are just promotion from AVX-VNNI-INT{8,16}. Since we will prefer VEX encoding, we need to use the different table order in template <vnni>, which prefers EVEX due to earlier introduction for AVX512_VNNI than AVX_VNNI. This means a new <vnni>. For vdpphps and vmpsadbw, we put them at the end of the table, with future AVX10.2 instructions. Nit: I will remove the arch requirement for avx_vnni_int{8,16} in evex-promote testcases after AVX10.2 implies AVX-VNNI-INT{8,16}. gas/Changelog: * testsuite/gas/i386/i386.exp: Add AVX10.2 tests. * testsuite/gas/i386/x86-64.exp: Ditto. * testsuite/gas/i386/avx10_2-256-1-intel.d: New. * testsuite/gas/i386/avx10_2-256-1.d: Ditto. * testsuite/gas/i386/avx10_2-256-1.s: Ditto. * testsuite/gas/i386/avx10_2-512-1-intel.d: Ditto. * testsuite/gas/i386/avx10_2-512-1.d: Ditto. * testsuite/gas/i386/avx10_2-512-1.s: Ditto. * testsuite/gas/i386/avx10_2-promote.d: Ditto. * testsuite/gas/i386/avx10_2-promote.s: Ditto. * testsuite/gas/i386/x86-64-avx10_2-256-1-intel.d: Ditto. * testsuite/gas/i386/x86-64-avx10_2-256-1.d: Ditto. * testsuite/gas/i386/x86-64-avx10_2-256-1.s: Ditto. * testsuite/gas/i386/x86-64-avx10_2-512-1-intel.d: Ditto. * testsuite/gas/i386/x86-64-avx10_2-512-1.d: Ditto. * testsuite/gas/i386/x86-64-avx10_2-512-1.s: Ditto. * testsuite/gas/i386/x86-64-avx10_2-promote.d: Ditto. * testsuite/gas/i386/x86-64-avx10_2-promote.s: Ditto. opcodes/Changelog: * i386-dis-evex-prefix.h: Adjust PREFIX_EVEX_0F3852. Add PREFIX_EVEX_0F3A42_W_0. * i386-dis-evex-w.h: Adjust EVEX_W_0F3A42. * i386-dis-evex.h: Add table pass for AVX10.2 instructions. * i386-dis.c: Adjust PREFIX_VEX_0F3850_W_0, PREFIX_VEX_0F3851_W_0, PREFIX_VEX_0F38D2_W_0 and PREFIX_VEX_0F38D3_W_0. * i386-opc.tbl: Add AVX10.2 instructions. * i386-mnem.h: Regenerated. * i386-tbl.h: Ditto. Co-authored-by: Lili Cui <lili.cui@intel.com>
2024-10-11Automatic date update in version.inGDB Administrator1-1/+1
2024-10-11gprofng: Use $(DESTDIR) in install-examplesH.J. Lu2-5/+4
Use $(DESTDIR) in install-examples to fix mkdir -p -- /usr/share/doc//gprofng mkdir: cannot create directory ‘/usr/share/doc//gprofng’: Permission denied for "make install DESTDIR=...". * doc/Makefile.am (install-examples): Use $(DESTDIR). * doc/Makefile.in: Regenerated. Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
2024-10-10gprofng: install examples to $(docdir)/gprofngVladimir Mezentsev2-3/+19
gprofng/ChangeLog 2024-10-09 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> * doc/Makefile.am: Install gprofng examples. * doc/Makefile.in: Rebuild.
2024-10-10gdbserver: pass osabi to GDB in target descriptionAndrew Burgess16-18/+41
On a Windows machine I built gdbserver, configured for the target 'x86_64-w64-mingw32', then on a GNU/Linux machine I built GDB with support for all target (--enable-targets=all). On the Windows machine I start gdbserver with a small test binary: $ gdbserver 192.168.129.25:54321 C:\some\directory\executable.exe On the GNU/Linux machine I start GDB without the test binary, and connect to gdbserver. As I have not given GDB the test binary, my expectation is that GDB would connect to gdbserver and then download the file over the remote protocol, but instead I was presented with this message: (gdb) target remote 192.168.129.25:54321 Remote debugging using 192.168.129.25:54321 warning: C:\some\directory\executable.exe: No such file or directory. 0x00007ffa3e1e1741 in ?? () (gdb) What I found is that if I told GDB where to find the binary, like this: (gdb) file target:C:/some/directory/executable.exe A program is being debugged already. Are you sure you want to change the file? (y or n) y Reading C:/some/directory/executable.exe from remote target... warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead. Reading C:/some/directory/executable.exe from remote target... Reading symbols from target:C:/some/directory/executable.exe... (gdb) then GDB would download the executable. I eventually tracked the problem down to exec_file_find (solib.c). The remote target was passing an absolute Windows filename (beginning with "C:/" in this case), but in exec_file_find GDB was failing the IS_TARGET_ABSOLUTE_PATH call, and so was treating the filename as relative. The IS_TARGET_ABSOLUTE_PATH call was failing because GDB thought that the file system kind was "unix", and as the filename didn't start with a "/" it assumed the filename was not absolute. But I'm connecting to a Windows target, my 'target-file-system-kind' was set to "auto", so should be figuring out that my file-system is "dos-based". Looking in effective_target_file_system_kind (filesystem.c), we find that the logic of "auto" is delegated to the current gdbarch. However in windows-tdep.c we see: set_gdbarch_has_dos_based_file_system (gdbarch, 1); So if we are using a Windows gdbarch we should have "dos-based" filesystems. What this means is that after connecting to the remote target GDB has selected the wrong gdbarch. What's happening is that the target description sent back by the remote target only includes the x86-64 registers. There's no information about which OS we're on. As a consequence, GDB picks the first x86-64 gdbarch which can handle the provided register set, which happens to be a GNU/Linux gdbarch. And indeed, there doesn't appear to be anywhere in gdbserver that sets the osabi on the target descriptions, though some target descriptions do have their osabi set when the description is created, e.g. in: gdb/arch/amd64.c - Sets GNU/Linux osabi when appropriate. gdb/arch/i386.c - Likewise. gdb/arch/tic6x.c - Always set GNU/Linux osabi. Most target descriptions are created without an osabi, gdbserver does nothing to fix this, and the description is returned to GDB without an osabi included. I propose that we always set the osabi name on the target descriptions returned from gdbserver. We could try to do this when the description is first created, but that would mean passing extra flags into the tdesc creation code (or just passing the osabi string in), and I don't think that's really necessary. If we consider the tdesc creation as being about figuring out which registers are on the target, then it makes sense that the osabi information is injected later. So what I've done is require the osabi name to be passed to the init_target_desc function. This is called, I believe, for all targets, in the gdbserver code. Now when I connect to the Windows remote the target description returned includes the osabi name. With this extra information GDB selects the correct gdbarch object, which means that GDB understands the target has a "dos-based" file-system. With that correct GDB understands that the filename it was given is absolute, and so fetches the file from the remote as we'd like. Approved-By: Luis Machado <luis.machado@arm.com> Approved-By: Simon Marchi <simon.marchi@efficios.com>
2024-10-10gdb/gdbserver: change shared set_tdesc_osabi to take gdb_osabiAndrew Burgess14-21/+52
There is a single declaration of set_tdesc_osabi that is shared between gdbserver/ and gdb/, this declaration takes a 'const char *' argument which is the string representing an osabi. Then in gdb/ we have an overload of set_tdesc_osabi which takes an 'enum gdb_osabi'. In this commit I change the shared set_tdesc_osabi to be the version which takes an 'enum gdb_osabi', and I remove the version which takes a 'const char *'. All users of set_tdesc_osabi are updated to pass an 'enum gdb_osabi'. The features/ code, which is generated from the xml files, requires a new function to be added to osabi.{c,h} which can return a string representation of an 'enum gdb_osabi'. With that new function in place the features/ code is regenerated. This change is being made to support the next commit. In the next commit gdbserver will be updated to call set_tdesc_osabi in more cases. The problem is that gdbserver stores the osabi as a string. The issue here is that a typo in the gdbserver/ code might go unnoticed and result in gdbserver sending back an invalid osabi string. To fix this we want gdbserver to pass an 'enum gdb_osabi' to the set_tdesc_osabi function. With that requirement in place it seems to make sense if all calls to set_tdesc_osabi pass an 'enum gdb_osabi'. There should be no user visible changes after this commit. Approved-By: Luis Machado <luis.machado@arm.com> Approved-By: Simon Marchi <simon.marchi@efficios.com>
2024-10-10gdb: split osabi support between gdb/ and gdbsupport/ directoriesAndrew Burgess7-137/+220
In future commits I want to call set_tdesc_osabi from gdbserver/ code. Currently the only version of set_tdesc_osabi available to gdbserver takes a string representing the osabi. The problem with this is that, having lots of calls to set_tdesc_osabi which all take a string is an invite for a typo to slip in. This typo could potentially go unnoticed until someone tries to debug the wrong combination of GDB and gdbserver, at which point GDB will fail to find the correct gdbarch because it doesn't understand the osabi string. It would be better if the set_tdesc_osabi calls in gdbserver could take an 'enum gdb_osabi' value and then convert this to the "correct" string internally. In this way we are guaranteed to always have a valid, known, osabi string. This commit splits the osabi related code, which currently lives entirely on the GDB side, between gdb/ and gdbsupport/. I've moved the enum definition along with the array of osabi names into gdbsupport/. Then all the functions that access the names list, and which convert between names and enum values are also moved. I've taken the opportunity of this move to add a '.def' file which contains all the enum names along with the name strings. This '.def' file is then used to create 'enum gdb_osabi' as well as the array of osabi name strings. By using a '.def' file we know that the enum order will always match the name string array. This commit is just a refactor, there are no user visible changes after this commit. This commit doesn't change how gdbserver sets the target description osabi string, that will come in the next commit. Approved-By: Luis Machado <luis.machado@arm.com> Approved-By: Simon Marchi <simon.marchi@efficios.com>
2024-10-10gdb: make use of set_tdesc_osabi overload in features/ filesAndrew Burgess6-6/+6
There are two versions of the set_tdesc_osabi function in GDB: void set_tdesc_osabi (struct target_desc *target_desc, const char *name) { set_tdesc_osabi (target_desc, osabi_from_tdesc_string (name)); } void set_tdesc_osabi (struct target_desc *target_desc, enum gdb_osabi osabi) { target_desc->osabi = osabi; } In the gdb/features/ files we call the second of these functions, like this: set_tdesc_osabi (result.get (), osabi_from_tdesc_string ("GNU/Linux")); This can be replaced with a call to the first set_tdesc_osabi function, so lets do that. I think that this makes the features/ code slightly simpler and easier to understand. There should be no user visible changes after this commit. Approved-By: Tom Tromey <tom@tromey.com> Approved-By: Simon Marchi <simon.marchi@efficios.com>
2024-10-10gdbserver: make arch and osabi names gdb::unique_xmalloc_ptr<char>Andrew Burgess2-15/+7
Convert target_desc::arch and target_desc::osabi from 'const char*' to gdb::unique_xmalloc_ptr<char>. This also allows us to remove the user defined ~target_desc destructor. I doubt it ever actually occurred, but in theory at least, there was a memory leak in set_tdesc_architecture and set_tdesc_osabi where the member variables were assigned without freeing any previous value... but I suspect that usually these fields are only set once. There should be no user visible changes after this commit. Approved-By: Tom Tromey <tom@tromey.com> Approved-By: Simon Marchi <simon.marchi@efficios.com>
2024-10-10[gdb/breakpoints] Fix gdb.base/scope-hw-watch-disable.exp on arm-linuxTom de Vries2-47/+71
On arm-linux, with test-case gdb.base/scope-hw-watch-disable.exp I run into: ... (gdb) awatch a^M Can't set read/access watchpoint when hardware watchpoints are disabled.^M (gdb) PASS: $exp: unsuccessful attempt to create an access watchpoint rwatch b^M Can't set read/access watchpoint when hardware watchpoints are disabled.^M (gdb) PASS: $exp: unsuccessful attempt to create a read watchpoint continue^M Continuing.^M ^M Program received signal SIGSEGV, Segmentation fault.^M 0xf7ec82c8 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6^M (gdb) FAIL: $exp: continue until exit ... Using "maint info break", we can see that the two failed attempts to set a watchpoint each left behind a stale "watchpoint scope" breakpoint: ... -5 watchpoint scope del y 0xf7ec569a inf 1 -5.1 y 0xf7ec569a inf 1 stop only in stack frame at 0xfffef4f8 -6 watchpoint scope del y 0xf7ec569a inf 1 -6.1 y 0xf7ec569a inf 1 stop only in stack frame at 0xfffef4f8 ... The SIGSEGV is a consequence of the stale "watchpoint scope" breakpoint: the same happens if we: - have can-use-hw-watchpoints == 1, - set one of the watchpoints, and - continue to exit. The problem is missing symbol info on libc which is supposed to tell which code is thumb. After doing "set arm fallback-mode thumb" the SIGSEGV disappears. Extend the test-case to check the "maint info break" command before and after the two failed attempts, to make sure that we catch the stale "watchpoint scope" breakpoints also on x86_64-linux. Fix this in watch_command_1 by moving creation of the "watchpoint scope" breakpoint after the call to update_watchpoint. Tested on x86_64-linux. PR breakpoints/31860 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31860
2024-10-10s390: Add arch15 instructionsAndreas Krebbel10-7/+334
opcodes/ * s390-mkopc.c (main) Accept arch15 as CPU string. * s390-opc.txt: Add arch15 instructions. include/ * opcode/s390.h (enum s390_opcode_cpu_val): Add S390_OPCODE_ARCH15. gas/ * config/tc-s390.c (s390_parse_cpu): New entry for arch15. * doc/c-s390.texi: Document arch15 march option. * doc/as.texi: Likewise. * testsuite/gas/s390/s390.exp: Run the arch15 related tests. * testsuite/gas/s390/zarch-arch15.d: Tests for arch15 instructions. * testsuite/gas/s390/zarch-arch15.s: Likewise. Signed-off-by: Andreas Krebbel <krebbel@linux.ibm.com> Reviewed-by: Jens Remus <jremus@linux.ibm.com>
2024-10-10[gdb/testsuite] Fix gdb.dwarf2/enum-type-c++.exp with clangTom de Vries2-31/+78
When running test-case gdb.dwarf2/enum-type-c++.exp with clang, we get: ... FAIL: gdb.dwarf2/enum-type-c++.exp: val1 has a parent FAIL: gdb.dwarf2/enum-type-c++.exp: print ns::A::val1 FAIL: gdb.dwarf2/enum-type-c++.exp: val2 has correct parent FAIL: gdb.dwarf2/enum-type-c++.exp: print ns::ec::val2 ... The problem is that the debug info produced by clang does not contain any references to enumerators val1 and val2, or the corresponding enumeration types. Instead, the variables u1 and u2 are considered to be simply of type int: ... <1><fb>: Abbrev Number: 2 (DW_TAG_variable) <fc> DW_AT_name : u1 <fd> DW_AT_type : <0x106> <101> DW_AT_external : 1 <103> DW_AT_location : (DW_OP_addrx <0>) <1><106>: Abbrev Number: 3 (DW_TAG_base_type) <107> DW_AT_name : int <108> DW_AT_encoding : 5 (signed) <109> DW_AT_byte_size : 4 <1><10a>: Abbrev Number: 2 (DW_TAG_variable) <10b> DW_AT_name : u2 <10c> DW_AT_type : <0x106> <110> DW_AT_external : 1 <112> DW_AT_location : (DW_OP_addrx <0x1>) ... Fix this by checking whether val1 and val2 are present in the cooked index before checking whether they have the correct parent. This cannot be expressed efficiently with gdb_test_lines, so factor out gdb_get_lines and use that instead. The test-case still calls "maint print objfiles" twice, but the first time is for have_index. We should probably use a gdb_caching_proc for this. Tested on aarch64-linux. Reported-By: Guinevere Larsen <guinevere@redhat.com> Reviewed-By: Keith Seitz <keiths@redhat.com> Tested-By: Guinevere Larsen <guinevere@redhat.com>
2024-10-10[gdb/testsuite] Fix some gdb.dwarf2 test-cases for check-read1Tom de Vries5-6/+15
I ran the testsuite in an environment simulating a stressed system in combination with check-read1. This exposes a few more FAILs. Fix the gdb.dwarf2 ones by using pipe / grep to filter out unnecessary output. Tested on x86_64-linux.
2024-10-10Automatic date update in version.inGDB Administrator1-1/+1
2024-10-09[gdb/testsuite] Fix gdb.base/reggroups.exp with check-read1Tom de Vries1-7/+21
On aarch64-linux, with make target check-read1, I run into: ... (gdb) info reg vector^M ... d19 {f = 0x0, u = 0x0, s = 0x0} {f =FAIL: gdb.base/reggroups.exp: fetch reggroup regs vector (timeout) 0, u = 0, s = 0}^M ... The problem is that while (as documented) the corresponding gdb_test_multiple doesn't work for vector registers, it doesn't skip them either. This causes the timeout, and it also causes the registers after a vector register not to be found. Fix this by using -lbl style matching. Make which reggroups and registers are found more explicit using verbose -log, which makes us notice that regnames with underscores are skipped, so fix that as well. While we're at it, this: ... set invalid_register_re "Invalid register .*" ... and this: ... -re $invalid_register_re { fail "$test (unexpected invalid register response)" } ... means that the prompt may or may not be consumed. Fix this by limiting the regexp to one line, and using exp_continue. While we're at it, improve readability of the complex regexp matching a single register by factoring out regexps. Tested on aarch64-linux and x86_64-linux.
2024-10-09PR32243, NAME_MAX does not exist on mingw-w64 without _POSIX_Alan Modra1-15/+17
PR 32243 * dlltool.c: Move forward decls. Delete unnecessary ones. (bfd_errmsg): Delete macro, define as inline function. (PATHMAX): Delete. (NAME_MAX): Define.
2024-10-09Automatic date update in version.inGDB Administrator1-1/+1
2024-10-08Use ui-out tables in "maint print user-regs"Tom Tromey2-3/+13
This changes "maint print user-regs" to use ui-out tables rather than printfs. Approved-By: Andrew Burgess <aburgess@redhat.com>
2024-10-08Use ui-out tables for info proc mappingsTom Tromey3-103/+76
This changes a few implementations of "info proc mappings" to use ui-out tables rather than printf. Note that NetBSD and FreeBSD also use printfs here, but since I can't test these, I didn't update them. Approved-By: Andrew Burgess <aburgess@redhat.com>
2024-10-08[gdb/testsuite] Fix gdb.base/break-interp.exp with check-read1Tom de Vries1-17/+5
When running test-case gdb.base/break-interp.exp with check-read1, I run into: ... (gdb) info files^M ... 0x00007ffff7e75980 - 0x00007ffff7e796a0 @ 0x001f1970 is .bss in /data/vries/gdb/leap-15-5/build/gdb/testsuite/outputs/gdb.base/break-interp/break-interp-BINprelinkNOdebugNOFAIL: gdb.base/break-interp.exp: ldprelink=NO: ldsepdebug=NO: binprelink=NO: binsepdebug=NO: binpie=NO: INNER: symbol-less: info files (timeout) pieNO.d/libc.so.6^M ... The code has two adaptations to deal with the large output: - nested gdb_test_multiple, and - an exp_continue in the inner gdb_test_multiple. The former seems unnecessary, and the latter doesn't trigger often enough because of an incomplete hex number regexp, causing the timeout. Get rid of both of these, and use -lbl instead. Tested on x86_64-linux.
2024-10-08gdb: include --enable-targets in 'show configuration' outputAndrew Burgess4-2/+23
Include the value of configuration flag --enable-targets in the output of GDB command 'show configuration' and also in the output printed for 'gdb --configuration'. This will make it easier to see how GDB was built. No tests added or updated as we can't really check for a specific flag appearing or not appearing on the configuration output. But we do print the configuration within lib/gdb.exp to check which features are built into GDB, so if this change broke configuration printing then plenty of tests should stop working (they don't). Approved-By: Tom Tromey <tom@tromey.com>
2024-10-08gdb: avoid breakpoint::clear_locations calls in update_breakpoint_locationsAndrew Burgess5-29/+121
The commit: commit 6cce025114ccd0f53cc552fde12b6329596c6c65 Date: Fri Mar 3 19:03:15 2023 +0000 gdb: only insert thread-specific breakpoints in the relevant inferior added a couple of calls to breakpoint::clear_locations() inside update_breakpoint_locations(). The intention of these calls was to avoid leaving redundant locations around when a thread- or inferior-specific breakpoint was switched from one thread or inferior to another. Without the clear_locations() calls the tests gdb.multi/tids.exp and gdb.multi/pending-bp.exp have some failures. A b/p is changed such that the program space it is associated with changes. This triggers a call to breakpoint_re_set_one() but the FILTER_PSPACE argument will be the new program space. As a result GDB correctly calculates the new locations and adds these to the breakpoint, but the old locations, in the old program space, are incorrectly retained. The call to clear_locations() solves this by deleting the old locations. However, while working on another patch I realised that the approach taken here is not correct. The FILTER_PSPACE argument passed to breakpoint_re_set_one() and then on to update_breakpoint_locations() might not be the program space to which the breakpoint is associated. Consider this example: (gdb) file /tmp/hello.x Reading symbols from /tmp/hello.x... (gdb) start Temporary breakpoint 1 at 0x401198: file hello.c, line 18. Starting program: /tmp/hello.x Temporary breakpoint 1, main () at hello.c:18 18 printf ("Hello World\n"); (gdb) break main thread 1 Breakpoint 2 at 0x401198: file hello.c, line 18. (gdb) info breakpoints Num Type Disp Enb Address What 2 breakpoint keep y 0x0000000000401198 in main at hello.c:18 stop only in thread 1 (gdb) add-inferior -exec /tmp/hello.x [New inferior 2] Added inferior 2 on connection 1 (native) Reading symbols from /tmp/hello.x... (gdb) info breakpoints Num Type Disp Enb Address What 2 breakpoint keep y <PENDING> main stop only in thread 1.1 Notice that after creating the second inferior and loading a file the thread-specific breakpoint was incorrectly made pending. Loading the exec file in the second inferior triggered a call to breakpoint_re_set() with the new, second, program space as the current_program_space. This program space ends up being passed to update_breakpoint_locations(). In update_breakpoint_locations this condition is true: if (all_locations_are_pending (b, filter_pspace) && sals.empty ()) and so we end up discarding all of the locations for this breakpoint, making the breakpoint pending. What we really want to do in update_breakpoint_locations() is, for thread- or inferior- specific breakpoints, delete any locations which are associated with a program space that this breakpoint is NOT associated with. But then I realised the answer was easier than that. The ONLY time that a b/p can have locations associated with the "wrong" program space like this is at the moment we change the thread or inferior the b/p is associated with by calling breakpoint_set_thread() or breakpoint_set_inferior(). And so, I think the correct solution is to hoist the call to clear_locations() out of update_breakpoint_locations() and place a call in each of the breakpoint_set_{thread,inferior} functions. I've done this, and added a couple of new tests. All of which are now passing. Approved-By: Tom Tromey <tom@tromey.com>
2024-10-08[gdb/testsuite] Fix gdb.ada/tagged-lookup.exp with read1+readnowTom de Vries1-6/+2
When running test-case gdb.ada/tagged-lookup.exp with target board readnow and make target check-read1: ... $ ( cd build/gdb; \ make check-read1 \ RUNTESTFLAGS="--target_board=readnow gdb.ada/tagged-lookup.exp" ) ... I run into: ... (gdb) PASS: gdb.ada/tagged-lookup.exp: set debug symtab-create 1 print *the_local_var^M $1 = (n => 2)^M (gdb) FAIL: gdb.ada/tagged-lookup.exp: only one CU expanded ... The problem is that the corresponding gdb_test_multiple uses line-by-line matching (using -lbl) which doesn't work well with the multiline pattern matching both the prompt and the line before it: ... -re -wrap ".* = \\\(n => $decimal\\\)" { ... Fix this by making it a one-line pattern: ... -re -wrap "" { ... While we're at it, replace an if-then-pass-else-fail with a gdb_assert. Tested on aarch64-linux.
2024-10-08[gdb/symtab] Fix gdb.dwarf2/enum-type-c++.exp with cc-with-debug-typesTom de Vries2-3/+5
When running test-case gdb.dwarf2/enum-type-c++.exp with target board cc-with-debug-types, we run into: ... (gdb) FAIL: gdb.dwarf2/enum-type-c++.exp: val1 has a parent ... because val1 has no parent: ... [31] ((cooked_index_entry *) 0x7efedc002e90) name: val1 canonical: val1 qualified: val1 DWARF tag: DW_TAG_enumerator flags: 0x0 [] DIE offset: 0xef parent: ((cooked_index_entry *) 0) ... [37] ((cooked_index_entry *) 0x38ffd280) name: val1 canonical: val1 qualified: val1 DWARF tag: DW_TAG_enumerator flags: 0x0 [] DIE offset: 0xef parent: ((cooked_index_entry *) 0) ... There are two entries, which seems to be an inefficiency, but for now let's focus on the correctness issue. The debug info for val1 looks like this: ... <1><cb>: Abbrev Number: 2 (DW_TAG_namespace) <cc> DW_AT_name : ns <cf> DW_AT_declaration : 1 <2><d3>: Abbrev Number: 12 (DW_TAG_class_type) <d4> DW_AT_name : A <d6> DW_AT_declaration : 1 <3><d6>: Abbrev Number: 13 (DW_TAG_enumeration_type) <db> DW_AT_declaration : 1 <1><dd>: Abbrev Number: 14 (DW_TAG_enumeration_type) <e7> DW_AT_specification: <0xd6> <2><ef>: Abbrev Number: 5 (DW_TAG_enumerator) <f0> DW_AT_name : val1 <f4> DW_AT_const_value : 1 ... Fix this by: - adding a cooked index entry for DIE 0xcb (and consequently for child DIE 0xd3), by marking it interesting, - making sure that the entry for DIE 0xcb has a name, and - using the entry for DIE 0xd3 as parent entry for DIE 0xdd. Tested on aarch64-linux. Approved-By: Tom Tromey <tom@tromey.com>
2024-10-08[gdb/symtab] Fix parent of enumeratorTom de Vries2-10/+52
As mentioned in commit 489b82720f5 ('[gdb/symtab] Revert "Change handling of DW_TAG_enumeration_type in DWARF scanner"'), when doing "maint print objfiles" in test-case gdb.dwarf2/enum-type.exp, for val1 we get an entry without parent: ... [27] ((cooked_index_entry *) 0x7fbbb4002ef0) name: val1 canonical: val1 qualified: val1 DWARF tag: DW_TAG_enumerator flags: 0x0 [] DIE offset: 0x124 parent: ((cooked_index_entry *) 0) ... This happens here in cooked_indexer::index_dies: ... info_ptr = recurse (reader, info_ptr, is_enum_class ? this_entry : parent_entry, fully); ... when we're passing down a nullptr parent_entry, while the parent of this_entry is deferred. Fix this in cooked_indexer::index_dies by passing down a deffered parent instead, such that we get: ... [27] ((cooked_index_entry *) 0x7ff0e4002ef0)^M name: val1^M canonical: val1^M qualified: ns::val1^M DWARF tag: DW_TAG_enumerator^M flags: 0x0 []^M DIE offset: 0x124^M parent: ((cooked_index_entry *) 0x7ff0e4002f20) [ns]^M ... Tested on x86_64-linux. Approved-By: Tom Tromey <tom@tromey.com>
2024-10-08[gdb/contrib] Fix "sofar->so far" misspellingTom de Vries3-2/+3
I forgot to follow up on a review comment and fix the "sofar->so far" misspelling [1]. Fix this by adding it to gdb/contrib/common-misspellings.txt. Tested on x86_64-linux. [1] https://sourceware.org/pipermail/gdb-patches/2024-September/211894.html
2024-10-08[gdb/contrib] Add more separators in spellcheck.shTom de Vries8-9/+53
Add two more separators in spellcheck.sh: colon and comma. Doing so triggers the "inbetween->between" rule, which gives an incorrect result. Override this with "inbetween->between, in between, in-between" [1], in a new file gdb/contrib/common-misspellings.txt. Fix the following common misspellings: ... everytime -> every time sucess -> success thru -> through transfered -> transferred inbetween -> between, in between, in-between ... Verified with spellcheck.sh. Tested on x86_64-linux. [1] https://www.grammarly.com/blog/commonly-confused-words/in-between-or-inbetween/
2024-10-08[gdb/contrib] Factor out grep_or and sed_or in spellcheck.shTom de Vries1-2/+41
While trying to add more separators here: ... # Separators: space, slash, tab. grep_separator=" |/| " sed_separator=" \|/\|\t" ... I mistakingly used "|" instead of "\|" in sed_separator. Factor out new variables grep_or and sed_or, and construct the grep_separator and sed_separator variables by joining the elements of a list using grep_or and sed_or. Verified with shellcheck, and tested by rerunning on x86_64-linux. Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
2024-10-08Revised "Don't return (null) from bfd_elf_sym_name"Alan Modra12-58/+97
Commit 68bbe1183379 results in a lot of follow up work, much of which likely is still to be done. (And yes, since this is all for corrupted or fuzzed object files, a whole lot of work doesn't much benefit anyone. It was a bad idea to put NULL in asymbol->name.) So I'm changing the approach to instead put a unique empty string for symbols with a corrupted st_name. An empty string won't require much work to ensure nm, objcopy, objdump etc. won't crash, since these tools already must work with unnamed local symbols. The unique empty string is called bfd_symbol_error_name. This patch uses that name string for corrupted symbols in the ELF and COFF backends. Such symbols are displayed by nm and objdump as the translated string "<corrupt>", which is what the COFF backend used to put directly into corrupted symbols. ie. it's the way I should have written the original patch, plus a few tides and cleanups I retained from the reverted patches.
2024-10-08Revert "Don't return "(null)" from bfd_elf_sym_name"Alan Modra6-24/+24
This reverts commit 68bbe118337939aa0b52e007a7415c8a157579a1.
2024-10-08Revert "bfd_elf_sym_name_raw"Alan Modra4-21/+10
This reverts commit 265757dc6e4d011a1b33ef1b3bfcd7f100f12f64.
2024-10-08Revert "get_synthetic_symtab fixes for commit 68bbe1183379"Alan Modra6-158/+132
This reverts commit 0c13ac533e59589793ee6c8045cff98663f3ea85.
2024-10-08Revert "is_target_special_symbol fixes for commit 68bbe1183379"Alan Modra3-13/+3
This reverts commit 6e40f9bb31be2f3656df97a1fcba4d6a30081e24.
2024-10-08Revert "dlltool fixes for commit 68bbe1183379"Alan Modra1-5/+4
This reverts commit 06116013f80e474800cfb122924bc2a6f060606a.