aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2023-10-10gdb: add remote_state::{is_async_p,can_async_p}Simon Marchi1-4/+16
A subsequent patch will want to know if the remote is async within a remote_state method. Add a helper method for that, and for "can async" as well, for symmetry. Change-Id: Id0f648ee4896736479fa942f5453eeeb0e5d4352 Approved-By: Andrew Burgess <aburgess@redhat.com>
2023-10-10gdb: make remote_state's async token privateSimon Marchi1-27/+44
Make remote_async_inferior_event_token private (rename to m_async_event_handler_token) and add methods for the various operations we do on it. This will help by: - allowing to break on those methods when debugging - allowing to add assertions in the methods Change-Id: Ia3b8a2bc48ad4849dbbe83442c3f83920f03334d Approved-By: Andrew Burgess <aburgess@redhat.com>
2023-10-10gdb: remove trailing whitespaces in remote.cSimon Marchi1-10/+9
Change-Id: I88d136b6b5a0a54d1c8a9f8a0068762a5456a29a
2023-10-10gdb: scope down registers_changed call in inferior::set_archSimon Marchi1-1/+4
inferior::set_arch calls registers_changed, which invalidates all regcaches. It would be enough to invalidate only regcaches of threads belonging to this inferior. Call registers_changed_ptid instead, with the proper process target / ptid. If the inferior does not have a process target, there should be no regcaches for that inferior, so no need to invalidate anything. Change-Id: Id8b5500acb7f373b01a534f16d3a7d028dc0d882 Reviewed-By: John Baldwin <jhb@FreeBSD.org> Approved-By: Andrew Burgess <aburgess@redhat.com>
2023-10-10gdb: remove target_gdbarchSimon Marchi93-504/+579
This function is just a wrapper around the current inferior's gdbarch. I find that having that wrapper just obscures where the arch is coming from, and that it's often used as "I don't know which arch to use so I'll use this magical target_gdbarch function that gets me an arch" when the arch should in fact come from something in the context (a thread, objfile, symbol, etc). I think that removing it and inlining `current_inferior ()->arch ()` everywhere will make it a bit clearer where that arch comes from and will trigger people into reflecting whether this is the right place to get the arch or not. Change-Id: I79f14b4e4934c88f91ca3a3155f5fc3ea2fadf6b Reviewed-By: John Baldwin <jhb@FreeBSD.org> Approved-By: Andrew Burgess <aburgess@redhat.com>
2023-10-10gdb: move set_target_gdbarch to inferior::set_archSimon Marchi4-20/+22
set_target_gdbarch is basically a setter for the current inferior's arch, that notifies other parts of GDB of the architecture change. Move the code of set_target_gdbarch to the inferior::set_arch method. Add gdbarch_initialized_p, so we can keep the assertion. Change-Id: I276e28eafd4740c94bc5233c81a86c01b4a6ae90 Reviewed-By: John Baldwin <jhb@FreeBSD.org> Approved-By: Andrew Burgess <aburgess@redhat.com>
2023-10-10gdb: add inferior parameter to architecture_changed observableSimon Marchi3-4/+6
This is to make it explicit which inferior's architecture just changed, and that the callbacks should not assume it is the current inferior. Update the only caller, pyuw_on_new_gdbarch, to add the parameter, although it doesn't use it currently. Change-Id: Ieb7f21377e4252cc6e7b1ce2cc812cd1a1840e0e Reviewed-By: John Baldwin <jhb@FreeBSD.org> Approved-By: Andrew Burgess <aburgess@redhat.com>
2023-10-10gdb: add inferior::{arch, set_arch}Simon Marchi25-55/+63
Make the inferior's gdbarch field private, and add getters and setters. This helped me by allowing putting breakpoints on set_arch to know when the inferior's arch was set. A subsequent patch in this series also adds more things in set_arch. Change-Id: I0005bd1ef4cd6b612af501201cec44e457998eec Reviewed-By: John Baldwin <jhb@FreeBSD.org> Approved-By: Andrew Burgess <aburgess@redhat.com>
2023-10-10asan: buffer overflow in elf32_arm_get_synthetic_symtabAlan Modra1-8/+16
Guard against fuzzed files where .plt size isn't commensurate with plt relocations. * elf32-arm.c (elf32_arm_plt0_size): Add data_size param. Return -1 if data_size is too small. (elf32_arm_plt_size): Likewise. Delete temp var. Formatting. (elf32_arm_get_synthetic_symtab): Adjust to suit.
2023-10-10asan: null dereference in read_and_display_attr_valueAlan Modra1-16/+9
This fixes multiple places in read_and_display_attr_value dealing with range and location lists that can segfault when debug_info_p is NULL. Fuzzed object files can contain arbitrary DW_FORMs. * dwarf.c (read_and_display_attr_value): Don't dereference NULL debug_info_p.
2023-10-10asan: invalid free in bfd_init_section_compress_statusAlan Modra1-8/+8
With specially crafted compressed sections, it's possible to tickle a problem when decompressing: If the compression headers says the uncompressed size is zero, this will be seen as an error return from bfd_compress_section_contents. On errors the caller should free any malloc'd input buffers, but this isn't really an error and the section contents have been updated to a bfd_alloc'd buffer which can't be freed. * compress.c (bfd_compress_section_contents): Return -1 as error rather than 0. (bfd_init_section_compress_status, bfd_compress_section): Adjust.
2023-10-10gdb/python: implement support for sending custom MI async notificationsJan Vrany6-0/+204
This commit adds a new Python function, gdb.notify_mi, that can be used to emit custom async notification to MI channel. This can be used, among other things, to implement notifications about events MI does not support, such as remote connection closed or register change. Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Andrew Burgess <aburgess@redhat.com>
2023-10-10gdb/python: generalize serialize_mi_result()Jan Vrany3-176/+181
This commit generalizes serialize_mi_result() to make usable in different contexts than printing result of custom MI command. To do so, the check whether passed Python object is a dictionary has been moved to the caller - at the very least, different uses require different error messages. Also it has been renamed to serialize_mi_results() to better match GDB/MI output syntax (see corresponding section in documentation, in particular rules 'result-record' and 'async-output'. Since it is now more generic function, it has been moved to py-mi.c. This is a preparation for implementing Python support for sending custom MI async events. Approved-By: Andrew Burgess <aburgess@redhat.com>
2023-10-10LoongArch/GAS: Add support for branch relaxationmengqinggang6-41/+367
For the instructions of R_LARCH_B16/B21, if the immediate overflow, add a B instruction and R_LARCH_B26 relocation. For example: .L1 ... blt $t0, $t1, .L1 R_LARCH_B16 change to: .L1 ... bge $t0, $t1, .L2 b .L1 R_LARCH_B26 .L2
2023-10-10[readelf] Handle .gdb_index section version 9Tom de Vries2-63/+119
Add the abilitity to print a v9 .gdb_index section. The v9 section contains an extra table, which is printed as follows: ... Shortcut table: Language of main: Fortran 95 Name of main: contains_keyword ... [ For the example, I used the exec of gdb test-case gdb.fortran/nested-funcs-2-exp when running the test-case with target board cc-with-gdb-index. ] Tested on x86_64-linux. Approved-By: Nick Clifton <nickc@redhat.com>
2023-10-10[gdb/symtab] Add name_of_main and language_of_main to the DWARF indexMatheus Branco Borella6-13/+146
This patch adds a new section to the DWARF index containing the name and the language of the main function symbol, gathered from `cooked_index::get_main`, if available. Currently, for lack of a better name, this section is called the "shortcut table". The way this name is both saved and applied upon an index being loaded in mirrors how it is done in `cooked_index_functions`, more specifically, the full name of the main function symbol is saved and `set_objfile_main_name` is used to apply it after it is loaded. The main use case for this patch is in improving startup times when dealing with large binaries. Currently, when an index is used, GDB has to expand symtabs until it finds out what the language of the main function symbol is. For some large executables, this may take a considerable amount of time to complete, slowing down startup. This patch bypasses that operation by having both the name and language of the main function symbol be provided ahead of time by the index. In my testing (a binary with about 1.8GB worth of DWARF data) this change brings startup time down from about 34 seconds to about 1.5 seconds. When testing the patch with target board cc-with-gdb-index, test-case gdb.fortran/nested-funcs-2.exp starts failing, but this is due to a pre-existing issue, filed as PR symtab/30946. Tested on x86_64-linux, with target board unix and cc-with-gdb-index. PR symtab/24549 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=24549 Approved-By: Tom de Vries <tdevries@suse.de>
2023-10-10Automatic date update in version.inGDB Administrator1-1/+1
2023-10-09gdb_unique_ptr.h: Fix a typo in a commentJohn Baldwin1-1/+1
2023-10-09Fix: Null pointer dereference in ldlex.lNick Clifton2-1/+4
PR 30951 * ldlex.l (yy_input): Check for YY_CURRENT_BUFFER being NULL.
2023-10-09Fix: A potential null_pointer_deference bugNick Clifton2-0/+9
PR 30954 * ldlang.c (map_input_to_output_sections): Check that os is non NULL before using it.
2023-10-09Fix: Null pointer dereference in elf32-i386.cNick Clifton2-0/+10
PR 30950 * elf32-i386.c (elf_i386_convert_load_reloc): Check for elf_x86_hash_table returning a NULL pointer.
2023-10-09Fix: A potential bug of null pointer dereferenceNick Clifton2-1/+7
PR 30949 * elflink.c (elf_gc_mark_debug_section): Check for bfd_section_from_elf_index returning a NULL pointer.
2023-10-09gdb/testsuite: match complete lines in gdb.base/maint.expAndrew Burgess1-2/+2
This thread: https://inbox.sourceware.org/gdb-patches/20231003195338.334948-1-thiago.bauermann@linaro.org/ pointed out that within gdb.base/maint.exp, some regexps within a gdb_test_multiple were failing to match a complete line, while later regexps within the gdb_test_multiple made use of the '^' anchor, and so assumed that earlier lines had been completely matched and removed from expect's buffer. When testing with READ1 set this assumption was failing. Fix this by extending the offending patterns with a trailing '\r\n'. Tested-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
2023-10-09Automatic date update in version.inGDB Administrator1-1/+1
2023-10-08Update gdb/NEWS after GDB 14 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.
2023-10-08Bump version to 15.0.50.DATE-git.Joel Brobecker2-2/+2
Now that the GDB 14 branch has been created, this commit bumps the version number in gdb/version.in to 15.0.50.DATE-git For the record, the GDB 14 branch was created from commit 8f12a1a841cd0c447de7a5a0f134a0efece73588. Also, as a result of the version bump, the following changes have been made in gdb/testsuite: * gdb.base/default.exp: Change $_gdb_major to 15.
2023-10-08Add testsuits for new assembler option of mthin-add-sub.gdb-14-branchpointcailulu6-24/+131
2023-10-08as: add option for generate R_LARCH_32/64_PCREL.cailulu3-6/+37
Some older kernels cannot handle the newly generated R_LARCH_32/64_PCREL, so the assembler generates R_LARCH_ADD32/64+R_LARCH_SUB32/64 by default, and use the assembler option mthin-add-sub to generate R_LARCH_32/64_PCREL as much as possible. The Option of mthin-add-sub does not affect the generation of R_LARCH_32_PCREL relocation in .eh_frame.
2023-10-08Automatic date update in version.inGDB Administrator1-1/+1
2023-10-07Revert "opcodes: microblaze: Add new bit-field instructions"Michael J. Eager10-196/+5
This reverts commit 6bbf249557ba17cfebe01c67370df4da9e6a56f9. Maciej W. Rozycki <macro@orcam.me.uk>: Yet it has caused numerous regressions: microblaze-elf +FAIL: unordered .debug_info references to .debug_ranges microblaze-elf +FAIL: binutils-all/pr26548 microblaze-elf +FAIL: readelf -Wwi pr26548e (reason: unexpected output) microblaze-elf +FAIL: readelf --debug-dump=loc locview-1 (reason: unexpected output) Yet it has caused numerous regressions: microblaze-elf +FAIL: unordered .debug_info references to .debug_ranges microblaze-elf +FAIL: binutils-all/pr26548 microblaze-elf +FAIL: readelf -Wwi pr26548e (reason: unexpected output) ...
2023-10-07[gdb/testsuite] Fix gdb.arch/i386-signal.exp on x86_64Tom de Vries2-1/+10
On x86_64-linux, with test-case gdb.arch/i386-signal.exp I run into: ... builtin_spawn -ignore SIGHUP gcc -fno-stack-protector i386-signal.c \ -fdiagnostics-color=never -fno-pie -g -no-pie -lm -o i386-signal^M /tmp/cc2xydTG.s: Assembler messages:^M /tmp/cc2xydTG.s:50: Error: operand size mismatch for `push'^M compiler exited with status 1 output is: /tmp/cc2xydTG.s: Assembler messages:^M /tmp/cc2xydTG.s:50: Error: operand size mismatch for `push'^M gdb compile failed, /tmp/cc2xydTG.s: Assembler messages: /tmp/cc2xydTG.s:50: Error: operand size mismatch for `push' UNTESTED: gdb.arch/i386-signal.exp: failed to compile ... This is with gas 2.41, it compiles without problems with gas 2.40. Some more strict checking was added in commit 5cc007751cd ("x86: further adjust extend-to-32bit-address conditions"). This may or may not be a gas regression ( https://sourceware.org/pipermail/binutils/2023-October/129818.html ). The offending bit is: ... " push $sigframe\n" ... which refers to a function: ... " .globl sigframe\n" "sigframe:\n" ... The test-case passes with target board unix/-m32. Make the test-case work by using pushq instead of push for the is_amd64_regs_target case. Tested on x86_64-linux, with target boards: - unix/-m64 (is_amd64_regs_target == 1), and - unix/-m32 (is_amd64_regs_target == 0), PR testsuite/30928 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30928
2023-10-06gdb: support rseq auxvsIlya Leoshkevich2-0/+6
Linux kernel commit commit 317c8194e6ae ("rseq: Introduce feature size and alignment ELF auxiliary vector entries") introduced two new auxvs: AT_RSEQ_FEATURE_SIZE and AT_RSEQ_ALIGN. Support them in GDB. This fixes auxv.exp on kernels >= v6.3. Change-Id: I8966c4d5c73eb7b45de6d410a9b28a6628edad2e Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30540 Approved-By: Tom Tromey <tom@tromey.com>
2023-10-06gprofng: 30910 cross test fail: can't read "CHECK_TARGET": no such variableVladimir Mezentsev2-23/+12
When TCL_TRY is FALSE, the wrong check-DEJAGNU is generated. Place "if TCL_TRY / endif" in the right place. gprofng/ChangeLog 2023-10-05 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> PR gprofng/30910 * Makefile.am: Correct "if TCL_TRY / endif". * Makefile.in: Rebuild.
2023-10-07Automatic date update in version.inGDB Administrator1-1/+1
2023-10-06process-dies-while-detaching.exp: Exit early if GDB misses sync breakpointThiago Jung Bauermann2-7/+7
I'm seeing a lot of variability in the failures of gdb.threads/process-dies-while-detaching.exp on aarch64-linux. On this platform, a problem yet to be investigated causes GDB to miss the _exit breakpoint. What happens next is random because after missing that breakpoint, GDB is out of sync with the inferior. This causes the tests following that point in the testcase to fail in a random way. In this scenario it's better to exit the testcase early to avoid random results in the testsuite. We are relying on gdb_continue_to_breakpoint to return the result of gdb_test_multiple. This is already the case because in Tcl the return value of a function is the return value of the last command it runs. But change gdb_continue_to_breakpoint to explicitly return this value, to make it clear this is the intended behaviour. Tested on aarch64-linux. Tested-By: Guinevere Larsen <blarsen@redhat.com> Approved-By: Andrew Burgess <aburgess@redhat.com>
2023-10-06opcodes: microblaze: Add new bit-field instructionsNeal Frager10-5/+196
This patches adds new bsefi and bsifi instructions. BSEFI- The instruction shall extract a bit field from a register and place it right-adjusted in the destination register. The other bits in the destination register shall be set to zero. BSIFI- The instruction shall insert a right-adjusted bit field from a register at another position in the destination register. The rest of the bits in the destination register shall be unchanged. Further documentation of these instructions can be found here: https://docs.xilinx.com/v/u/en-US/ug984-vivado-microblaze-ref This patch has been tested for years of AMD Xilinx Yocto releases as part of the following patch set: https://github.com/Xilinx/meta-xilinx/tree/master/meta-microblaze/recipes-devtools/binutils/binutils Signed-off-by: nagaraju <nagaraju.mekala@amd.com> Signed-off-by: Ibai Erkiaga <ibai.erkiaga-elorza@amd.com> Signed-off-by: Neal Frager <neal.frager@amd.com> Signed-off-by: Michael J. Eager <eager@eagercon.com>
2023-10-06gdb/NEWS: reorder some entries in the NEWS fileAndrew Burgess1-12/+12
I spotted two entries in the NEWS file that I believe are in the wrong place, these are: - An entry about MI v1 being deprecated, this feels like it should be the first entry under the 'MI changes' heading, and - An entry for the $_shell convenience function which is currently under the 'New commands' heading (sort of), when I think this should be listed in the general news section.
2023-10-06gdbserver: fix gdbserver builds after expedite_regs changesAndrew Burgess3-6/+16
After this commit: commit 6a65998a8a94abaaae7ca4ff0ab9c3f25dc2e766 Date: Mon Sep 11 12:42:00 2023 +0100 Convert tdesc's expedite_regs to a string vector The risc-v, loongarch, and csky gdbserver builds were broken. A use of target_desc::expedite_regs (for each architecture) was not updated to take account of the type change. I've tested that this fixes the risc-v build. I haven't tested the other architectures, but they should be fine.
2023-10-06gdb/testsuite: cleanup in gdb.base/args.expAndrew Burgess1-52/+36
The last few commits resolved the KFAILs in gdb.base/args.exp. With those out of the way we can clean up this test script a little. In this commit I have: - Stopped passing 'nowarnings' flag when building the source file. I see no reason why this source should issue a warning, - Moved setup of GDBFLAGS into args_test proc, callers that passed a newline needed a small tweak, and also the matching code needs updating for newline handling, but I think this is nicer, the argument lists are now given just once, - Updated comment on args_test, - Updated other comments. There should be no change in what is tested after this commit. Approved-By: Tom Tromey <tom@tromey.com>
2023-10-06gdbserver: cleanup in handle_v_runAndrew Burgess1-19/+5
After the previous commit there is now a redundant string copy in handle_v_run, this commit cleans that up. There should be no functional change after this commit. During review I was pointed to this older series: https://inbox.sourceware.org/gdb-patches/20211022071933.3478427-1-m.weghorn@posteo.de/ which also includes this fix as part of a larger set of changes. I'm giving a Co-Authored-By credit to the author of that original series. I believe this smaller fix brings some benefits on its own, though the original series does offer additional improvements. Once this is merged I'll take a look at rebasing and resubmitting the original series. Co-Authored-By: Michael Weghorn <m.weghorn@posteo.de> Approved-By: Tom Tromey <tom@tromey.com>
2023-10-06gdbserver: handle newlines in inferior argumentsAndrew Burgess2-32/+5
Similarly to how single quotes were mishandled, which was fixed two commits ago, this commit fixes handling of newlines in arguments passed to gdbserver. We already had a test that covered this, gdb.base/args.exp, which, when run with the native-extended-gdbserver board contained several KFAIL covering this situation. In this commit I remove the unnecessary, attempt to quote incoming newlines within arguments, and do some minimal cleanup of the related code. There is additional cleanup that can be done, but I'm leaving that for the next commit. Then I've removed the KFAIL from the test case, and performed some minimal cleanup there too. After this commit the gdb.base/args.exp is 100% passing with the native-extended-gdbserver board file. During review I was pointed to this older series: https://inbox.sourceware.org/gdb-patches/20211022071933.3478427-1-m.weghorn@posteo.de/ which also includes this fix as part of a larger set of changes. I'm giving a Co-Authored-By credit to the author of that original series. I believe this smaller fix brings some benefits on its own, though the original series does offer additional improvements. Once this is merged I'll take a look at rebasing and resubmitting the original series. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27989 Co-Authored-By: Michael Weghorn <m.weghorn@posteo.de> Approved-By: Tom Tromey <tom@tromey.com>
2023-10-06gdbserver: fix handling of trailing empty argumentAndrew Burgess2-6/+11
When I posted the previous patch for review Andreas Schwab pointed out that passing a trailing empty argument also doesn't work. The fix for this is in the same area of code as the previous patch, but is sufficiently different that I felt it deserved a patch of its own. I noticed that passing arguments containing single quotes to gdbserver didn't work correctly: gdb -ex 'set sysroot' --args /tmp/show-args Reading symbols from /tmp/show-args... (gdb) target extended-remote | gdbserver --once --multi - /tmp/show-args Remote debugging using | gdbserver --once --multi - /tmp/show-args stdin/stdout redirected Process /tmp/show-args created; pid = 176054 Remote debugging using stdio Reading symbols from /lib64/ld-linux-x86-64.so.2... (No debugging symbols found in /lib64/ld-linux-x86-64.so.2) 0x00007ffff7fd3110 in _start () from /lib64/ld-linux-x86-64.so.2 (gdb) set args abc "" (gdb) run The program being debugged has been started already. Start it from the beginning? (y or n) y Starting program: /tmp/show-args \' stdin/stdout redirected Process /tmp/show-args created; pid = 176088 2 args are: /tmp/show-args abc Done. [Inferior 1 (process 176088) exited normally] (gdb) target native Done. Use the "run" command to start a process. (gdb) run Starting program: /tmp/show-args \' 2 args are: /tmp/show-args abc Done. [Inferior 1 (process 176095) exited normally] (gdb) q The 'shows-args' program used here just prints the arguments passed to the inferior. Notice that when starting the inferior using the extended-remote target there is only a single argument 'abc', while when using the native target there is a second argument, the blank line, representing the empty argument. The problem here is that the vRun packet coming from GDB looks like this (I've removing the trailing checksum): $vRun;PROGRAM_NAME;616263; If we compare this to a packet with only a single argument and no trailing empty argument: $vRun;PROGRAM_NAME;616263 Notice the lack of the trailing ';' character here. The problem is that gdbserver processes this string in a loop. At each point we maintain a pointer to the character just after a ';', and then we process everything up to either the next ';' character, or to the end of the string. We break out of this loop when the character we start with (in that loop iteration) is the null-character. This means in the trailing empty argument case, we abort the loop before doing anything with the empty argument. In this commit I've updated the loop, we now break out using a 'break' statement at the end of the loop if the (sub-)string we just processed was empty, with this change we now notice the trailing empty argument. I've updated the test case to cover this issue. Approved-By: Tom Tromey <tom@tromey.com>
2023-10-06gdbserver: fix handling of single quote argumentsAndrew Burgess3-10/+7
I noticed that passing arguments containing single quotes to gdbserver didn't work correctly: gdb -ex 'set sysroot' --args /tmp/show-args Reading symbols from /tmp/show-args... (gdb) target extended-remote | gdbserver --once --multi - /tmp/show-args Remote debugging using | gdbserver --once --multi - /tmp/show-args stdin/stdout redirected Process /tmp/show-args created; pid = 176054 Remote debugging using stdio Reading symbols from /lib64/ld-linux-x86-64.so.2... (No debugging symbols found in /lib64/ld-linux-x86-64.so.2) 0x00007ffff7fd3110 in _start () from /lib64/ld-linux-x86-64.so.2 (gdb) set args \' (gdb) r The program being debugged has been started already. Start it from the beginning? (y or n) y Starting program: /tmp/show-args \' stdin/stdout redirected Process /tmp/show-args created; pid = 176088 2 args are: /tmp/show-args \' Done. [Inferior 1 (process 176088) exited normally] (gdb) target native Done. Use the "run" command to start a process. (gdb) run Starting program: /tmp/show-args \' 2 args are: /tmp/show-args ' Done. [Inferior 1 (process 176095) exited normally] (gdb) q The 'shows-args' program used here just prints the arguments passed to the inferior. Notice that when starting the inferior using the extended-remote target the second argument is "\'", while when running using native target the argument is "'". The second of these is correct, the \' used with the "set args" command is just to show GDB that the single quote is not opening an argument string. It turns out that the extra backslash is injected on the gdbserver side when gdbserver processes the arguments that GDB passes it, the code that does this was added as part of this much larger commit: commit 2090129c36c7e582943b7d300968d19b46160d84 Date: Thu Dec 22 21:11:11 2016 -0500 Share fork_inferior et al with gdbserver In this commit I propose removing the specific code that adds what I believe is a stray backslash. I've extended an existing test to cover this case, and I now see identical behaviour when using an extended-remote target as with the native target. This partially fixes PR gdb/27989, though there are still some issues with newline handling which I'll address in a later commit. During review I was pointed to this older series: https://inbox.sourceware.org/gdb-patches/20211022071933.3478427-1-m.weghorn@posteo.de/ which also includes this fix as part of a larger set of changes. I'm giving a Co-Authored-By credit to the author of that original series. I believe this smaller fix brings some benefits on its own, though the original series does offer additional improvements. Once this is merged I'll take a look at rebasing and resubmitting the original series. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27989 Co-Authored-By: Michael Weghorn <m.weghorn@posteo.de> Approved-By: Tom Tromey <tom@tromey.com>
2023-10-06Fix: alpha: ld segfaults inNick Clifton2-2/+7
PR 30940 * elf64-alpha.c (elf64_alpha_check_relocs): Correct error message.
2023-10-05gdb/configure.ac: Add option --with-additional-debug-dirsThiago Jung Bauermann7-4/+51
If you want to install GDB in a custom prefix, have it look for debug info in that prefix but also in the distro's default location (typically, /usr/lib/debug) and run the GDB testsuite before doing "make install", you have a bit of a problem: Configuring GDB with '--prefix=$PREFIX' sets the GDB 'debug-file-directory' parameter to $PREFIX/lib/debug. Unfortunately this precludes GDB from looking for distro-installed debug info in /usr/lib/debug. For regular GDB use you could set debug-file-directory to $PREFIX:/usr/lib/debug in $PREFIX/etc/gdbinit so that GDB will look in both places, but if you want to run the testsuite then that doesn't help because in that case GDB runs with the '-nx' option. There's the configure option '--with-separate-debug-dir' to set the default value for 'debug-file-directory', but it accepts only one directory and not a list. I considered modifying it to accept a list, but it's not obvious how to do that because its value is also used by BFD, as well as processed for "relocatability". I thought it was simpler to add a new option to specify a list of additional directories that will be appended to the debug-file-directory setting. Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Tom Tromey <tom@tromey.com>
2023-10-06Automatic date update in version.inGDB Administrator1-1/+1
2023-10-05[gdb/go] Handle v3 go_0 mangled prefixTom de Vries1-3/+27
With gcc-10 we have: ... (gdb) break package2.Foo^M Breakpoint 2 at 0x402563: file package2.go, line 5.^M (gdb) PASS: gdb.go/package.exp: setting breakpoint 1 ... but with gcc-11: ... gdb) break package2.Foo^M Function "package2.Foo" not defined.^M Make breakpoint pending on future shared library load? (y or [n]) n^M (gdb) FAIL: gdb.go/package.exp: gdb_breakpoint: set breakpoint at package2.Foo ... In the gcc-10 case, though the exec contains dwarf, it's not used to set the breakpoint (which is an independent problem, filed as PR go/30941), instead the minimal symbol information is used. The minimal symbol information changed between gcc-10 and gcc-11: ... $ nm a.out.10 | grep Foo 000000000040370d T go.package2.Foo 0000000000404e50 R go.package2.Foo..f $ nm a.out.11 | grep Foo 0000000000403857 T go_0package2.Foo 0000000000405030 R go_0package2.Foo..f ... A new v3 mangling scheme was used. The mangling schemes define a separator character and mangling character: - for v2, dot is used both as separator character and mangling character, and - for v3, dot is used as separator character and underscore as mangling character. For more details, see [1] and [2]. In v3, "_0" demangles to ".". [ See gcc commit a01dda3c23b ("compiler, libgo: change mangling scheme"), function Special_char_code::Special_char_code. ] Handle the new go_0 prefix in unpack_mangled_go_symbol, which fixes the test-case. Note that this doesn't fix this regression: ... $ gccgo-10 package2.go -c -g0 $ gccgo-10 package1.go package2.o -g0 $ gdb -q -batch a.out -ex "break go.package2.Foo" Breakpoint 1 at 0x40370d $ gccgo-11 package2.go -c -g0 $ gccgo-11 package1.go package2.o -g0 $ gdb -q -batch a.out -ex "break go.package2.Foo" Function "go.package2.Foo" not defined. ... With gcc-10, we set a breakpoint on the mangled minimal symbol. That one has simply changed for gcc-11, so it's equivalent to using: ... $ gdb -q -batch a.out -ex "break go_0package2.Foo" Breakpoint 1 at 0x403857 ... which does work. Tested on x86_64-linux: - openSUSE Leap 15.4, using gccgo-7, - openSUSE Tumbleweed, using gccgo-13. PR go/27238 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27238 [1] https://go-review.googlesource.com/c/gofrontend/+/271726 [2] https://github.com/golang/go/issues/41862#issuecomment-707244103
2023-10-05gdb: use objfile->pspace in free_objfile observersSimon Marchi2-2/+2
Use objfile->pspace instead of current_program_space. Change-Id: I127a1788e155b321563114452ed5b530f1d1f618 Approved-By: Tom Tromey <tom@tromey.com>
2023-10-05gdb: remove unnecessary nullptr check in free_objfile observersSimon Marchi3-11/+2
The free_objfile observable is never called with a nullptr objfile. Change-Id: I1e990edeb45bc38009ccb129c623911097ab65fe Approved-By: Tom Tromey <tom@tromey.com>
2023-10-05gdb: add all_objfiles_removed observerSimon Marchi16-102/+105
The new_objfile observer is currently used to indicate both when a new objfile is added to program space (when passed non-nullptr) and when all objfiles of a program space were just removed (when passed nullptr). I think this is confusing (and Andrew apparently thinks so too [1]). Add a new "all_objfiles_removed" observer to remove the second role from "new_objfile". Some existing users of new_objfile do nothing if the passed objfile is nullptr. For them, we can simply drop the nullptr check. For others, add a new all_objfiles_removed callback, and refactor things a bit to keep the existing behavior as much as possible. Some callbacks relied on current_program_space, and following the refactoring now use either objfile->pspace or the pspace passed to all_objfiles_removed. I think this should be relatively safe, and in general a step in the right direction. On the notify side, I found only one call site to change from new_objfile to all_objfiles_removed, in clear_symtab_users. It is not entirely clear to me that this is entirely correct. clear_symtab_users appears to be called in spots that don't remove all objfiles (functions finish_new_objfile, remove_symbol_file_command, reread_symbols, do_module_cleanups). But I think that this patch at least makes the current code clearer. [1] https://gitlab.com/gnutools/binutils-gdb/-/commit/a0a031bce0527b1521788b5dad640e7883b3a252 Change-Id: Icb648f72862e056267f30f44dd439bd4ec766f13 Approved-By: Tom Tromey <tom@tromey.com>
generated by cgit v1.1 at 2024-11-14 00:08:58 +0000