aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2024-05-07gdb/arch: assert that X86_XSTATE_MPX is not set for x32Andrew Burgess1-2/+6
While rebasing this series[1] past this commit: commit 4bb20a6244b7091a9a7a2ae35dfbd7e8db27550a Date: Wed Mar 20 04:13:18 2024 -0700 gdbserver: Clear X86_XSTATE_MPX bits in xcr0 on x32 I worried that there could be other paths that might result in an xcr0 value which has X86_XSTATE_MPX set in x32 mode. As everyone eventually calls amd64_create_target_description to build their target description, I figured we could assert in here that if X86_XSTATE_MPX is set then we should not be an x32 target, this will uncover any other bugs in this area. I'm not currently able to build/run any x32 binaries, so I have no way to test this, but the author of commit 4bb20a6244b7091 did test this series with that assert in place and didn't see any problems. [1] https://inbox.sourceware.org/gdb-patches/cover.1714143669.git.aburgess@redhat.com Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31511 Approved-By: Felix Willgerodt <felix.willgerodt@intel.com>
2024-05-07gdbserver: convert have_ptrace_getregset to a triboolAndrew Burgess4-10/+10
Convert the have_ptrace_getregset global within gdbserver to a tribool. This brings the flag into alignment with the corresponding flag in GDB. The gdbserver have_ptrace_getregset variable is already used as a tribool, it just doesn't have the tribool type. In a future commit I plan to share more code between GDB and gdbserver, and having this variable be the same type in both code bases will make the sharing much easier. There should be no user visible changes after this commit. Approved-By: John Baldwin <jhb@FreeBSD.org> Reviewed-By: Felix Willgerodt <felix.willgerodt@intel.com>
2024-05-07gdbserver/ipa/x86: remove unneeded declarationsAndrew Burgess1-4/+0
Spotted some declarations in gdbserver/linux-amd64-ipa.cc that are no longer needed. These are: 1. 'init_registers_amd64_linux' - the comment claims this function is auto generated, but I don't believe that this is still the case. Also the function is not used in this file, 2. 'tdesc_amd64_linux' - this variable doesn't seem to exist any more, I suspect this was renamed to 'tdesc_amd64_linux_no_xml', but neither are used in this file, so lets remove the declaration. The amd64 in-process-agent still builds fine after this commit. There should be no user visible changes after this commit. Approved-By: Felix Willgerodt <felix.willgerodt@intel.com>
2024-05-07gdb.base/watchpoint-running.exp: Run sw watch tests even if no hw watchPedro Alves1-1/+1
The code in gdb.base/watchpoint-running.exp that is trying to skip testing with hardware watchpoints also skips testing with software watchpoints if hardware watchpoints aren't supported by the target. This fixes it. Change-Id: Iaed62ac827b32b4fd73b732ad81fa4a5aa5784ba
2024-05-07Remove gdb.base/watchpoint-running.exp leftoverPedro Alves1-2/+0
Remove accidentally leftover commented-out line from gdb.base/watchpoint-running.exp. Change-Id: Ie1c3b85997d2ca92a2159a539d24b02fd3c9e697
2024-05-07gdb/testsuite/lib/rocm: Fix with_rocm_gpu_lockLancelot SIX1-1/+1
A recent commit refactored with_rocm_gpu_lock: commit fbb0edfe60edf4ca01884151e6d9b1353aaa0a7e Date: Sat May 4 10:41:09 2024 +0200 [gdb/testsuite] Factor out proc with_lock Factor out proc with_lock from with_rocm_gpu_lock, and move required procs lock_file_acquire and lock_file_release to lib/gdb-utils.exp. This causes regressions in gdb.rocm/*.exp (as well as in downstream rocgdb). The issue can be reproduced in the following minimal test: load_lib rocm.exp set foo hello with_rocm_gpu_lock { verbose -logs $foo } The issue is that the body to execute under the lock is executed in the context of with_rocm_gpu_lock (uplevel 1 used in with_lock) instead of in the context of the "original" caller. This patch adjusted with_rocm_gpu_lock to account for the new extra frame in the call stack between the caller of with_rocm_gpu_lock and where the code execution is triggered. Approved-By: Tom de Vries <tdevries@suse.de> Change-Id: I79ce2c9615012215867ed5bb60144abe7dce28fe
2024-05-07LoongArch: Fix ld test failures caused by using instruction aliasesLulu Cai1-1/+1
Different versions of objdump may take different forms of output for instructions. Use -M no-aliases to avoid the failure of ld test cases caused by objdump using aliases.
2024-05-07Automatic date update in version.inGDB Administrator1-1/+1
2024-05-06Fix build issues with mingw toolchainBernd Edlinger5-0/+6
With a x86_64-pc-mingw32 toolchain there is a build issue whether or not the --disable-threading option is used. The problem happens because _WIN32_WINNT is defined to 0x501 before #include <mutex> which makes the compilation abort due to missing support for __gthread_cond_t in std_mutex.h, which is conditional on _WIN32_WINNT >= 0x600. Fix the case when --disable-threading is used, by only including <mutex> in gdb/complaints.c when STD_CXX_THREAD is defined. Additionally make the configure script try to #include <mutex> to automatically select --disable-threading when the header file is not able to compile. Approved-By: Tom Tromey <tom@tromey.com>
2024-05-06[gdb/testsuite] Handle ptrace operation not permitted in can_spawn_for_attachTom de Vries9-39/+135
When running the testsuite on a system with kernel.yama.ptrace_scope set to 1, we run into attach failures. Fix this by recognizing "ptrace: Operation not permitted" in can_spawn_for_attach. Tested on aarch64-linux and x86_64-linux. Approved-By: Pedro Alves <pedro@palves.net>
2024-05-06[gdb/exp] Redo cast handling for indirectionTom de Vries2-6/+4
In commit ed8fd0a342f ("[gdb/exp] Fix cast handling for indirection"), I introduced the behaviour that even though we have: ... (gdb) p *a_loc () 'a_loc' has unknown return type; cast the call to its declared return type ... we get: ... (gdb) p (char)*a_loc () $1 = 97 'a' ... In other words, the unknown return type of a_loc is inferred from the cast, effectually evaluating: ... (gdb) p (char)*(char *)a_loc () ... This is convient for the case that errno is defined as: ... #define errno (*__errno_location ()) ... and the return type of __errno_location is unknown but the macro definition is known, such that we can use: ... (gdb) p (int)errno ... instead of ... (gdb) p *(int *)__errno_location () ... However, as Pedro has pointed out in post-commit review [1], this makes it harder to reason about the semantics of an expression. For instance, this: ... (gdb) p (long long)*a_loc ()" ... would be evaluated without debug info as: ... (gdb) p (long long)*(long long *)a_loc ()" ... but with debug info as: ... (gdb) p (long long)*(char *)a_loc ()" ... Fix this by instead simply erroring out for this case: ... (gdb) p (char)*a_loc () 'a_loc' has unknown return type; cast the call to its declared return type ... Tested on x86_64-linux. Approved-By: Pedro Alves <pedro@palves.net> [1] https://sourceware.org/pipermail/gdb-patches/2024-May/208821.html
2024-05-06x86: Drop using extension_opcode to encode vvvv registerCui, Lili5-121/+134
gas/ChangeLog: * config/tc-i386.c (build_modrm_byte): Dropped the use of extension_opcode to encode the vvvv register. * testsuite/gas/i386/x86-64-sse2avx.d: Added new testcases. * testsuite/gas/i386/x86-64-sse2avx.s: Diito. opcodes/ChangeLog: * i386-opc.tbl: Added DstVVVV to some extension_opcode instructions. * i386-tbl.h: Regenerated.
2024-05-06x86: Drop SwapSourcesCui, Lili4-327/+330
gas/ChangeLog: * config/tc-i386.c (build_modrm_byte): Dropped the use of SWAP_SOURCES to encode the vvvv register. opcodes/ChangeLog: * i386-opc.h (SWAP_SOURCES): Dropped. (NO_DEFAULT_MASK): Adjusted the value. (ADDR_PREFIX_OP_REG): Ditto. (DISTINCT_DEST): Ditto. (IMPLICIT_STACK_OP): Ditto. (VexVVVV_SRC2): New. * i386-opc.tbl: Dropped SwapSources and replaced its VexVVVV with Src1VVVV. * i386-tbl.h: Regenerated.
2024-05-06x86: Use vexvvvv as the switch state to encode the vvvv registerCui, Lili4-670/+674
Use vexvvvv as the switch state, and replace VexVVVV with Src1VVVV. Src1VVVV means using VEX.vvvv encodes the first source register operand. The old logic did not check vexvvvv first, which made the logic here very complicated. gas/ChangeLog: * config/tc-i386.c (optimize_encoding): Replaced 1 with Src1VVVV. (build_modrm_byte): Used vexvvvv to encode the vvvv register. (s_insn): Replaced 1 with Src1VVVV. opcodes/ChangeLog: * i386-opc.h (VexVVVV_DST): Adjusted the value. (Src1VVVV): New. * i386-opc.tbl: Replaced part VexVVVV with Src1VVVV. * i386-tbl.h: Regenerated.
2024-05-06Automatic date update in version.inGDB Administrator1-1/+1
2024-05-05Automatic date update in version.inGDB Administrator1-1/+1
2024-05-04Fix heap-use-after-free in index-cached with --disable-threadingHannes Domani1-1/+1
If threads are disabled, either by --disable-threading explicitely, or by missing std::thread support, you get the following ASAN error when loading symbols: ==7310==ERROR: AddressSanitizer: heap-use-after-free on address 0x614000002128 at pc 0x00000098794a bp 0x7ffe37e6af70 sp 0x7ffe37e6af68 READ of size 1 at 0x614000002128 thread T0 #0 0x987949 in index_cache_store_context::store() const ../../gdb/dwarf2/index-cache.c:163 #1 0x943467 in cooked_index_worker::write_to_cache(cooked_index const*, deferred_warnings*) const ../../gdb/dwarf2/cooked-index.c:601 #2 0x1705e39 in std::function<void ()>::operator()() const /gcc/9/include/c++/9.2.0/bits/std_function.h:690 #3 0x1705e39 in gdb::task_group::impl::~impl() ../../gdbsupport/task-group.cc:38 0x614000002128 is located 232 bytes inside of 408-byte region [0x614000002040,0x6140000021d8) freed by thread T0 here: #0 0x7fd75ccf8ea5 in operator delete(void*, unsigned long) ../../.././libsanitizer/asan/asan_new_delete.cc:177 #1 0x9462e5 in cooked_index::index_for_writing() ../../gdb/dwarf2/cooked-index.h:689 #2 0x9462e5 in operator() ../../gdb/dwarf2/cooked-index.c:657 #3 0x9462e5 in _M_invoke /gcc/9/include/c++/9.2.0/bits/std_function.h:300 It's happening because cooked_index_worker::wait always returns true in this case, which tells cooked_index::wait it can delete the m_state cooked_index_worker member, but cooked_index_worker::write_to_cache tries to access it immediately afterwards. Fixed by making cooked_index_worker::wait only return true if desired_state is CACHE_DONE, same as if threading was enabled, so m_state will not be prematurely deleted. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31694 Approved-By: Tom Tromey <tom@tromey.com>
2024-05-04Remove dwarf2_per_objfile::adjustTom Tromey2-15/+0
All the calls to dwarf2_per_objfile::adjust have been removed, so we can remove this function entirely. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31261
2024-05-04Remove call to dwarf2_per_objfile::adjust from read_attribute_valueTom Tromey1-1/+0
Currently, read_attribute_value calls dwarf2_per_objfile::adjust on any address. This seems wrong, because the address may not even be in the text section. Luckily, this call is also not needed, because read_func_scope calls 'relocate', which does the same work.
2024-05-04Remove call to dwarf2_per_objfile::adjust from read_call_site_scopeTom Tromey1-5/+2
read_call_site_scope does not need to call 'adjust', because in general the call site is not a symbol address, but rather just the address of some particular call.
2024-05-04Remove more calls to dwarf2_per_objfile::adjustTom Tromey1-18/+8
As with the previous patch, this patch removes some calls to dwarf2_per_objfile::adjust. These calls are not needed by the cooked indexer, as it does not create symbols or look up symbols by address. The call in dwarf2_ranges_read is similarly not needed, as it is only used to update an addrmap; and in any case I believe this particular call is only reached by the indexer.
2024-05-04Remove call to dwarf2_per_objfile::adjust from ranges readersTom Tromey2-4/+0
dwarf2_per_objfile::adjust applies gdbarch_adjust_dwarf2_addr to an address, leaving the result unrelocated. However, this adjustment is only needed for text-section symbols -- it isn't needed for any sort of address mapping. Therefore, these calls can be removed from read_addrmap_from_aranges and create_addrmap_from_gdb_index. Approved-By: Andrew Burgess <aburgess@redhat.com>
2024-05-04bus error with fuzzed archive elementAlan Modra1-1/+12
* libbfd.c (bfd_mmap_local): Sanity check rsize against actual file offset and size, not an archive element offset and size.
2024-05-04[gdb/testsuite] Use unique portnum in parallel testing (check//% case)Tom de Vries2-2/+11
Make target check//% is the gdb variant of a similar gcc make target [1]. When running tests using check//%: ... $ cd build/gdb $ make check//unix/{-fPIE/-pie,-fno-PIE/-no-pie} -j2 TESTS=gdb.server/*.exp ... we get: ... $ cat build/gdb/testsuite.unix.-fPIE.-pie/cache/portnum 2427 $ cat build/gdb/testsuite.unix.-fno-PIE.-no-pie/cache/portnum 2423 ... The problem is that there are two portnum files used in parallel. Fix this by: - creating a common lockdir build/gdb/testsuite.lockdir for make target check//%, - passing this down to the runtests invocations using variable GDB_LOCK_DIR, and - using GDB_LOCK_DIR in lock_dir. Tested on aarch64-linux. Approved-By: Tom Tromey <tom@tromey.com> PR testsuite/31632 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31632 [1] https://gcc.gnu.org/install/test.html
2024-05-04[gdb/testsuite] Use unique portnum in parallel testingTom de Vries1-9/+38
When instrumenting get_portnum using: ... puts "PORTNUM: $res" ... and running: ... $ cd build/gdb $ make check-parallel -j2 TESTS=gdb.server/*.exp ... we run into: ... Running gdb.server/abspath.exp ... PORTNUM: 2345 ... and: ... Running gdb.server/bkpt-other-inferior.exp ... PORTNUM: 2345 ... This is because the test-cases are run in independent runtest invocations. Fix this by handling the parallel case in get_portnum using: - a file $objdir/cache/portnum to keep the portnum variable, and - a file $objdir/cache/portnum.lock to serialize access to it. Tested on aarch64-linux. Approved-By: Tom Tromey <tom@tromey.com>
2024-05-04[gdb/testsuite] Move gpu-parallel.lock to cache dirTom de Vries1-1/+1
The lock directory returned by lock_dir is currently $objdir. It seems possible to leave a stale lock file that blocks progress in a following run. Fix this by using a directory that is guaranteed to be initially empty when using GDB_PARALLEL, like temp or cache. In gdb/testsuite/README I found: ... cache in particular is used to share data across invocations of runtest ... which seems appropriate, so let's use cache for this. Tested on aarch64-linux. Approved-By: Tom Tromey <tom@tromey.com>
2024-05-04[gdb/testsuite] Factor out proc lock_dirTom de Vries2-1/+8
In lib/rocm.exp we have: ... set gpu_lock_filename $objdir/gpu-parallel.lock ... This decides both the lock file name and directory. Factor out a new proc lock_dir that decides on the directory, leaving just: ... set gpu_lock_filename gpu-parallel.lock ... Tested on aarch64-linux. Approved-By: Tom Tromey <tom@tromey.com>
2024-05-04[gdb/testsuite] Factor out proc with_lockTom de Vries2-54/+60
Factor out proc with_lock from with_rocm_gpu_lock, and move required procs lock_file_acquire and lock_file_release to lib/gdb-utils.exp. Tested on aarch64-linux. Approved-By: Tom Tromey <tom@tromey.com>
2024-05-04[gdb/testsuite] Make portnum a persistent globalTom de Vries1-1/+1
When instrumenting get_portnum using: ... puts "PORTNUM: $res" ... and running: ... $ cd build/gdb $ make check TESTS=gdb.server/*.exp ... we get: ... Running gdb.server/target-exec-file.exp ... PORTNUM: 2345 Running gdb.server/stop-reply-no-thread-multi.exp ... PORTNUM: 2345 PORTNUM: 2346 PORTNUM: 2347 PORTNUM: 2348 PORTNUM: 2349 PORTNUM: 2350 ... So, while get_portnum does return increasing numbers in a single test-case, it restarts at each test-case. This is a regression since the introduction of persistent globals. Fix this by using "gdb_persistent_global portnum", such that we get: ... Running gdb.server/target-exec-file.exp ... PORTNUM: 2345 Running gdb.server/stop-reply-no-thread-multi.exp ... PORTNUM: 2346 PORTNUM: 2347 PORTNUM: 2348 PORTNUM: 2349 PORTNUM: 2350 PORTNUM: 2351 ... Tested on aarch64-linux. Approved-By: Tom Tromey <tom@tromey.com>
2024-05-04[gdb/testsuite] Factor out proc get_portnumTom de Vries1-11/+29
In gdbserver_start, we have some code that determines what port number to use: ... # Port id -- either specified in baseboard file, or managed here. if [target_info exists gdb,socketport] { set portnum [target_info gdb,socketport] } else { # Bump the port number to avoid conflicts with hung ports. incr portnum } ... Factor this out into a new proc get_portnum. Tested on aarch64-linux. Approved-By: Tom Tromey <tom@tromey.com>
2024-05-04Automatic date update in version.inGDB Administrator1-1/+1
2024-05-03Adjust gdb_continue_to_end for WindowsPedro Alves1-0/+15
On Cygwin, supposely single-threaded programs are always multi-threaded, due to the extra threads spawned by the Cygwin runtime. Because of that, any gdb_continue_to_end call that doesn't specify "allow_extra" fails, like so: (gdb) PASS: gdb.base/langs.exp: show language at main continue Continuing. [Thread 16140.0x1fbc exited with code 0] [Thread 16140.0x2458 exited with code 0] [Thread 16140.0x3494 exited with code 0] [Inferior 1 (process 16140) exited normally] (gdb) FAIL: gdb.base/langs.exp: continue until exit at first session (the program exited) Similarly, with this simple program compiled with MinGW: $ cat ~/sleeper.c #include <windows.h> int main () { Sleep (2000); return 0; } and with a MinGW GDB, I see: (gdb) start ... (gdb) info threads Id Target Id Frame * 1 Thread 15292.0x3850 main () at /home/alves/sleeper.c:5 2 Thread 15292.0x3048 0x00007ff9630d2fb7 in ntdll!ZwWaitForWorkViaWorkerFactory () from C:\Windows\SYSTEM32\ntdll.dll (gdb) c Continuing. [Thread 15292.0x3850 exited with code 0] [Inferior 1 (process 15292) exited normally] (gdb) This commit adjusts gdb_continue_to_end to expect the thread exited messages, on Cygwin and MinGW. Change-Id: I5e410a7252c11cd9ecea632f1e00c2a7fcd69098 Approved-By: Andrew Burgess <aburgess@redhat.com>
2024-05-03[gdb/build] Fix gdbserver/linux-aarch64-low.cc buildMark Wielaard1-1/+1
Commit 0ee25f97d21e ("Fix regression on aarch64-linux gdbserver") removed the last use of i in gdbserver/linux-aarch64-low.cc (aarch64_target::low_stopped_data_address). Breaking the build on aarch64 with: gdbserver/linux-aarch64-low.cc: In member function ?virtual CORE_ADDR aarch64_target::low_stopped_data_address()?: gdbserver/linux-aarch64-low.cc:557:12: error: unused variable ?i? [-Werror=unused-variable] 557 | int pid, i; | ^ cc1plus: all warnings being treated as errors Fix this by removing the variable i completely. Fixes: 0ee25f97d21e ("Fix regression on aarch64-linux gdbserver")
2024-05-03[gdb/testsuite] Use save_vars to restore GDBFLAGSTom de Vries25-187/+165
There's a pattern of using: ... set saved_gdbflags $GDBFLAGS set GDBFLAGS "$GDBFLAGS ..." <do something with GDBFLAGS> set GDBFLAGS $saved_gdbflags ... Simplify this by using save_vars: ... save_vars { GDBFLAGS } { set GDBFLAGS "$GDBFLAGS ..." <do something with GDBFLAGS> } ... Tested on x86_64-linux.
2024-05-03[gdb/testsuite] Remove superfluous -quiet and -ex set width/height 0Tom de Vries9-16/+5
INTERNAL_GDBFLAGS contains: - -quiet - -iex "set width 0" - -iex "set height 0" There are test-cases that add these once more. Clean this up. Tested on x86_64-linux. PR testsuite/31649 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31649
2024-05-03[gdb/testsuite] Update INTERNAL_GDBFLAGS exampleTom de Vries1-1/+1
In commit 31c50280179 ("[gdb/testsuite] Add -q to INTERNAL_GDBFLAGS") I added -q to the INTERNAL_GDBFLAGS, but I forgot to update the INTERNAL_GDBFLAGS example in gdb/testsuite/README. Fix this by adding the -q there as well.
2024-05-03[gdb/exp] Fix cast handling for indirectionTom de Vries3-3/+76
Consider a test-case compiled without debug info, containing: ... char a = 'a'; char * a_loc (void) { return &a; } ... We get: ... (gdb) p (char)*a_loc () Cannot access memory at address 0x10 ... There's a bug in unop_ind_base_operation::evaluate that evaluates "(char)*a_loc ()" the same as: ... (gdb) p (char)*(char)a_loc () Cannot access memory at address 0x10 ... Fix this by instead evaluating it the same as: ... (gdb) p (char)*(char *)a_loc () $1 = 97 'a' ... Tested on x86_64-linux. PR exp/31693 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31693
2024-05-03x86: tidy <sse*> templatesJan Beulich1-20/+20
Some of them no longer need a separate vvvv attribute, thus allowing them to be simplified. For <aes> the situation is slightly different: None of the remaining uses make use of vvvv anymore.
2024-05-03x86/APX: further extend SSE2AVX coverageJan Beulich5-230/+1235
Since {vex}/{vex3} are respected on legacy mnemonics when -msse2avx is in use, {evex} should be respected, too. So far this is the case only for insns where eGPR-s can come into play. Extend coverage to insns with only %xmm register and possibly immediate operands.
2024-05-03x86/APX: extend SSE2AVX coverageJan Beulich9-656/+2600
Legacy encoded SIMD insns are converted to AVX ones in that mode. When eGPR-s are in use, i.e. with APX, convert to AVX10 insns (where available; there are quite a few which can't be converted). Note that LDDQU is represented as VMOVDQU32 (and the prior use of the sse3 template there needs dropping, to get the order right). Note further that in a few cases, due to the use of templates, AVX512VL is used when AVX512F would suffice. Since AVX10 is the main reference, this shouldn't be too much of a problem.
2024-05-03x86: zap value-less Disp8MemShift from non-EVEX templatesJan Beulich1-7/+19
In order to allow to continue to use templatized SSE2AVX templates when enhancing those to also cover eGPR usage, Disp8MemShift wants using to deviate from what general template attributes supply. That requires using Disp8MemShift in a way also affecting non-EVEX templates, yet having this attribute set would so far implicitly mean EVEX encoding. Recognize the case and instead zap the attribute if no other attribute indicates EVEX encoding. No change in generated tables.
2024-05-03Automatic date update in version.inGDB Administrator1-1/+1
2024-05-02Fix regression on aarch64-linux gdbserverTom Tromey5-158/+126
Commit 9a03f218 ("Fix gdb.base/watchpoint-unaligned.exp on aarch64") fixed a watchpoint bug in gdb -- but did not touch the corresponding code in gdbserver. This patch moves the gdb code into gdb/nat, so that it can be shared with gdbserver, and then changes gdbserver to use it, fixing the bug. This is yet another case where having a single back end would prevent bugs. I tested this using the AdaCore internal gdb testsuite. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29423 Approved-By: Luis Machado <luis.machado@arm.com>
2024-05-02PR31692, objdump fails .debug_info size checkAlan Modra1-4/+4
PR 31692 * objdump.c (load_specific_debug_section): Replace bfd_get_size check with bfd_section_size_insane. Call free_debug_section after printing error messages. Set section->start NULL when freeing.
2024-05-02[gdb/symtab] Work around PR gas/29517, dwarf2 caseTom de Vries4-3/+35
In commit 1d45d90934b ("[gdb/symtab] Work around PR gas/29517") we added a workaround for PR gas/29517. The problem is present in gas version 2.39, and fixed in 2.40, so the workaround is only active for gas version == 2.39. However, the problem in gas is only fixed for dwarf version >= 3, which supports DW_TAG_unspecified_type. Fix this by also activating the workaround for dwarf version == 2. Tested on x86_64-linux. Approved-by: Kevin Buettner <kevinb@redhat.com> PR symtab/31689 https://sourceware.org/bugzilla/show_bug.cgi?id=31689
2024-05-02Automatic date update in version.inGDB Administrator1-1/+1
2024-05-01[gdb/testsuite] Fix stray file in get_compiler_infoTom de Vries1-1/+1
When running test-case gdb.dwarf2/gdb-index-nodebug.exp with host board local-remote-host and target board remote-gdbserver-on-localhost, I get: ... $ ls build/gdb/testsuite cache compiler.i config.log config.status gdb.log gdb.sum lib Makefile outputs site.bak site.exp temp ... The file compiler.i is there because get_compiler_info uses: ... set ppout "$outdir/compiler.i" ... The file is a temporary, and as such belongs in a temp dir. Fix this by using standard_temp_file, moving the file to build/gdb/testsuite/temp/<pid>/compiler.i. Tested on x86_64-linux.
2024-05-01[gdb/testsuite] Fix stray file in gdb.dwarf2/gdb-index-nodebug.expTom de Vries1-2/+2
After running test-case gdb.dwarf2/gdb-index-nodebug.exp I have: ... $ ls build/gdb/testsuite cache config.status gdb.log lib outputs site.exp config.log gdb-index-nodebug.gdb-index gdb.sum Makefile site.bak temp ... The file gdb-index-nodebug.gdb-index doesn't belong there. It happens to be there because we do: ... set index_file ${testfile}.gdb-index set cmd "save gdb-index [file dirname ${index_file}]" ... which results in: ... (gdb) save gdb-index . ... The intention was possibly to use $binfile instead of $testfile, but using that wouldn't work for remote host. Fix this by using host_standard_output_file. Tested on x86_64-linux.
2024-05-01Automatic date update in version.inGDB Administrator1-1/+1
2024-04-30RISC-V: PR29823, defined the missing elf_backend_obj_attrs_handle_unknown.Nelson Chu1-0/+13
bfd/ PR 29823 * elfnn-riscv.c (riscv_elf_obj_attrs_handle_unknown): New function. (elf_backend_obj_attrs_handle_unknown): Defined to riscv_elf_obj_attrs_handle_unknown.
generated by cgit v1.1 at 2024-11-26 22:21:01 +0000