summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2024-01-26x86/APX: TILE{RELEASE,ZERO} have no EVEX encodingsJan Beulich
Re-using the entire VEX decode hierarchy for the respective major opcode has led to those two also being decoded as-if valid. Follow the earlier USE_X86_64_EVEX_{PFX,W}_TABLE approach to avoid this happening.
2024-01-26x86/APX: no need to have decode go through x86_64_table[]Jan Beulich
As suggested during review already, all such entries have their first slot as Bad_Opcode, so by adding two more enumerators we can avoid doing that decode step altogether.
2024-01-26x86: make "-msyntax=intel -mnaked-reg" match ".intel_syntax noprefix"Jan Beulich
Adjustments made for the directive (by set_intel_syntax()) need also making for the command line option. Break out respective code into a new helper function, to also be invoked during command line processing. Further also set register_prefix when processing -mnaked-reg.
2024-01-26x86/APX: optimize MOVBEJan Beulich
With identical source and destination it can be covered by the NDD-to- legacy conversion logic as well, even if in this case the original insn doesn't use an NDD encoding. The size savings are even better here, for the replacement (BSWAP) not having a ModR/M byte.
2024-01-26LoongArch: Fix a bug of getting relocation typemengqinggang
The old code works because R_LARCH_RELAX has no symbol index. It causes '(rel + 1)->r_info == R_LARCH_RELAX' is 1 and ELFNN_R_TYPE (1) is 1.
2024-01-26LoongArch: gas: Add support for s9 registermengqinggang
In LoongArch ABI, r22 register can be used as frame pointer or static register(s9). Link: https://github.com/loongson/la-abi-specs/blob/release/lapcs.adoc#general-purpose-registers
2024-01-26LoongArch: ld: Add support for TLS LE symbol with addendmengqinggang
Add support for TLS LE symbol with addend, such as: lu12i.w $t0, %le_hi20(a + 0x8) ori $t0, $t0, %le_lo12(a + 0x8)
2024-01-26Assertion failure dumping .eh_frame_hdrAlan Modra
dwarf.c can hit "Assertion '(start) <= (end)' failed" on truncated sections, due to get_encoded_eh_value wrongly returning a full count for truncated words. * dwarf.c (get_encoded_eh_value): Return zero for truncated words.
2024-01-26Automatic date update in version.inGDB Administrator
2024-01-25gdb: remove get_gdb_program_nameSimon Marchi
Nothing uses it. Change-Id: I7a3fbf38e290a5147fbcbf175bc34f01dfb335c7
2024-01-25elf: Add is_standard_elfH.J. Lu
PR ld/31289 tests failed for fr30-elf, frv-elf, ft32-elf, iq2000-elf, mn10200-elf, ms1-elf and msp430-elf targets: FAIL: ld-elf/fatal-warnings-2a FAIL: ld-elf/fatal-warnings-2b FAIL: ld-elf/fatal-warnings-3a FAIL: ld-elf/fatal-warnings-3b FAIL: ld-elf/fatal-warnings-4a FAIL: ld-elf/fatal-warnings-4b even though PR ld/31289 targets xfail for [is_generic] targets. These targets not only don't use the generic_link_hash_table linker, but also don't use the standard ELF emulation. Add is_standard_elf for ELF targets which use the standard ELF emulation and replace [is_generic] with ![is_standard_elf] in PR ld/31289 tests. binutils/ PR ld/31289 * testsuite/lib/binutils-common.exp (is_standard_elf): New. ld/ PR ld/31289 * testsuite/lib/binutils-common.exp (is_generic): Return 1 for fr30-*-*, frv-*-elf, ft32-*-*, iq2000-*-*, mn10200-*-*, moxie-*-moxiebox*, msp430-*-* and mt-*-*. * testsuite/ld-elf/fatal-warnings-2a.d: Replace [is_generic] with ![is_standard_elf]. * testsuite/ld-elf/fatal-warnings-2b.d: Likewise. * testsuite/ld-elf/fatal-warnings-3a.d: Likewise. * testsuite/ld-elf/fatal-warnings-3b.d: Likewise. * testsuite/ld-elf/fatal-warnings-4a.d: Likewise. * testsuite/ld-elf/fatal-warnings-4b.d: Likewise.
2024-01-25ld: Always call output_unknown_cmdline_warningH.J. Lu
Call output_unknown_cmdline_warning if there are no input files so that $ ld -z bad-option reports ld: warning: -z bad-option ignored ld: no input files instead of ld: no input files PR ld/31289 * ldmain.c (main): Call output_unknown_cmdline_warning if there are no input files.
2024-01-25[gdb/testsuite] Fix regexp in vgdb_startTom de Vries
On Fedora 39 aarch64 I run into: ... (gdb) target remote | vgdb --wait=2 --max-invoke-ms=2500 --pid=2114437^M Remote debugging using | vgdb --wait=2 --max-invoke-ms=2500 --pid=2114437^M relaying data between gdb and process 2114437^M warning: remote target does not support file transfer, \ attempting to access files from local filesystem.^M Reading symbols from /lib/ld-linux-aarch64.so.1...^M _start () at ../sysdeps/aarch64/dl-start.S:22^M warning: 22 ../sysdeps/aarch64/dl-start.S: No such file or directory^M (gdb) FAIL: gdb.base/valgrind-infcall.exp: target remote for vgdb ... For contrast, on openSUSE Leap 15.4 x86_64 I have: ... (gdb) target remote | vgdb --wait=2 --max-invoke-ms=2500 --pid=18797^M Remote debugging using | vgdb --wait=2 --max-invoke-ms=2500 --pid=18797^M relaying data between gdb and process 18797^M warning: remote target does not support file transfer, \ attempting to access files from local filesystem.^M Reading symbols from /lib64/ld-linux-x86-64.so.2...^M (No debugging symbols found in /lib64/ld-linux-x86-64.so.2)^M 0x0000000004002550 in _start () from /lib64/ld-linux-x86-64.so.2^M (gdb) PASS: gdb.base/valgrind-infcall.exp: target remote for vgdb ... The fail happens in vgdb_start because the regexp only matches the "in _start ()" variant, not the "_start () at": ... gdb_test "$vgdbcmd" " in \\.?_start .*" "target remote for vgdb" ... Which variant you get is determined by presence of debug info. Fix this by also matching the "_start () at" variant. Tested aarch64-linux and x86_64-linux. Approved-By: Tom Tromey <tom@tromey.com>
2024-01-25gas: Update NEWSAndrew Carlotti
Groups entries by architecture, and update AArch64 content.
2024-01-25[gdb/build] Workaround gcc PR113599Tom de Vries
Since gcc commit d3f48f68227 ("c++: non-dependent .* operand folding [PR112427]"), with gdb we run into PR gcc/113599 [1], a wrong-code bug, as reported in PR build/31281. Work around this by flipping inherit order: ... -class thread_info : public refcounted_object, - public intrusive_list_node<thread_info> +class thread_info : public intrusive_list_node<thread_info>, + public refcounted_object ... An argument could be made that this isn't necessary, because this occurred in an unreleased gcc version. However, I think it could be useful when bisecting gcc for other problems in building gdb. Having this workaround means the bisect won't reintroduce the problem. Furthermore, the workaround is harmless. Tested on Fedora rawhide x86_64. Approved-By: Tom Tromey <tom@tromey.com> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31281 [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113599
2024-01-25[gdb/testsuite] Fix gdb.base/eh_return.expTom de Vries
On Fedora rawhide aarch64, I run into: ... (gdb) PASS: gdb.base/eh_return.exp: set breakpoint on address run ^M Starting program: eh_return ^M [Thread debugging using libthread_db enabled]^M Using host libthread_db library "/lib64/libthread_db.so.1".^M [Inferior 1 (process 1113051) exited normally]^M (gdb) FAIL: gdb.base/eh_return.exp: hit breakpoint (the program exited) ... This happens as follows: the test-case sets a breakpoint on the last instruction of function eh2: ... (gdb) break *0x00000000004103ec^M ... and expects to hit the breakpoint, but instead the "br x6" is taken: ... 0x00000000004103e0 <+176>: cbz x4, 0x4103ec <eh2+188>^M 0x00000000004103e4 <+180>: add sp, sp, x5^M 0x00000000004103e8 <+184>: br x6^M 0x00000000004103ec <+188>: ret^M ... In contrast, with fedora f39 we have: ... 0x00000000004103bc <+156>: ldp x2, x3, [sp, #48]^M 0x00000000004103c0 <+160>: ldp x29, x30, [sp, #16]^M 0x00000000004103c4 <+164>: add sp, sp, #0x50^M 0x00000000004103c8 <+168>: add sp, sp, x4^M 0x00000000004103cc <+172>: ret^M ... and the breakpoint is reached. Fix this by detecting that the breakpoint is not hit, and declaring the test unsupported. Tested on aarch64-linux. Approved-By: Tom Tromey <tom@tromey.com> PR testsuite/31291 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31291
2024-01-25Fix attach-twice.c testcase for AIX.Aditya Vidyadhar Kamath
Currently, in AIX attach-twice.exp testcase is untested due to the below error. gdb/testsuite/gdb.base/attach-twice.c:43:7: error: too few arguments to function 'ptrace' This is because in AIX ptrace has five arguments. This patch is a fix for the same such that this test case runs in AIX and other targets as well.
2024-01-25ld: Improve --fatal-warnings for unknown command-line optionsH.J. Lu
There are 2 problems with --fatal-warnings for unknown command-line options: 1. --fatal-warnings doesn't trigger an error for an unknown command-line option when --fatal-warnings is the last command-line option. 2. When --fatal-warnings triggers an error for an unknown command-line option, the message says that the unknown command-line option is ignored. This patch queues unknown command-line option warnings and outputs queued command-line option warnings after all command-line options have been processed so that --fatal-warnings can work for unknown command-line options regardless of the order of --fatal-warnings. When --fatal-warnings is used, the linker message is changed from ld: warning: -z bad-option ignored to ld: error: unsupported option: -z bad-option The above also applies to "-z dynamic-undefined-weak" when the known "-z dynamic-undefined-weak" option is ignored. PR ld/31289 * ldelf.c (ldelf_after_parse): Use queue_unknown_cmdline_warning to warn the ignored -z dynamic-undefined-weak option. * ldmain.c (main): Call output_unknown_cmdline_warnings after calling ldemul_after_parse. * ldmisc.c (CMDLINE_WARNING_SIZE): New. (cmdline_warning_list): Likewise. (cmdline_warning_head): Likewise. (cmdline_warning_tail): Likewise. (queue_unknown_cmdline_warning): Likewise. (output_unknown_cmdline_warnings): Likewise. * ldmisc.h (queue_unknown_cmdline_warning): Likewise. (output_unknown_cmdline_warnings): Likewise. * emultempl/elf.em (gld${EMULATION_NAME}_handle_option): Use queue_unknown_cmdline_warning to warn unknown -z option. * testsuite/ld-elf/fatal-warnings-1a.d: New file. * testsuite/ld-elf/fatal-warnings-1b.d: Likewise. * testsuite/ld-elf/fatal-warnings-2a.d: Likewise. * testsuite/ld-elf/fatal-warnings-2b.d: Likewise. * testsuite/ld-elf/fatal-warnings-3a.d: Likewise. * testsuite/ld-elf/fatal-warnings-3b.d: Likewise. * testsuite/ld-elf/fatal-warnings-4a.d: Likewise. * testsuite/ld-elf/fatal-warnings-4b.d: Likewise.
2024-01-25Automatic date update in version.inGDB Administrator
2024-01-25riscv64-pei uninitialised data writing relocsAlan Modra
Without this patch the r_offset field of struct external_reloc is uninitialised when using objcopy. * coff/riscv64.h (SWAP_IN_RELOC_OFFSET): Define. (SWAP_OUT_RELOC_OFFSET): Define.
2024-01-24Emit stopped event for DAP attach requestTom Tromey
In an earlier patch, I wrote: ... It also adds some machinery so that attach stops can be suppressed, which I think is the right thing to do. However, after some discussions here at AdaCore, I now believe this to be incorrect -- while DAP says that expected "continue" events should be suppressed, there is no corresponding language for expected "stop" events, and indeed "stop" events explicitly mention cases like "step". This patch arranges for the stop event to be emitted again.
2024-01-24Handle DW_AT_endianity on enumeration typesTom Tromey
A user found that gdb would not correctly print a field from an Ada record using the scalar storage order feature. We tracked this down to a combination of problems. First, GCC did not emit DW_AT_endianity on the enumeration type. DWARF does not specify this, but it is an obvious and harmless extension. This was fixed in GCC recently: https://gcc.gnu.org/pipermail/gcc-patches/2024-January/642347.html https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=5d8b60effc7268448a94fbbbad923ab6871252cd Second, GDB did not handle this attribute on enumeration types. This patch makes this change and adds a test case that will pass with the patched GCC. So far, the GCC patch isn't on the gcc-13 branch; but if it ever goes in, the test case in this patch can be updated to reflect that. Reviewed-By: Keith Seitz <keiths@redhat.com>
2024-01-24gdb/arm: Fix epilogue frame idThiago Jung Bauermann
arm_epilogue_frame_this_id has a comment saying that it fall backs to using the current PC if the function start address can't be identified, but it actually uses only the PC to make the frame id. This patch makes the code match the comment. Another hint that it's what is intended is that arm_prologue_this_id, a function almost identical to it, does that. The problem was found by code inspection. It fixes the following testsuite failures: FAIL: gdb.base/unwind-on-each-insn.exp: foo: instruction 9: check frame-id matches FAIL: gdb.reverse/solib-reverse.exp: reverse-next third shr1 FAIL: gdb.reverse/solib-reverse.exp: reverse-next second shr1 FAIL: gdb.reverse/solib-reverse.exp: reverse-next first shr1 FAIL: gdb.reverse/solib-reverse.exp: reverse-next generic FAIL: gdb.reverse/solib-reverse.exp: reverse-step into solib function one FAIL: gdb.reverse/solib-reverse.exp: reverse-step within solib function one FAIL: gdb.reverse/solib-reverse.exp: reverse-step into solib function two FAIL: gdb.reverse/solib-reverse.exp: reverse-step within solib function two Tested on arm-linux-gnueabi-hf.
2024-01-24gdb/testsuite: add test for backtracing for threaded inferiors from a corefileGuinevere Larsen
This patch is based on an out-of-tree patch that fedora has been carrying for a while. It tests if GDB is able to properly unwind a threaded program in the following situations: * regular threads * in a signal handler * in a signal handler executing on an alternate stack And the final frame can either be in a syscall or in an infinite loop. The test works by running the inferior until a crash to generate a corefile, or until right before the crash. Then applies a backtrace to all threads to see if any frame can't be identified, and the order of the threads in GDB. Finally, it goes thread by thread and tries to collect a large part of the backtrace, to confirm that everything is being unwound correctly. Co-Authored-By: Andrew Burgess <aburgess@redhat.com> Reviewed-By: Luis Machado <luis.machado@arm.com> Approved-By: Luis Machado <luis.machado@arm.com>
2024-01-24aarch64: Eliminate unused variable warnings with -DNDEBUGAndrew Carlotti
2024-01-24LoongArch: gas: Start a new frag after instructions that can be relaxedmengqinggang
For R_LARCH_TLS_{LE_HI20_R,LE_ADD_R,LD_PC_HI20,GD_PC_HI20, DESC_PC_HI20} relocations, start a new frag to get correct eh_frame Call Frame Information FDE DW_CFA_advance_loc info.
2024-01-24LoongArch: gas: Don't define LoongArch .alignmengqinggang
Gcc may generate "\t.align\t%d,54525952,4\n" before commit b20c7ee066cb7d952fa193972e8bc6362c6e4063. To write 54525952 (NOP) to object file, we call s_align_ptwo (-4). It result in alignment padding must be a multiple of 4 if .align has second parameter. Use default s_align_ptwo for .align.
2024-01-24Add myself as the KVX port maintainerPaul Iannetta
binutils/ChangeLog: * MAINTAINERS: Add myself as the KVX port maintainer.
2024-01-24Automatic date update in version.inGDB Administrator
2024-01-23aarch64: Update Architecture Extensions documentationAndrew Carlotti
Restructure the architecture extensions table, add a new table for architecture version dependencies, add missing architecture extensions, and improve some extension descriptions.
2024-01-23aarch64: Include +predres2 in -march=armv8.9-aAndrew Carlotti
This matches the dependencies in the architecture, in LLVM, and even in the original Binutils commit message that mistakenly included it only in armv9.4-a.
2024-01-23[PATCH v2] gas/NEWS, ld/NEWS: Announce LoongArch changes in 2.42Xi Ruoyao
2024-01-23gdb: fix "list ." related crashGuinevere Larsen
When a user attempts to use the "list ." command with an inferior that doesn't have debug symbols, GDB would crash. This was reported as PR gdb/31256. The crash would happen when attempting to get the current symtab_and_line for the stop location, because the symtab would return a null pointer and we'd attempt to dereference it to print the line. This commit fixes that by checking for an empty symtab and erroring out of the function if it happens. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31256 Approved-By: Tom Tromey <tom@tromey.com>
2024-01-23sim: sh: fix nested braces in struct initMike Frysinger
The op struct includes an array of strings, but doesn't use braces around that array when initializing. This causes a ton of warnings when using -Wmissing-braces. Add them to fix. The code this tool generates is the same before & after.
2024-01-22sim: riscv: Fix crash during instruction decodingJaydeep Patil
The match_never() function has been removed and thus step_once() crashes during instruction decoding. Fixed it by checking for null pointer before invoking function attached to match_func member of riscv_opcode structure
2024-01-22sim: frv: fix -Wincompatible-function-pointer-types warnings [PR sim/29752]Mike Frysinger
Some compilers warn in the frv code: sem.c:24343:41: error: incompatible function pointer types passing 'void (SIM_CPU *, UINT, UDI)' (aka 'void (struct _sim_cpu *, unsigned int, unsigned long)') to parameter of type 'void (*)(SIM_CPU *, UINT, DI)' (aka 'void (*)(struct _sim_cpu *, unsigned int, long)') [-Wincompatible-function-pointer-types] This is due to frvbf_h_acc40U_set using UDI for setting the new value, but using the common sim_queue_fn_di_write API which uses DI. The same size, but different sign. We could change frvbf_h_acc40U_set to take a DI without changing behavior in practice: the UDI is already passed via the queue function which accepts a DI, and frvbf_h_acc40U_set already casts the input to UDI before running any operations on it. However, these files are all generated, so manual changes here would be reverted. Seems like we can only change the register type for all APIs in the cpu definition. This builds cleanly, and passes sim unittests. Not sure if it's 100% the answer, but seems to be the best we have currently. Bug: https://sourceware.org/PR29752
2024-01-23Automatic date update in version.inGDB Administrator
2024-01-22gdb/testsuite: avoid duplicate test names in gdb.dwarf2/dw2-zero-range.exp ↵Simon Marchi
(and more) Tom Tromey noticed that dw2-zero-range.exp reported a duplicate test name. This happens because have_index calls get_index_type with the default test name. Refactor the test to avoid this, while cleaning a few other things, the most important being: - factor out the relocated and unrelocated parts in their own procs - give different names to generated binaries in different variations, such that all binaries are left in the test output directory (this makes it easier to debug a specific variation) Change-Id: I7cdf7a344834852fbb035d7e0434559eab6b1e94
2024-01-22Fix 31252 gprofng causes testsuite parallel jobs failVladimir Mezentsev
Before running our tests, we made a fake installation into ./tmpdir. This installation changes libopcodes.la in the build area. Gas testing may fail if gas and gprofng tests are run in parallel. I create a script to run gprofng. Inside this script, LD_LIBRARY_PATH, GPROFNG_SYSCONFDIR are set. putenv_libcollector_ld_misc() first uses $GPROFNG_PRELOAD_LIBDIRS to create directories for SP_COLLECTOR_LIBRARY_PATH ($SP_COLLECTOR_LIBRARY_PATH is used to set up LD_PRELOAD). gprofng/ChangeLog 2024-01-19 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> PR gprofng/31252 PR gprofng/30808 * src/envsets.cc (putenv_libcollector_ld_misc): Use $GPROFNG_PRELOAD_LIBDIRS first to build SP_COLLECTOR_LIBRARY_PATH. * testsuite/config/default.exp: Create a script to run gprofng. * testsuite/lib/display-lib.exp: Fix typo.
2024-01-22Updated Serbian translations for th bfd, gold and opcodes directoriesNick Clifton
2024-01-22binutils: Fix calloc argument order in srconv.cMark Wielaard
GCC 14 will warn about calling calloc with swapped size and count arguments. binutils/srconv.c: In function ‘nints’: binutils/srconv.c:598:36: error: ‘xcalloc’ sizes specified with ‘sizeof’ in the earlier argument and not in the later argument [-Werror=calloc-transposed-args] 598 | return (int *) (xcalloc (sizeof (int), x)); | ^~~ binutils/srconv.c:598:36: note: earlier argument should specify number of elements, later size of each element binutils/ * srconv.c (nints): Swap xcalloc arguments. (wr_du): Likewise. (wr_dus): Likewise.
2024-01-22binutils: Fix calloc argument order in coffgrok.cMark Wielaard
GCC 14 will warn about calling calloc with swapped size and count arguments. binutils-gdb/binutils/coffgrok.c: In function ‘do_sections_p1’: binutils-gdb/binutils/coffgrok.c:116:72: error: ‘xcalloc’ sizes specified with ‘sizeof’ in the earlier argument and not in the later argument [-Werror=calloc-transposed-args] 116 | struct coff_section *all = (struct coff_section *) (xcalloc (sizeof (struct coff_section), | ^~~~~~ binutils-gdb/binutils/coffgrok.c:116:72: note: earlier argument should specify number of elements, later size of each element binutils/ * coffgrok.c (empty_scope): Swap xcalloc arguments. (empty_symbol): Likewise. (do_lines): Likewise. (doit): Likewise. (coff_grok): Likewise.
2024-01-22libsframe: Fix calloc argument order in dump_sframe_headerMark Wielaard
GCC14 warns about the order of the arguments to calloc libsframe/sframe-dump.c: In function ‘dump_sframe_header’: libsframe/sframe-dump.c:70:39: warning: ‘calloc’ sizes specified with ‘sizeof’ in the earlier argument and not in the later argument [-Wcalloc-transposed-args] 70 | flags_str = (char*) calloc (sizeof (char), SFRAME_HEADER_FLAGS_STR_MAX_LEN); | ^~~~ libsframe/sframe-dump.c:70:39: note: earlier argument should specify number of elements, later size of each element Fix this by swapping the size and count arguments. libsframe/ * sframe-dump.c (dump_sframe_header): Swap arguments to calloc
2024-01-22opcodes: tic4x_disassemble swap xcalloc argumentsMark Wielaard
GCC 14 will detect when the size and count arguments of calloc are swapped. binutils-gdb/opcodes/tic4x-dis.c: In function ‘tic4x_disassemble’: binutils-gdb/opcodes/tic4x-dis.c:710:32: error: ‘xcalloc’ sizes specified with ‘sizeof’ in the earlier argument and not in the later argument [-Werror=calloc-transposed-args] 710 | optab = xcalloc (sizeof (tic4x_inst_t *), (1 << TIC4X_HASH_SIZE)); | ^~~~~~~~~~~~ binutils-gdb/opcodes/tic4x-dis.c:710:32: note: earlier argument should specify number of elements, later size of each element binutils-gdb/opcodes/tic4x-dis.c:712:40: error: ‘xcalloc’ sizes specified with ‘sizeof’ in the earlier argument and not in the later argument [-Werror=calloc-transposed-args] 712 | optab_special = xcalloc (sizeof (tic4x_inst_t *), TIC4X_SPESOP_SIZE); | ^~~~~~~~~~~~ binutils-gdb/opcodes/tic4x-dis.c:712:40: note: earlier argument should specify number of elements, later size of each element opcodes/ChangeLog: * /tic4x-dis.c (tic4x_disassemble): Swap size and count xcalloc arguments.
2024-01-22Handle EOF more gracefully in DAPTom Tromey
A user pointed out that gdb will print a Python exception when it gets an EOF in DAP mode. And, it turns out that an EOF like this also causes gdb not to exit. This is due to the refactoring that moved the JSON reader to its own thread -- previously this caused an exception to propagate and cause an exit, but now it just leaves the reader hung. This patch fixes these problems by arranging to handle EOF more gracefully. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31217
2024-01-22Fix handling of DW_OP_GNU_push_tls_addressTom Tromey
In one spot, DW_OP_GNU_push_tls_address is handled differently from DW_OP_form_tls_address. However, I think they should always be treated identically. Approved-by: Kevin Buettner <kevinb@redhat.com>
2024-01-22sim: Fix -Werror=shadow=local by changing mem to addr in sim_{read,write}Mark Wielaard
m32c/cpu.h defines mem as enum value, which causes GCC 14 to emit sim/m32c/gdb-if.c: In function ‘sim_read’: sim/m32c/gdb-if.c:162:33: error: declaration of ‘mem’ shadows a previous local [-Werror=shadow=local] 162 | sim_read (SIM_DESC sd, uint64_t mem, void *buf, uint64_t length) | ~~~~~~~~~^~~ In file included from ../../binutils-gdb/sim/m32c/gdb-if.c:38: sim/m32c/cpu.h:83:3: note: shadowed declaration is here 83 | mem, | ^~~ Fix this by renaming mem to addr in all sim_read and sim_write functions. Most already used addr instead of mem. In one file, sim/rx/gdb-if.c, this also meant renaming the local addr variable to vma.
2024-01-22sim: Fix some -Werror=shadow=compatible-local issues in aarch64/simulator.cMark Wielaard
With GCC 14 -Werror=shadow=compatible-local flags the reuse of single capital letters used in aarch64/cpustate.h enums 88 | expand_logical_immediate (uint32_t S, uint32_t R, uint32_t N) | ~~~~~~~~~^ In file included from ../../binutils-gdb/sim/aarch64/aarch64-sim.h:27, from ../../binutils-gdb/sim/aarch64/simulator.c:33: 217 | N = 1 << N_IDX | ^ sim/aarch64/simulator.c: In function ‘expand_logical_immediate’: sim/aarch64/simulator.c:88:60: error: declaration of ‘N’ shadows a previous local [-Werror=shadow=compatible-local] sim/aarch64/cpustate.h:217:3: note: shadowed declaration is here
2024-01-22sim: Fix cc -Werror=shadow=local in cr16/simops.cMark Wielaard
include/opcode/cr16.h defines cc as an enum value, which causes GCC 14 to warn sim/cr16/simops.c: In function ‘cond_stat’: sim/cr16/simops.c:138:26: error: declaration of ‘cc’ shadows a previous local [-Werror=shadow=local] 138 | static int cond_stat(int cc) | ~~~~^~ In file included from ../../binutils-gdb/sim/cr16/cr16-sim.h:26, from ../../binutils-gdb/sim/cr16/simops.c:39: sim/../include/opcode/cr16.h:149:3: note: shadowed declaration is here 149 | cc, | ^~ Fix this by renaming cc in cr16/simops.c to cond.
2024-01-22gdb/testsuite: relax filename restriction in some gdb.btrace testsGuinevere Larsen
The test gdb.btrace/tailcall.exp has multiple tests that include the filename in the output. When testing with gcc, only a relative path is printed, but when using clang, the full file path is printed instead. This makes most of those tests fail, with the exception of "record goto 4" which allows for more characters before the file name. The test gdb.btrace/recod_goto.exp suffers with the same issue This commit allows for text before the filename. However, instead of how the aforementioned "record goto 4", it uses a regexp that doesn't allow for newlines, just in case some off output happens. Approved-By: Tom Tromey <tom@tromey.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-07-10 09:33:14 +0000