aboutsummaryrefslogtreecommitdiff
path: root/gdb
AgeCommit message (Collapse)AuthorFilesLines
2024-11-01Fix compile error due to [[noreturn]] with clangAndrew Oates1-1/+2
Since commit d9deb60b2e9e94b532f43a7d3ddddf5ddf6dbdd3, I get the following compiler error when building binutils (cross-compiling) on macos: CXX remote-sim.o ../../gdb/remote-sim.c:334:28: error: assigning to 'void (*)(host_callback *, const char *, ...) __attribute__((noreturn))' (aka 'void (*)(host_callback_struct *, const char *, ...) __attribute__((noreturn))') from incompatible type 'void (host_callback *, const char *, ...)' (aka 'void (host_callback_struct *, const char *, ...)') gdb_callback.error = gdb_os_error; ^~~~~~~~~~~~ 1 error generated. This appears to be due to the mismatch between ATTRIBUTE_NORETURN and [[noreturn]] on gdb_os_error. Reverting the change for gdb_os_error resolves the issue. Removing ATTTRIBUTE_NORETURN on the declaration of host_callback::error also works, but deprives the compiler of data. Tested by compiling on macos both with the system clang, as well as with GCC 14. With clang, remote-sim.c does not compile (per above) without this patch. With GCC, it compiles with and without the patch (it doesn't link, but AFAICT that is unrelated). The clang bug is reported upstream at https://github.com/llvm/llvm-project/issues/113511 Approved-By: Tom Tromey <tom@tromey.com>
2024-11-01Add gdb.events.tui_enabledTom Tromey10-0/+73
This adds a new event source so that Python scripts can track whether or not the TUI is presently enabled. v2 of the patch renames "status" -> "enabled". Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32162 Reviewed-By: Eli Zaretskii <eliz@gnu.org> Reviewed-by: Keith Seitz <keiths@redhat.com>
2024-10-31Prevent use-after-free of bfd filename in gdb_bfd_close_or_warnDomani Johannes1-2/+3
On Windows gcore is not implemented, and if you try it, you get an heap-use-after-free error: (gdb) gcore C:/gdb/build64/gdb-git-python3/gdb/testsuite/outputs/gdb.base/gcore-buffer-overflow/gcore-buffer-overflow.test warning: cannot close "================================================================= ==10108==ERROR: AddressSanitizer: heap-use-after-free on address 0x1259ea503110 at pc 0x7ff6806e3936 bp 0x0062e01ed990 sp 0x0062e01ed140 READ of size 111 at 0x1259ea503110 thread T0 #0 0x7ff6806e3935 in strlen C:/gcc/src/gcc-14.2.0/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:391 #1 0x7ff6807169c4 in __pformat_puts C:/gcc/src/mingw-w64-v12.0.0/mingw-w64-crt/stdio/mingw_pformat.c:558 #2 0x7ff6807186c1 in __mingw_pformat C:/gcc/src/mingw-w64-v12.0.0/mingw-w64-crt/stdio/mingw_pformat.c:2514 #3 0x7ff680713614 in __mingw_vsnprintf C:/gcc/src/mingw-w64-v12.0.0/mingw-w64-crt/stdio/mingw_vsnprintf.c:41 #4 0x7ff67f34419f in vsnprintf(char*, unsigned long long, char const*, char*) C:/msys64/mingw64/x86_64-w64-mingw32/include/stdio.h:484 #5 0x7ff67f34419f in string_vprintf[abi:cxx11](char const*, char*) C:/gdb/src/gdb.git/gdbsupport/common-utils.cc:106 #6 0x7ff67b37b739 in cli_ui_out::do_message(ui_file_style const&, char const*, char*) C:/gdb/src/gdb.git/gdb/cli-out.c:227 #7 0x7ff67ce3d030 in ui_out::call_do_message(ui_file_style const&, char const*, ...) C:/gdb/src/gdb.git/gdb/ui-out.c:571 #8 0x7ff67ce4255a in ui_out::vmessage(ui_file_style const&, char const*, char*) C:/gdb/src/gdb.git/gdb/ui-out.c:740 #9 0x7ff67ce2c873 in ui_file::vprintf(char const*, char*) C:/gdb/src/gdb.git/gdb/ui-file.c:73 #10 0x7ff67ce7f83d in gdb_vprintf(ui_file*, char const*, char*) C:/gdb/src/gdb.git/gdb/utils.c:1881 #11 0x7ff67ce7f83d in vwarning(char const*, char*) C:/gdb/src/gdb.git/gdb/utils.c:181 #12 0x7ff67f3530eb in warning(char const*, ...) C:/gdb/src/gdb.git/gdbsupport/errors.cc:33 #13 0x7ff67baed27f in gdb_bfd_close_warning C:/gdb/src/gdb.git/gdb/gdb_bfd.c:437 #14 0x7ff67baed27f in gdb_bfd_close_or_warn C:/gdb/src/gdb.git/gdb/gdb_bfd.c:646 #15 0x7ff67baed27f in gdb_bfd_unref(bfd*) C:/gdb/src/gdb.git/gdb/gdb_bfd.c:739 #16 0x7ff68094b6f2 in gdb_bfd_ref_policy::decref(bfd*) C:/gdb/src/gdb.git/gdb/gdb_bfd.h:82 #17 0x7ff68094b6f2 in gdb::ref_ptr<bfd, gdb_bfd_ref_policy>::~ref_ptr() C:/gdb/src/gdb.git/gdbsupport/gdb_ref_ptr.h:91 #18 0x7ff67badf4d2 in gcore_command C:/gdb/src/gdb.git/gdb/gcore.c:176 0x1259ea503110 is located 16 bytes inside of 4064-byte region [0x1259ea503100,0x1259ea5040e0) freed by thread T0 here: #0 0x7ff6806b1687 in free C:/gcc/src/gcc-14.2.0/libsanitizer/asan/asan_malloc_win.cpp:90 #1 0x7ff67f2ae807 in objalloc_free C:/gdb/src/gdb.git/libiberty/objalloc.c:187 #2 0x7ff67d7f56e3 in _bfd_free_cached_info C:/gdb/src/gdb.git/bfd/opncls.c:247 #3 0x7ff67d7f2782 in _bfd_delete_bfd C:/gdb/src/gdb.git/bfd/opncls.c:180 #4 0x7ff67d7f5df9 in bfd_close_all_done C:/gdb/src/gdb.git/bfd/opncls.c:960 #5 0x7ff67d7f62ec in bfd_close C:/gdb/src/gdb.git/bfd/opncls.c:925 #6 0x7ff67baecd27 in gdb_bfd_close_or_warn C:/gdb/src/gdb.git/gdb/gdb_bfd.c:643 #7 0x7ff67baecd27 in gdb_bfd_unref(bfd*) C:/gdb/src/gdb.git/gdb/gdb_bfd.c:739 #8 0x7ff68094b6f2 in gdb_bfd_ref_policy::decref(bfd*) C:/gdb/src/gdb.git/gdb/gdb_bfd.h:82 #9 0x7ff68094b6f2 in gdb::ref_ptr<bfd, gdb_bfd_ref_policy>::~ref_ptr() C:/gdb/src/gdb.git/gdbsupport/gdb_ref_ptr.h:91 #10 0x7ff67badf4d2 in gcore_command C:/gdb/src/gdb.git/gdb/gcore.c:176 It happens because gdb_bfd_close_or_warn uses a bfd-internal name for the failing-close warning, after the close is finished, and the name already freed: static int gdb_bfd_close_or_warn (struct bfd *abfd) { int ret; const char *name = bfd_get_filename (abfd); for (asection *sect : gdb_bfd_sections (abfd)) free_one_bfd_section (sect); ret = bfd_close (abfd); if (!ret) gdb_bfd_close_warning (name, bfd_errmsg (bfd_get_error ())); return ret; } Fixed by making a copy of the name for the warning. Approved-By: Andrew Burgess <aburgess@redhat.com>
2024-10-30gdb: Update SECURITY.txt to mention extension scripts and internal errorsGuinevere Larsen1-13/+38
Given the recent CVE filed for GDB (CVE-2024-36699), I decided to update the gdb/SECURITY.txt to be more explicit about some details. Specifically, we now explicitly say that internal errors aren't security vulnerabilities, and mention that users should review plugins before running them, and under which conditions a plugin can cause a security bug. Reviewed-By: Tom Tromey <tom@tromey.com> Approved-By: Luis Machado <luis.machado@arm.com> Approved-By: Andrew Burgess <aburgess@redhat.com>
2024-10-30[gdb/tdep] Use std::array in amd64-windows-tdep.cTom de Vries1-24/+27
I noticed commit 84786372e1c ("Fix size of register buffer") fixing a stack-buffer-overflow found by AddressSanitizer in amd64_windows_store_arg_in_reg: ... - gdb_byte buf[8]; + gdb_byte buf[16]; ... and wondered if we could have found this without AddressSanitizer. I realized that the problem is that this: ... gdb_byte buf[N]; ... regcache->cooked_write (regno, buf); ... is using the deprecated variant of cooked_write instead of the one using gdb::array_view: ... /* Transfer of pseudo-registers. */ void cooked_write (int regnum, gdb::array_view<const gdb_byte> src); /* Deprecated overload of the above. */ void cooked_write (int regnum, const gdb_byte *src); ... and consequently cooked_write does not know the size of buf. Fix this by using std::array, and likewise in other places in gdb/amd64-windows-tdep.c. In the process I fixed another out of bounds access here: ... gdb_byte imm16[2]; ... cache->prev_sp = cur_sp + extract_unsigned_integer (imm16, 4, byte_order); ... where we're reading 4 bytes from the 2-byte buffer imm16. Tested by rebuilding on x86_64-linux. Tested-By: Hannes Domani <ssbssa@yahoo.de>
2024-10-29Fix signal unsafe call inside a signalBernd Edlinger4-9/+100
It can easily happen that the signal handler function `handle_fatal_signal` uses various signal unsafe functions. The problematic functions are `_` and `strsignal` which can be pre-computed after the `setlocale` call is done. Unfortunately when compiled with --disable-libbacktrace a different code path is used, that calls the glibc function `backtrace` which calls `malloc` and `free` and is therefore also signal unsafe, that is probably unfixable, so there is no attempt to fix anything in this code path. Approved-By: Andrew Burgess <aburgess@redhat.com> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31713#c9
2024-10-29[gdb/testsuite] Add read1 and readmore to make-check-all.shTom de Vries1-3/+42
There are two useful ways to run a test-case, that are not represented by a board file in gdb/testsuite/boards: check-read1 and check-readmore. Consequently, they're not run either by make-check-all.sh. Fix this by adding check-read1 and check-readmore to make-check-all.sh. Tested on x86_64-linux. Verified with shellcheck. Approved-By: Andrew Burgess <aburgess@redhat.com>
2024-10-29[gdb/symtab] Handle multiple .debug_info sectionsTom de Vries7-19/+109
When compiling dw2-multiple-debug-info.c using -gdwarf-5 -fdebug-types-section, we end with two .debug_info sections in the object file: ... $ g++ gdb.dwarf2/dw2-multiple-debug-info.c -c -g \ -gdwarf-5 \ -fdebug-types-section $ readelf -WS dw2-multiple-debug-info.o | grep -v RELA | grep .debug_info [10] .debug_info PROGBITS 0 000128 0000cd 00 GC 0 0 8 [12] .debug_info PROGBITS 0 0001f8 0000ad 00 C 0 0 8 ... One of them contains the CU for dw2-multiple-debug-info.c, the other contains the TU for the type of variable a. When trying to print the type of variable a, we get: ... $ gdb -q -batch dw2-multiple-debug-info.o -ex "ptype a" 'a' has unknown type; cast it to its declared type ... because the TU hasn't been read. Fix this by adding support for reading multiple .debug_info sections, similar to how that is done for multiple .debug_types sections, getting us instead: ... $ gdb -q -batch dw2-multiple-debug-info.o -ex "ptype a" type = class sp1::A { ... } ... Tested on x86_64-linux. PR symtab/32223 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32223
2024-10-29fortran: Fix arrays of variable length strings for FORTRANIjaz, Abdul B6-5/+219
Before this change resolve_dynamic_array_or_string was called for all TYPE_CODE_ARRAY and TYPE_CODE_STRING types, but, in the end, this function always called create_array_type_with_stride, which creates a TYPE_CODE_ARRAY type. Suppose we have subroutine vla_array (arr1, arr2) character (len=*):: arr1 (:) character (len=5):: arr2 (:) print *, arr1 ! break-here print *, arr2 end subroutine vla_array The "print arr1" and "print arr2" command at the "break-here" line gives the following output: (gdb) print arr1 $1 = <incomplete type> (gdb) print arr2 $2 = ('abcde', 'abcde', 'abcde') (gdb) ptype arr1 type = Type End Type (gdb) ptype arr2 type = character*5 (3) Dwarf info using Intel® Fortran Compiler for such case contains following: <1><fd>: Abbrev Number: 12 (DW_TAG_string_type) <fe> DW_AT_name : (indirect string, offset: 0xd2): .str.ARR1 <102> DW_AT_string_length: 3 byte block: 97 23 8 (DW_OP_push_object_address; DW_OP_plus_uconst: 8) After this change resolve_dynamic_array_or_string now calls create_array_type_with_stride or create_string_type, so if the incoming dynamic type is a TYPE_CODE_STRING then we'll get back a TYPE_CODE_STRING type. Now gdb shows following: (gdb) p arr1 $1 = ('abddefghij', 'abddefghij', 'abddefghij', 'abddefghij', 'abddefghij') (gdb) p arr2 $2 = ('abcde', 'abcde', 'abcde') (gdb) ptype arr1 type = character*10 (5) (gdb) ptype arr2 type = character*5 (3) In case of GFortran, compiler emits DW_TAG_structure_type for string type arguments of the subroutine and it has only DW_AT_declaration tag. This results in <incomplete type> in gdb. So, following issue is raised in gcc bugzilla "https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101826". Fixing above issue introduce regression in gdb.fortran/mixed-lang-stack.exp, i.e. the test forces the language to C/C++ and print a Fortran string value. The string value is a dynamic type with code TYPE_CODE_STRING. Before this commit the dynamic type resolution would always convert this to a TYPE_CODE_ARRAY of characters, which the C value printing could handle. But now after this commit we get a TYPE_CODE_STRING, which neither the C value printing, or the generic value printing code can support. And so, I've added support for TYPE_CODE_STRING to the generic value printing, all characters of strings are printed together till the first null character. Lastly, in gdb.opt/fortran-string.exp and gdb.fortran/string-types.exp tests it expects type of character array in 'character (3)' format but now after this change we get 'character*3', so tests are updated accordingly. Approved-By: Tom Tromey <tom@tromey.com>
2024-10-28Fix size of register bufferHannes Domani1-1/+2
When calling a function with double arguments, I get this asan error: ==7920==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x0053131ece38 at pc 0x7ff79697a68f bp 0x0053131ec790 sp 0x0053131ebf40 READ of size 16 at 0x0053131ece38 thread T0 #0 0x7ff79697a68e in MemcmpInterceptorCommon(void*, int (*)(void const*, void const*, unsigned long long), void const*, void const*, unsigned long long) C:/gcc/src/gcc-14.2.0/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:814 #1 0x7ff79697aebd in memcmp C:/gcc/src/gcc-14.2.0/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:845 #2 0x7ff79697aebd in memcmp C:/gcc/src/gcc-14.2.0/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:840 #3 0x7ff7927e237f in regcache::raw_write(int, gdb::array_view<unsigned char const>) C:/gdb/src/gdb.git/gdb/regcache.c:874 #4 0x7ff7927e3c85 in regcache::cooked_write(int, gdb::array_view<unsigned char const>) C:/gdb/src/gdb.git/gdb/regcache.c:914 #5 0x7ff7927e5d89 in regcache::cooked_write(int, unsigned char const*) C:/gdb/src/gdb.git/gdb/regcache.c:933 #6 0x7ff7911d5965 in amd64_windows_store_arg_in_reg C:/gdb/src/gdb.git/gdb/amd64-windows-tdep.c:216 Address 0x0053131ece38 is located in stack of thread T0 at offset 40 in frame #0 0x7ff7911d565f in amd64_windows_store_arg_in_reg C:/gdb/src/gdb.git/gdb/amd64-windows-tdep.c:208 This frame has 4 object(s): [32, 40) 'buf' (line 211) <== Memory access at offset 40 overflows this variable It's because the first 4 double arguments are passed via XMM registers, and they need a buffer of 16 bytes, even if we only use 8 bytes of them. Approved-By: Tom Tromey <tom@tromey.com>
2024-10-28Don't copy memory for arguments if there are noneHannes Domani1-0/+1
If amd64_windows_push_arguments is called with no arguments, then ARGS can be NULL, and inside the passed-by-pointer block, memcpy is called with this NULL, which is undefined behavior. So this just disable the passed-by-pointer block if there are no arguments. Fixes the following ubsan error: C:/gdb/src/gdb.git/gdb/amd64-windows-tdep.c:244:12: runtime error: null pointer passed as argument 2, which is declared to never be null Approved-By: Tom Tromey <tom@tromey.com>
2024-10-28gdb/record: add support to vzeroupper instructionGuinevere Larsen3-0/+73
This commit adds recording support for the AVX instruction vzeroupper, which zeroes the high bits of ymm registers 0..15. In the programmer's manual, it is explicitly states that ymm registers 16..31 won't be affected if present, so we only need to record the first 16 registers. We record ymm_h registers since only the higher bits are touched, and that reduces the memory footprint of the instruction. This instruction is tested differently as we want to confirm we're only saving the relevant registers, and we want to ensure we're saving all of them, so it makes use of "maint print record-instruction" to see exactly what was recorded. Approved-By: Tom Tromey <tom@tromey.com>
2024-10-28gdb/record: support AVX instructions VMOVDQ(U|A) when recordingGuinevere Larsen3-4/+115
This commit adds support for the instructions VMOVDQU and VMOVDQA, used to move values to/from 256 bit registers. Unfortunately, the programmer's manual is very incomplete (if not wrong) about these instructions, so the logic had to be reverse engineered from how gcc actually encodes the instruction. This commit also changes the memory regions from the test to store 256 bits, so its easier to test the instructions and that we're recording ymm registers correctly. Approved-By: Tom Tromey <tom@tromey.com>
2024-10-28gdb/record: Add recording support to vpbroadcast instructionsGuinevere Larsen3-0/+71
This commit adds recording support to all AVX and AVX2 instructions of the form vpbroadcast. GDB is not yet concerned about AVX512 in recording mode, so for now we only support the AVX2 registers and instructions. This commit also updates the gdb.reverse/i386-avx-reverse.exp to test broadcast instructions. Approved-By: Tom Tromey <tom@tromey.com>
2024-10-28gdb/record: add support to AVX unpack instructionsGuinevere Larsen3-1/+121
This commit adds support to recording instructions to unpack high or low data from XMM registers, identified by the mnemonics in the form: VPUNPCK [L|H] [BW|WD|DQ|QDQ]. All these instructions are encoded the exact same way, and only affect the destination register, making them trivial to implement together. It also updates the test gdb.reverse/i386-avx-reverse.exp to test these new instructions. The test always uses ymm because the vpunpck instructions overwrite the high bits, so we have to be able to record the full ymm register, not just the output size. Approved-By: Tom Tromey <tom@tromey.com>
2024-10-28gdb/record: add support to vmovd and vmovq instructionsGuinevere Larsen5-2/+359
This commit adds support to the x86_64 AVX instructions vmovd and vmovq. The programmers manuals for Intel and AMD describe these 2 instructions as being almost the same, but my local testing, using gcc 13.2 on Fedora 39, showed several differences and inconsistencies. The instruction is supposed to always use the 3-byte VEX prefix, but I could only find 2-byte versions. The instructions aren't differentiated by the VEX.w bit, but by opcodes and VEX.pp. This patch adds a test with many different uses for both vmovd and vmovq. It also updates the test gdb.reverse/step-precsave.exp to reference the generic "missing avx support" bug open in the bug tracker (17346), instead of pointing to one that specifically calls out to vmovd instructions. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23188 Approved-By: Tom Tromey <tom@tromey.com>
2024-10-28gdb: Start supporting AVX instructionGuinevere Larsen4-4/+105
This patch introduces the information needed to properly identify the VEX prefix, used to signal an AVX and AVX2 instruction, and introduces a helper function to handle all AVX instruction, instead of adding to the 3000 line long recording function. This new function will temporarily set the current thread as "not executing" so that it can read from pseudo registers as we record, since most AVX/AVX2 instructions would benefit from recording ymm registers. The new helper also handles unsupported instructions so that the largest part of the i386_process_record doesn't have to be shifted by 2 spaces, which made an unreadably big patch file. The only expected difference to the end user added by this patch is a small change to the unsupported message. This patch also updates the test gdb.reverse/step-precsave.exp, by recognizing the new output. As a note for the future, we don't handle xmm16-31 and ymm16-31 because those require the EVEX prefix, meaning avx512 support. Approved-By: Tom Tromey <tom@tromey.com>
2024-10-28gdb: Allow replayed threads to read and write pseudo registersGuinevere Larsen3-2/+25
In an effort to support AVX instructions when recording, we need to allow replaying threads to access pseudo registers. Currently, if we try to do that gdb will fail in a call to validate_registers_access, because the thread is executing so GDB thinks it is unsafe to read pseudo registers. When replaying, the thread is really executing for all intents and purposes, but the execution is just having GDB change values on registers, so it will always be safe to read and write pseudo registers. This commit changes functions that check for register access to allow access when we are replaying. The check to whether we are replaying must not happen when writing a core file, as record_full_list could be nullptr, so we only check it if the thread is executing. As of this commit, I don't know of a way to trigger this commit without AVX support on record, so a test isn't provided. However, as soon as record-full supports saving ymm registers, the AVX tests will test this as well. Approved-By: Tom Tromey <tom@tromey.com>
2024-10-27gdb/testsuite: avoid intermittent failures on a debuginfod testAndrew Burgess1-1/+1
I saw a failure in gdb.debuginfod/build-id-no-debug-warning.exp which I could only produce one time. Normally the test output looks like this: file /tmp/build/gdb/testsuite/outputs/gdb.debuginfod/build-id-no-debug-warning/.build-id/0c/30f589cc4f2c0fb22c8914d042ddf39c9a3885.debug Reading symbols from /tmp/build/gdb/testsuite/outputs/gdb.debuginfod/build-id-no-debug-warning/.build-id/0c/30f589cc4f2c0fb22c8914d042ddf39c9a3885.debug... Downloading separate debug info for /tmp/build/gdb/testsuite/outputs/gdb.debuginfod/build-id-no-debug-warning/.build-id/0c/30f589cc4f2c0fb22c8914d042ddf39c9a3885.debug... Reading symbols from /tmp/build/gdb/testsuite/outputs/gdb.debuginfod/build-id-no-debug-warning/.client_cache/0c30f589cc4f2c0fb22c8914d042ddf39c9a3885/debuginfo... (gdb) PASS: gdb.debuginfod/build-id-no-debug-warning.exp: local_debuginfod: debuginfod running, info downloaded, no war But one time I saw this: file /tmp/build/gdb/testsuite/outputs/gdb.debuginfod/build-id-no-debug-warning/.build-id/0c/30f589cc4f2c0fb22c8914d042ddf39c9a3885.debug Reading symbols from /tmp/build/gdb/testsuite/outputs/gdb.debuginfod/build-id-no-debug-warning/.build-id/0c/30f589cc4f2c0fb22c8914d042ddf39c9a3885.debug... Downloading 6.77 K separate debug info for /tmp/build/gdb/testsuite/outputs/gdb.debuginfod/build-id-no-debug-warning/.build-id/0c/30f589cc4f2c0fb22c8914d042ddf39c9a3885.debug... Reading symbols from /tmp/build/gdb/testsuite/outputs/gdb.debuginfod/build-id-no-debug-warning/.client_cache/0c30f589cc4f2c0fb22c8914d042ddf39c9a3885/debuginfo... (gdb) FAIL: gdb.debuginfod/build-id-no-debug-warning.exp: local_debuginfod: debuginfod running, info downloaded, no warnings The difference is the "Downloading separate debug info for ..." line has gained an extra '6.77 K' component. When I got the FAIL the machine was under heavy load, so I suspect everything was running pretty slow. I think the size is only added when the debuginfod download is taking its time. Anyway, the test in question is not expecting to see a size, which is why it failed. Every other debuginfod test does allow for an optional size being printed, so lets update this test to also accept an optional size, this should prevent failures like this in the future.
2024-10-26[gdb/testsuite] Fix gdb.dwarf2/dwp-symlink.exp with target board fission-dwpTom de Vries1-6/+11
There are two test-cases that only run when the target board produces .dwp files, gdb.dwarf2/dwp-sepdebug.exp and gdb.dwarf2/dwp-symlink.exp. When running those test-cases with target board fission-dwp, I run into: ... (gdb) ptype main^M warning: Could not find DWO CU dwp-symlink0.dwo(0x496f1a7405c37a61) \ referenced by CU at offset 0xa6 [in module dwp-symlink]^M type = <unknown return type> ()^M (gdb) FAIL: gdb.dwarf2/dwp-symlink.exp: binary default, dwp at symlink ... coming from: ... # This case cannot work. gdb_test "ptype main" {type = int \(\)} "binary default, dwp at symlink" ... I had a bit of difficulty understanding what the test-case does/tries to do, so to build some understanding I reproduced the behaviour outside of the test-case: ... $ cat start.c void _start (void) {} $ gcc -gsplit-dwarf start.c -nostdlib $ gdb -q -batch a.out -ex "print _start" $1 = {void (void)} 0x400144 <_start> $ dwp -e a.out $ rm start.dwo $ gdb -q -batch a.out -ex "print _start" $1 = {void (void)} 0x400144 <_start> $ ln -s a.out b.out $ gdb -q -batch b.out -ex "print _start" $1 = {void (void)} 0x400144 <_start> $ mv a.out.dwp b.out.dwp $ gdb -q -batch b.out -ex "print _start" $1 = {void (void)} 0x400144 <_start> $ gdb -q -batch a.out -ex "print _start" During symbol reading: Could not find DWO CU start.dwo(0x8bdfd613387aa145) \ referenced by CU at offset 0x0 [in module a.out] warning: Could not find DWO CU start.dwo(0x8bdfd613387aa145) \ referenced by CU at offset 0x0 [in module a.out] $1 = {<text variable, no debug info>} 0x400144 <_start> ... and agreed, that cannot work: the DWO CU required in a.out is in b.out.dwp, and there's no way to find b.out.dwp starting from a.out. The fact that a FAIL is produced is incorrect, gdb does nothing wrong. Fix this by checking for the warning text instead. While we're at it, fix this PATH as well: ... (gdb) cd /data/vries/gdb/leap-15-5/build/gdb/testsuite/outputs/gdb.dwarf2/dwp-symlink^M Working directory /data/vries/gdb/leap-15-5/build/gdb/testsuite/outputs/gdb.dwarf2/dwp-symlink.^M (gdb) PASS: gdb.dwarf2/dwp-symlink.exp: cd \ /data/vries/gdb/leap-15-5/build/gdb/testsuite/outputs/gdb.dwarf2/dwp-symlink PATH: gdb.dwarf2/dwp-symlink.exp: cd \ /data/vries/gdb/leap-15-5/build/gdb/testsuite/outputs/gdb.dwarf2/dwp-symlink ... While we're at it, use string_to_regexp to simplify the test-case. Tested on x86_64-linux, with target board fission-dwp.
2024-10-26gdb/testsuite: fix test pattern after switch to -lbl matchingAndrew Burgess1-3/+3
After commit: commit a1ccc78ea7ba8cad3ff37cbde9b5d3bba0194796 Date: Fri Oct 25 06:14:03 2024 +0200 [gdb/testsuite] Fix some test-cases for check-read1 (-lbl) I notice that gdb.base/sect-cmd.exp would sometimes fail. The problem is that by switching to line by line matching we now need to ensure that the gdb_test_multiple patterns match up to the end of the line, but don't actually include the trailing \r\n (yeah, our line by line matching is weird). We need to be especially careful anywhere '.*' is used as this can potentially match content on a subsequent line. I have replaced '.*' with '\[^\r\n\]*(?=\r\n)', matching everything up to the end of the line, but not the end of line itself, and I've made use of '(?=\r\n)' in a couple of other places to ensure we match up to the end of the line, but don't match the line terminator itself.
2024-10-26[gdb] Don't create registry keys in destructorTom de Vries6-20/+34
Creating a registry key using emplace calls new: ... DATA *result = new DATA (std::forward<Args> (args)...); ... which can throw a bad alloc, which will terminate gdb if called from a destructor. Fix this in a few places. Tested on aarch64-linux. Approved-By: Tom Tromey <tom@tromey.com>
2024-10-25[gdb] Handle bad alloc in gdb_rl_callback_read_char_wrapper_noexceptTom de Vries1-1/+17
Say we simulate a bad alloc in exceptions_state_mc_init: ... jmp_buf * exceptions_state_mc_init () { + { + static bool throw_bad_alloc = true; + if (throw_bad_alloc) + { + throw_bad_alloc = false; + + va_list dummy; + throw gdb_quit_bad_alloc (gdb_exception_quit ("bad alloc", dummy)); + } + } catchers.emplace_front (); return &catchers.front ().buf; } ... After starting gdb and typing "q", gdb terminates: ... $ gdb -q (gdb) terminate called after throwing an instance of 'gdb_quit_bad_alloc' what(): std::bad_alloc ... because the bad alloc (thrown in TRY_SJLJ) is caught by the noexcept on gdb_rl_callback_read_char_wrapper_noexcept: ... static struct gdb_exception gdb_rl_callback_read_char_wrapper_noexcept () noexcept { struct gdb_exception gdb_expt; /* C++ exceptions can't normally be thrown across readline (unless it is built with -fexceptions, but it won't by default on many ABIs). So we instead wrap the readline call with a sjlj-based TRY/CATCH, and rethrow the GDB exception once back in GDB. */ TRY_SJLJ ... Fix this by renaming gdb_rl_callback_read_char_wrapper_noexcept to gdb_rl_callback_read_char_wrapper_sjlj and calling it from a wrapper function that catches the bad alloc expection: ... static struct gdb_exception gdb_rl_callback_read_char_wrapper_noexcept () noexcept { try { return gdb_rl_callback_read_char_wrapper_sjlj (); } catch (gdb_exception &ex) { return std::move (ex); } } ... getting us instead: ... $ gdb -q (gdb) bad alloc (gdb) q ... Tested on aarch64-linux.
2024-10-25[gdb/testsuite] Fix gdb.cp/exceptprint.exp with check-read1Tom de Vries1-1/+2
Fix test-case gdb.cp/exceptprint.exp with make target check-read1 by limiting the output of skip_libstdcxx_probe_tests_prompt by making the used command more precise: using "info probes stap libstdcxx" instead of "info probes". Tested on x86_64-linux.
2024-10-25[gdb/testsuite] Fix gdb.threads/ia64-sigill.exp with check-read1Tom de Vries1-4/+19
Fix test-case gdb.threads/ia64-sigill.exp with make target check-read1 by using a custom line-by-line exp_continue clause: ... -re "\r\n\[^\r\n\]*(?=\r\n\[^\r\n\]*\r\n)" { exp_continue } ... which drops a line each time it finds two lines in the buffer. This allows the other clauses to use two-line patterns. Tested on x86_64-linux.
2024-10-25[gdb/testsuite] Fix some test-cases for check-read1 (-lbl)Tom de Vries1-7/+14
I ran the testsuite in an environment simulating a stressed system in combination with check-read1. This exposes a few more FAILs. Fix some by using -lbl. Tested on x86_64-linux.
2024-10-25[gdb/testsuite] Fix some test-cases for check-read1 (pipe/grep)Tom de Vries6-15/+34
I ran the testsuite in an environment simulating a stressed system in combination with check-read1. This exposes a few more FAILs. Fix some by using pipe / grep to filter out unnecessary output. Tested on x86_64-linux.
2024-10-25[gdb/testsuite] Fix some test-cases for check-read1 (gdb_test_lines)Tom de Vries7-88/+80
I ran the testsuite in an environment simulating a stressed system in combination with check-read1. This exposes a few more FAILs. Fix some by using gdb_test_lines, as well as related gdb_get_lines. Tested on x86_64-linux.
2024-10-24Add locking when reading BFD sectionsTom Tromey1-0/+23
This adds some per-BFD locking to gdb_bfd_map_section and gdb_bfd_get_full_section_contents. It turned out that the background DWARF reader could race with the auto-load code, because the reader might try to mmap a section when the main thread was trying to read in .debug_gdb_scripts. The current BFD threading model is that only BFD globals will be locked, so any multi-threaded use of a BFD has to be handled specially by the application. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31626 Reviewed-by: Kevin Buettner <kevinb@redhat.com>
2024-10-24Use gdb_bfd_get_full_section_contents in auto-load.cTom Tromey1-7/+4
This changes auto-load.c ot use gdb_bfd_get_full_section_contents. This shouldn't change any behavior, but makes it easier to add locking in a subsequent patch. Reviewed-by: Kevin Buettner <kevinb@redhat.com>
2024-10-23gdb/testsuite: introduce dwarf5 option to gdb_compileGuinevere Larsen5-5/+12
A few tests on the testsuite require dwarf5 to work. Up until now, the way to do this was to explicitly add the command line flag -gdwarf-5. This isn't very portable, in case a compiler requires a different flag to emit dwarf5. This commit adds a new option to gdb_compile that would be able to add the correct flag (if known) or error out in case we are unable to tell which flag to use. It also changes the existing tests to use this general option instead of hard coding -gdwarf-5. Reviewed-by: Keith Seitz <keiths@redhat.com> Approved-By: Tom Tromey <tom@tromey.com>
2024-10-22Implement 'Object_SizeTom Tromey12-16/+254
This patch started as an attempt to allow the 'Size attribute to be applied to types, and not just objects. However, that turns out to be difficult due to the Ada semantcs of 'Size. In particular, Ada requires 'Size to denote the size of the representation of the value, so for example Boolean'Size must be 1. Implementing this properly requires information not readily available to gdb... and while we could synthesize this information in many cases, it also seemed to me that this wasn't strictly very useful when debugging. So instead, this patch adds support for the 'Object_Size attribute, which is somewhat closer to 'sizeof'. Note also that while 'Object_Size is defined for some dynamic types, I chose not to implement this here, as again this information is not readily available -- and I think it's preferable to error than to print something that might be incorrect. Reviewed-By: Eli Zaretskii <eliz@gnu.org>
2024-10-22[gdb/testsuite] Handle maint set dwarf synchronous off defaultTom de Vries3-3/+19
I ran the testsuite with a patch setting dwarf_synchronous to false by default, and ran into FAILs in test-cases gdb.dwarf2/dw2-inter-cu-error.exp and gdb.dwarf2/dw2-inter-cu-error-2.exp, because the expected DWARF errors did not show up as a result of the file command. Fix this by forcing "maint set dwarf synchronous on". Add the same in gdb.base/index-cache.exp, where this is also required. Tested on aarch64-linux.
2024-10-22[gdb/testsuite] Improve class name in gdb.dwarf2/self-spec.expTom de Vries1-3/+3
I ran into: ... (gdb) pipe maint print objfiles self-spec | grep c1^M name: c1^M canonical: c1^M qualified: c1^M [3] ((addrmap *) 0xfffedfc1f010)^M (gdb) FAIL: gdb.dwarf2/self-spec.exp: class c1 in cooked index ... Fix this by renaming the class from c1 to class1. Tested on aarch64-linux.
2024-10-22[gdb] Handle EINTR in run_under_shellTom de Vries1-1/+6
When building gdb with -O2 -fsanitize=thread and running test-case gdb.base/bg-exec-sigint-bp-cond.exp, I run into: ... (gdb) c&^M Continuing.^M (gdb) Quit^M (gdb) quit_count=1 ^M Breakpoint 2, foo () at bg-exec-sigint-bp-cond.c:23^M 23 return 0;^M FAIL: $exp: no force memory write: \ SIGINT does not interrupt background execution ... What happens is that: - the breakpoint hits - while evaluating the condition of the breakpoint, $_shell("kill -INT <pid-of-gdb>") is called, handled by run_under_shell - in run_under_shell, a vfork is issued - in the vfork child, execl executes the kill command - in the vfork parent, waitpid is called to wait for the result of the kill command - waitpid returns -1 with errno set to EINTR - run_under_shell doesn't check the result of waitpid, and returns the value of local variable status. Since waitpid returned -1, status was not assigned a value, so it's uninitialized, and happens to be non-zero - the breakpoint condition evaluates to true, because $_shell("kill -INT <pid-of-gdb>") != 0 - the breakpoint triggers a stop, which the test-case doesn't expect. Fix this by using gdb::handle_eintr to call waitpid in run_under_shell. Also handle the case that waitpid returns an error other than EINTR, using perror_with_name. Tested on x86_64-linux. Approved-By: Tom Tromey <tom@tromey.com> PR gdb/30695 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30695
2024-10-21[gdb/symtab] Fix incorrect filenames with inter-CU refsTom de Vries3-6/+118
With target board unix we get: ... $ gdb -q -batch outputs/gdb.cp/cplusfuncs/cplusfuncs \ -ex "info function operator\*" All functions matching regular expression "operator\*": File /home/vries/gdb/src/gdb/testsuite/gdb.cp/cplusfuncs.cc: 72: void foo::operator*(foo&); 85: void foo::operator*=(foo&); ... but with target board cc-with-dwz-m: ... All functions matching regular expression "operator\*": File /usr/lib/gcc/aarch64-redhat-linux/14/include/stddef.h: 72: void foo::operator*(foo&); 85: void foo::operator*=(foo&); ... The first operator: ... $ c++filt _ZN3foomlERS_ foo::operator*(foo&) ... matches address 0x410250 which is defined here in the CU in the exec: ... <1><10f1>: Abbrev Number: 13 (DW_TAG_subprogram) <10f2> DW_AT_specification: <alt 0x93> <10f6> DW_AT_decl_line : 72 <10f7> DW_AT_decl_column : 7 <10f7> DW_AT_object_pointer: <0x1106> <10f9> DW_AT_low_pc : 0x410250 <1101> DW_AT_high_pc : 32 <1102> DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_cfa) <1104> DW_AT_call_all_calls: 1 ... and declared here in the PU in the .dwz file: ... <2><93>: Abbrev Number: 20 (DW_TAG_subprogram) <94> DW_AT_external : 1 <94> DW_AT_name : operator* <98> DW_AT_decl_file : 2 <98> DW_AT_decl_line : 10 <99> DW_AT_decl_column : 9 <9a> DW_AT_linkage_name: _ZN3foomlERS_ <9e> DW_AT_accessibility: 1 (public) <9e> DW_AT_declaration : 1 <9e> DW_AT_object_pointer: <0xa2> ... When creating a new symbol for the operator, the DW_AT_decl_file attribute is looked up, and found to be 2. The 2 is supposed to be mapped using the PU, which has this file name table: ... The File Name Table (offset 0x78, lines 3, columns 2): Entry Dir Name 0 0 <dwz> 1 1 stddef.h 2 2 cplusfuncs.cc ... Instead, it's mapped using the CU, which has this file name table: ... The File Name Table (offset 0x34, lines 3, columns 2): Entry Dir Name 0 1 cplusfuncs.cc 1 1 cplusfuncs.cc 2 2 stddef.h ... This is PR symtab/30814. There's a similar PR for lto, PR symtab/25771, where the same problem happens for two CUs. Fix this by using the correct file name table. Add a dwarf assembly test-case for PR25771. Tested on aarch64-linux. Reviewed-By: Tom Tromey <tom@tromey.com> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=25771 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30814
2024-10-21[gdb/contrib] Handle dot in spellcheck.shTom de Vries7-38/+52
Add handling of '.' in gdb/contrib/spellcheck.sh. While we're at, simplify the sed invocation by using a single s command instead of 3 s commands. Also introduce sed_join and grep_join. Fix the following common misspellings: ... bandwith -> bandwidth emmitted -> emitted immediatly -> immediately suprize -> surprise thru -> through transfered -> transferred ... Verified with shellcheck.
2024-10-21[gdb/contrib] Speed up spellcheck.sh --checkTom de Vries1-15/+34
Speed up gdb/contrib/shellcheck.sh by caching the grep pattern. Without cached grep pattern: ... $ time ./gdb/contrib/spellcheck.sh --check gdb/gdb.c real 0m2,750s user 0m0,013s sys 0m0,032s ... and with cached grep pattern: ... $ time ./gdb/contrib/spellcheck.sh --check gdb/gdb.c real 0m0,192s user 0m0,022s sys 0m0,024s ... Tested on aarch64-linux.
2024-10-21[gdb/contrib] Add spellcheck.sh --checkTom de Vries1-1/+18
Add a new option --check to gdb/contrib/spellcheck.sh, to do the spell check and bail out ASAP with an exit code of 1 if misspelled words were found, or 0 otherwise. Verified with shellcheck.
2024-10-21gdb/guile: add get-basic-typeAndrew Burgess4-1/+29
A question was asked on stackoverflow.com about the guile function get-basic-type[1] which is mentioned in the docs along with an example of its use. The problem is, the function was apparently never actually added to GDB. But it turns out that it's pretty easy to implement, so lets add it now. Better late than never. The implementation mirrors the Python get_basic_type function. I've added a test which is a copy of the documentation example. One issue is that the docs suggest that the type will be returned as just "int", however, I'm not sure what this actually means. It makes more sense that the function return a gdb:type object which would be represented as "#<gdb:type int>", so I've updated the docs to show this output. [1] https://stackoverflow.com/questions/79058691/unbound-variable-get-basic-type-in-gdb-guile-session Reviewed-By: Kevin Buettner <kevinb@redhat.com>
2024-10-21[gdb/build, c++20] Fix more deprecated implicit capture of thisTom de Vries2-3/+3
When building gdb with -std=c++20 I run into: ... gdb/dwarf2/cooked-index.c: In lambda function: gdb/dwarf2/cooked-index.c:471:47: error: implicit capture of ‘this’ via \ ‘[=]’ is deprecated in C++20 [-Werror=deprecated] 471 | gdb::thread_pool::g_thread_pool->post_task ([=] () | ^ gdb/dwarf2/cooked-index.c:471:47: note: add explicit ‘this’ or ‘*this’ capture ... Fix this and two more spots by removing the capture default, and explicitly listing all captures. Tested on x86_64-linux.
2024-10-20gdb: fix 'maint info inline-frames' after 'stepi'Andrew Burgess2-7/+44
There is an invalid assumption within 'maint info inline-frames' which triggers an assert: (gdb) stepi 0x000000000040119d 18 printf ("Hello World\n"); (gdb) maintenance info inline-frames ../../src/gdb/inline-frame.c:554: internal-error: maintenance_info_inline_frames: Assertion `it != inline_states.end ()' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. ----- Backtrace ----- ... etc ... The problem is this assert: /* Stopped threads always have cached inline_state information. */ gdb_assert (it != inline_states.end ()); If you check out infrun.c and look in handle_signal_stop for the call to skip_inline_frames then you'll find a rather large comment that explains that we don't always compute the inline state information for performance reasons. So the assertion is not valid. I've updated the code so that if there is cached information we use that, but if there is not then we just create our own information for the current $pc of the current thread. This means that, if there is cached information, GDB still correctly shows which frame the inferior is in (it might not be in the inner most frame). If there is no cached information we will always display the inferior as being in the inner most frame, but that's OK, because if skip_inline_frames has not been called then GDB will have told the user they are in the inner most frame, so everything lines up. I've extended the test to check 'maint info inline-frames' after a stepi which would previously have triggered the assertion.
2024-10-20Use std::make_unique in more placesTom Tromey11-31/+35
I searched for spots using ".reset (new ...)" and replaced most of these with std::make_unique. I think this is a bit cleaner and more idiomatic. Regression tested on x86-64 Fedora 40. Reviewed-By: Klaus Gerlicher<klaus.gerlicher@intel.com>
2024-10-19Capture the current directory and debug directory in DWARF readerTom Tromey2-7/+18
This changes the DWARF reader to capture the current working directory and the current debug directory. This avoids races when the DWARF reader is working in the background. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31716
2024-10-19Add cwd paramter to openpTom Tromey2-5/+8
This patch adds a cwd paramter to openp, so that the current directory can be passed in by the caller. This is useful when background threads call this function -- they can then avoid using the global and thus avoid races with the user using "cd". Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31716
2024-10-19[gdbsupport] Add gdb::array_view::{iterator,const_iterator}Tom de Vries1-0/+36
While trying to substitute some std::vector type A in the code with a gdb::array_view: ... - using A = std::vector<T> + using A = gdb::array_view<T> .... I ran into the problem that the code was using A::iterator while gdb::array_view doesn't define such a type. Fix this by: - adding types gdb::array_view::iterator and gdb::array_view::const_iterator, - using them in gdb::array_view::(c)begin and gdb::array_view::(c)end, as is usual, and - using them explicitly in a unit test. Tested on aarch64-linux. Approved-By: Tom Tromey <tom@tromey.com>
2024-10-19[gdb/guile, c++20] Work around Werror=volatile in libguile.hTom de Vries1-1/+8
When building gdb with -std=c++20, I run into: ... In file included from /usr/include/guile/2.0/libguile/__scm.h:479, from /usr/include/guile/2.0/libguile.h:31, from /data/vries/gdb/src/gdb/guile/guile-internal.h:30, from /data/vries/gdb/src/gdb/guile/guile.c:37: /usr/include/guile/2.0/libguile/gc.h: In function ‘scm_unused_struct* \ scm_cell(scm_t_bits, scm_t_bits)’: /usr/include/guile/2.0/libguile/tags.h:98:63: error: using value of \ assignment with ‘volatile’-qualified left operand is deprecated \ [-Werror=volatile] 98 | # define SCM_UNPACK(x) ((scm_t_bits) (0? (*(volatile SCM *)0=(x)): x)) | ~~~~~~~~~~~~~~~~~~~^~~~~ ... This was reported upstream [1]. Work around this by using SCM_DEBUG_TYPING_STRICTNESS == 0 instead of the default SCM_DEBUG_TYPING_STRICTNESS == 1. Tested on x86_64-linux. Approved-By: Tom Tromey <tom@tromey.com> PR guile/30767 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30767 [1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=65333
2024-10-19[gdb/symtab] Skip local variables in cooked indexTom de Vries3-7/+66
Consider test-case gdb.dwarf2/local-var.exp. The corresponding source contains a function with a local variable: ... program test logical :: local_var local_var = .TRUE. end ... Currently, the local variable shows up in the cooked index: ... [2] ((cooked_index_entry *) 0xfffec40063b0) name: local_var canonical: local_var qualified: local_var DWARF tag: DW_TAG_variable flags: 0x2 [IS_STATIC] DIE offset: 0xa3 parent: ((cooked_index_entry *) 0xfffec4006380) [test] ... making the cooked index larger than necessary. Fix this by skipping it in cooked_indexer::index_dies. Tested on aarch64-linux. PR symtab/32276 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32276
2024-10-18Require a command argument in gdb.execute_miTom Tromey2-0/+11
Hannes pointed out that gdb.execute_mi() will crash. This patch fixes the bug. Reviewed-By: Guinevere Larsen <guinevere@redhat.com>
2024-10-18[gdb] Handle bad alloc handling in gdb_bfd_openTom de Vries1-7/+8
Say we simulate a bad alloc in gdb_bfd_init_data: ... + { + static bool throw_bad_alloc = true; + if (throw_bad_alloc) + { + throw_bad_alloc = false; + + va_list dummy; + throw gdb_quit_bad_alloc (gdb_exception_quit ("bad alloc", dummy)); + } + } gdata = new gdb_bfd_data (abfd, st); ... That works out fine for doing "file a.out" once: ... $ gdb -q -batch -ex "file a.out" bad alloc $ ... but doing so twice get us: ... $ gdb -q -batch -ex "file a.out" -ex "file a.out" bad alloc Fatal signal: Segmentation fault ----- Backtrace ----- 0x5183f7 gdb_internal_backtrace_1 /home/vries/gdb/src/gdb/bt-utils.c:121 0x5183f7 _Z22gdb_internal_backtracev /home/vries/gdb/src/gdb/bt-utils.c:167 0x62329b handle_fatal_signal /home/vries/gdb/src/gdb/event-top.c:917 0x6233ef handle_sigsegv /home/vries/gdb/src/gdb/event-top.c:990 0xfffeffba483f ??? 0x65554c eq_bfd /home/vries/gdb/src/gdb/gdb_bfd.c:231 0xeaca77 htab_find_with_hash /home/vries/gdb/src/libiberty/hashtab.c:597 0x657487 _Z12gdb_bfd_openPKcS0_ib /home/vries/gdb/src/gdb/gdb_bfd.c:580 0x6272d7 _Z16exec_file_attachPKci /home/vries/gdb/src/gdb/exec.c:451 0x627e67 exec_file_command /home/vries/gdb/src/gdb/exec.c:550 0x627f23 file_command /home/vries/gdb/src/gdb/exec.c:565 Segmentation fault (core dumped) $ ... The problem is in gdb_bfd_open, where we insert abfd into gdb_bfd_cache: ... if (bfd_sharing) { slot = htab_find_slot_with_hash (gdb_bfd_cache, &search, hash, INSERT); gdb_assert (!*slot); *slot = abfd; } gdb_bfd_init_data (abfd, &st); ... while the bad alloc means that gdb_bfd_init_data is interrupted and abfd is not properly initialized. Fix this by reversing the order, inserting abfd into gdb_bfd_cache only after a successful call to gdb_bfd_init_data, such that we get: ... $ gdb -q -batch -ex "file a.out" -ex "file a.out" bad alloc $ ... Tested on aarch64-linux. Approved-By: Tom Tromey <tom@tromey.com>
generated by cgit v1.1 at 2025-09-20 09:57:09 +0000