aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2025-04-29[gdb/testsuite] Fix gdb.base/ptype.exp with gcc 15Tom de Vries1-4/+4
With test-case gdb.base/ptype.exp and gcc 15 I run into: ... (gdb) ptype old_fptr^M type = double (*)(void)^M (gdb) FAIL: $exp: ptype old_fptr (compiler doesn't emit unprototyped types) ... Since C23, non-prototype function declarations are no longer supported, so "double (*old_fptr) ()" is interpreted as "double (*old_fptr) (void)". We could try to fix this by detecting the language dialect used, and accepting the output in that case, but that feels fragile. We could try to fix this by hard-coding the language dialect, but that doesn't work for all compilers. So instead, we opt for the simplest solution: just accept this output, and produce a pass. Tested on aarch64-linux. Approved-By: Tom Tromey <tom@tromey.com> PR testsuite/32756 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32756
2025-04-29[gdb/testsuite] Fix gdb.python/py-objfile.exp with gcc 15Tom de Vries4-5/+8
When running test-case gdb.python/py-objfile.exp with gcc 15, we get: ... (gdb) p main^M $2 = {int (void)} 0x40066c <main>^M (gdb) FAIL: $exp: print main with debug info ... The source file declares main as "int main ()" ... and until C23 this meant a non-prototype function declaration and we'd have: ... (gdb) p main^M $2 = {int ()} 0x40066c <main>^M ... However, starting C23 "int main ()" is simply equivalent to "int main (void)". Fix this by: - declaring main as "int main (void)" in the test-case, and - updating the regexp to expect an "int (void)" prototype. Likewise in gdb.base/jit-bfd-name.exp. Tested on aarch64-linux. Approved-By: Tom Tromey <tom@tromey.com> PR testsuite/32756 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32756
2025-04-29[gdb/testsuite] Don't use string_to_regexp twice in gdb.base/options.expTom de Vries1-2/+1
In test-case gdb.base/options.exp, in proc test_completer_recognizes we have: ... set expected_re [string_to_regexp $input_line] test_gdb_complete_unique $input_line $expected_re ... However, the first thing we do in proc test_gdb_complete_unique is to apply string_to_regexp to the second argument: ... proc test_gdb_complete_unique { input_line complete_line {append_char " "} {max_completions false} {testname ""} } { set complete_line_re [string_to_regexp $complete_line] test_gdb_complete_unique_re \ $input_line \ $complete_line_re \ $append_char \ $max_completions\ $testname } ... This happens to not cause any FAILs at the moment, but this should be done only once. Fix this not using string_to_regexp in proc test_completer_recognizes. Tested on x86_64-linux. Approved-By: Tom Tromey <tom@tromey.com>
2025-04-29[gdb] Handle nullptr gdb_std{err,out} in {gdbpy,ioscm}_flushTom de Vries2-5/+14
Using the trigger patch described in the previous commit, I get: ... $ gdb (gdb) <q>error detected on stdin Fatal signal: Segmentation fault ----- Backtrace ----- 0x64c7b3 gdb_internal_backtrace_1 /data/vries/gdb/src/gdb/bt-utils.c:127 0x64c937 _Z22gdb_internal_backtracev /data/vries/gdb/src/gdb/bt-utils.c:196 0x94db83 handle_fatal_signal /data/vries/gdb/src/gdb/event-top.c:1021 0x94dd48 handle_sigsegv /data/vries/gdb/src/gdb/event-top.c:1098 0x7f372be578ff ??? 0x10b7c0a _Z9gdb_flushP7ui_file /data/vries/gdb/src/gdb/utils.c:1527 0xd4b938 gdbpy_flush /data/vries/gdb/src/gdb/python/python.c:1624 0x7f372d73b276 _PyCFunction_FastCallDict Objects/methodobject.c:231 0x7f372d73b276 _PyCFunction_FastCallKeywords Objects/methodobject.c:294 0x7f372d794a09 call_function Python/ceval.c:4851 0x7f372d78e838 _PyEval_EvalFrameDefault Python/ceval.c:3351 0x7f372d796e6e PyEval_EvalFrameEx Python/ceval.c:754 0x7f372d796e6e _PyFunction_FastCall Python/ceval.c:4933 0x7f372d796e6e _PyFunction_FastCallDict Python/ceval.c:5035 0x7f372d6fefc8 _PyObject_FastCallDict Objects/abstract.c:2310 0x7f372d6fefc8 _PyObject_Call_Prepend Objects/abstract.c:2373 0x7f372d6fe162 _PyObject_FastCallDict Objects/abstract.c:2331 0x7f372d700705 callmethod Objects/abstract.c:2583 0x7f372d700705 _PyObject_CallMethodId Objects/abstract.c:2640 0x7f372d812a41 flush_std_files Python/pylifecycle.c:699 0x7f372d81281d Py_FinalizeEx Python/pylifecycle.c:768 0xd4d49b finalize_python /data/vries/gdb/src/gdb/python/python.c:2308 0x9587eb _Z17ext_lang_shutdownv /data/vries/gdb/src/gdb/extension.c:330 0xfd98df _Z10quit_forcePii /data/vries/gdb/src/gdb/top.c:1817 0x6b3080 _Z12quit_commandPKci /data/vries/gdb/src/gdb/cli/cli-cmds.c:483 0x1056577 stdin_event_handler /data/vries/gdb/src/gdb/ui.c:131 0x1986970 handle_file_event /data/vries/gdb/src/gdbsupport/event-loop.cc:551 0x1986f4b gdb_wait_for_event /data/vries/gdb/src/gdbsupport/event-loop.cc:672 0x1985e0c _Z16gdb_do_one_eventi /data/vries/gdb/src/gdbsupport/event-loop.cc:263 0xb66f2e start_event_loop /data/vries/gdb/src/gdb/main.c:402 0xb670ba captured_command_loop /data/vries/gdb/src/gdb/main.c:466 0xb68b9b captured_main /data/vries/gdb/src/gdb/main.c:1344 0xb68c44 _Z8gdb_mainP18captured_main_args /data/vries/gdb/src/gdb/main.c:1363 0x41a3b1 main /data/vries/gdb/src/gdb/gdb.c:38 --------------------- A fatal error internal to GDB has been detected, further debugging is not possible. GDB will now terminate. This is a bug, please report it. For instructions, see: <https://www.gnu.org/software/gdb/bugs/>. Segmentation fault (core dumped) $ q ... Fix this in gdbpy_flush by checking for nullptr gdb_stdout/gdb_stderr (and likewise in ioscm_flush) such that we get instead: ... $ gdb (gdb) <q>error detected on stdin $ q ... Tested on x86_64-linux. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2025-04-29[gdb] Fix sig_write for null gdb_stderrTom de Vries2-7/+16
When running test-case gdb.tui/tui-layout-asm.exp with target board dwarf5-fission-debug-types, the test-case fails and I get a core dump: ... # of unexpected core files 1 ... Looking at the backtrace of the core file, what seems to be happening is that: - gdbpy_flush attempts to flush gdb_stdout, which is nullptr - that causes a segfault - gdb intercepts this and starts to handle it using handle_fatal_signal - handle_fatal_signal calls sig_write, which attempts to write to gdb_stderr, which is nullptr, - that causes another segfault - gdb exits I managed to reproduce the problem by the following trigger patch in stdin_event_handler: ... - if (error) + if (1 || error) { current_ui = main_ui; ui->unregister_file_handler (); - if (main_ui == ui) + if (1 || main_ui == ui) { gdb_printf (gdb_stderr, _("error detected on stdin\n")); + gdb_stderr = nullptr; + gdb_stdout = nullptr; + gdb_stdlog = nullptr; quit_command ((char *) 0, 0); } ... which gives us: ... $ gdb (gdb) <q>error detected on stdin Segmentation fault (core dumped) $ q ... Fix sig_write to handle the case that gdb_stderr == nullptr, such that we get instead: ... $ gdb (gdb) <q>error detected on stdin Fatal signal: Segmentation fault ----- Backtrace ----- ... --------------------- A fatal error internal to GDB has been detected, further debugging is not possible. GDB will now terminate. This is a bug, please report it. For instructions, see: <https://www.gnu.org/software/gdb/bugs/>. Segmentation fault (core dumped) $ q ... Tested on x86_64-linux. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2025-04-29[gdb] Factor out sig_writeTom de Vries3-25/+13
Lambda function sig_write: ... const auto sig_write = [] (const char *msg) -> void { gdb_stderr->write_async_safe (msg, strlen (msg)); } ... is defined a few times. Factor this out into a regular function. Tested on x86_64-linux. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2025-04-29elf: Properly set sh_offset for .tbss sectionsH.J. Lu3-16/+51
Set sh_offset for .tbss sections to their nominal offset after aligning. They are not loaded from disk so the value doesn't really matter, except when the .tbss section is the first one in a PT_TLS segment. In that case, it sets the p_offset for the PT_TLS segment, which according to the ELF gABI ought to satisfy p_offset % p_align == p_vaddr % p_align. bfd/ PR ld/32896 * elf.c (assign_file_positions_for_load_sections): Properly set sh_offset for .tbss sections. ld/ PR ld/32896 * testsuite/ld-elf/tbss4.d: New file. * testsuite/ld-elf/tbss4.s: Likewise. Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
2025-04-28gprofng not reading references correctly in DwarfVladimir Mezentsev2-9/+9
Fixed as specified in the DWARF standard: The first type of reference can identify any debugging information entry within the containing unit. This type of reference is an offset from the first byte of the compilation header for the compilation unit containing the reference. There are five forms for this type of reference. There are fixed length forms for one, two, four and eight byte offsets (respectively, DW_FORM_ref1, DW_FORM_ref2, DW_FORM_ref4, and DW_FORM_ref8). There is also an unsigned variable length offset encoded form that uses unsigned LEB128 numbers (DW_FORM_ref_udata). gprofng/ChangeLog 2025-04-27 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> * src/DwarfLib.cc (set_die): Handling DWARF references (DW_FORM_ref1, DW_FORM_ref2, DW_FORM_ref4, DW_FORM_ref8, DW_FORM_ref_udata). * src/Dwarf.cc: Likewise.
2025-04-29dwarf: Dump .debug_loclists only for DWARF-5H.J. Lu6-2/+1175
.debug_loclists section is loaded into debug_information as DWARF-5 debug info and .debug_loc section is loaded into debug_information as pre-DWARF-5 debug info. When dumping .debug_loc section, we should only process pre-DWARF-5 debug info in debug_information. When dumping .debug_loclists section, we should only process DWARF-5 info in debug_information. binutils/ PR binutils/32809 * dwarf.c (display_debug_loc): Dump .debug_loclists only for DWARF-5. ld/ PR binutils/32809 * testsuite/ld-x86-64/dwarf4.s: New file. * testsuite/ld-x86-64/dwarf5a.s: Likewise. * testsuite/ld-x86-64/dwarf5b.s: Likewise. * testsuite/ld-x86-64/pr32809.d: Likewise. * testsuite/ld-x86-64/x86-64.exp: Run pr32809. Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
2025-04-29Automatic date update in version.inGDB Administrator1-1/+1
2025-04-28Fix "set debug parser"Tom Tromey5-3/+29
While debugging my longer series, I discovered that I broken "set debug parser" a couple years ago. This patch fixes it and adds a minimal test case so that it, hopefully, will not break again. This patch also adds parser debugging to the C++ name canonicalizer. Thanks to Tom de Vries for fixing the test case.
2025-04-28Regenerate more configury files for 64-bit BFD detection fixMaciej W. Rozycki5-11/+0
The fix for 64-bit BFD detection omitted the regeneration of a bunch of configury files; fix that.
2025-04-28Fix 64-bit BFD detection causing build failuresMaciej W. Rozycki12-710/+166
We have a discrepancy with 64-bit BFD handling across our component subdirectories leading to link failures such as: ld: ../opcodes/.libs/libopcodes.a(disassemble.o): in function `disassembler': disassemble.c:(.text+0x65): undefined reference to `print_insn_alpha' ld: disassemble.c:(.text+0x105): undefined reference to `print_insn_ia64' ld: disassemble.c:(.text+0x11d): undefined reference to `print_insn_loongarch' ld: disassemble.c:(.text+0x1a1): undefined reference to `print_insn_big_mips' [...] with some configurations having a 32-bit host and 64-bit BFD, such as: `--host=i386-linux-gnu --target=riscv64-linux-gnu --enable-targets=all'. This is ultimately due to how 64-bit BFD is enabled for bfd/ itself and other subdirectorses and has been a regression from commit 1d5269c994bf ("unify 64-bit bfd checks"). For bfd/ the BFD_64_BIT autoconf macro from config/bfd64.m4 is used combined with this logic in bfd/configure.ac: case ${host64}-${target64}-${want64} in *true*) wordsize=64 bfd64_libs='$(BFD64_LIBS)' all_backends='$(BFD64_BACKENDS) $(BFD32_BACKENDS)' [...] ;; false-false-false) wordsize=32 all_backends='$(BFD32_BACKENDS)' ;; esac where the value of ${wordsize} switches between 32-bit and 64-bit BFD via these pieces: #define BFD_ARCH_SIZE @wordsize@ and: #if BFD_ARCH_SIZE >= 64 #define BFD64 #endif in bfd/bfd-in.h, which ultimately becomes a part of "bfd.h". Then ${host64} is determined in bfd/configure.ac from the host's word size, via the host's pointer size: if test "x${ac_cv_sizeof_void_p}" = "x8"; then host64=true fi And ${target64} is determined in bfd/configure.ac from the target's word size: if test ${target_size} = 64; then target64=true fi Where multiple targets have been requested with `--enable-targets=all' the presence of any 64-bit target will set "true" here. Finally ${want64} is set according to `--enable-64-bit-bfd' user option with an arrangement involving BFD_64_BIT: BFD_64_BIT if test $enable_64_bit_bfd = yes ; then want64=true else want64=false fi which also, redundantly, checks and sets its result upon the host's word size. Lastly ${want64} is also selectively set by target fragments in bfd/config.bfd, which mostly if not completely overlaps with ${target64} setting as described above. Conversely other subdirectories only rely on BFD_64_BIT, so they fail to notice that BFD is 64-bit and do not enable their 64-bit handling where the host requested is 32-bit and 64-bit BFD has been enabled other than with `--enable-64-bit-bfd'. One consequence is opcodes/disassemble.c enables calls to its numerous own 64-bit backends by checking the BFD64 macro from "bfd.h", however does not actually enable said backends in its Makefile. Hence the link errors quoted above. Address the problem then by moving the `--enable-64-bit-bfd' option back to bfd/configure.ac and remove the call to BFD_64_BIT from there and then rewrite the macro in terms of checking for the presence of BFD64 macro in "bfd.h", which is the canonical way of determining whether BFD is 64-bit or not. Rather than running `grep' directly on ../bfd/bfd-in3.h as the opcodes/ fragment used to before the problematic commit: if grep '#define BFD_ARCH_SIZE 64' ../bfd/bfd-in3.h > /dev/null; then run the preprocessor on "bfd.h", which allows to invoke the macro from configure.ac files placed in subdirectories located at deeper levels, by relying on the preprocessor's search path. This requires however that the invokers rely on `all-bfd' rather than `configure-bfd' for their `configure' invocation stage, because "bfd.h" is made by `make all' rather than `configure' in bfd/. Do not cache the result of this check however, as reconfiguring a tree such as to flip `--enable-64-bit-bfd' on or to change a secondary target may affect BFD64 and we have no access to information about secondary targets in BFD_64_BIT. Also remove the ENABLE_BFD_64_BIT automake conditional, as it's not used anywhere. Last but not least remove the hack from gdb/configure.ac to fail builds for `mips*-*-*' hosts where `--enable-targets=all' has been requested, but `--enable-64-bit-bfd' has not as it's no longer needed. Such builds complete successfully now, having enabled 64-bit BFD implicitly. Tested-By: Guinevere Larsen <guinevere@redhat.com> Tested-By: Luis Machado <luis.machado@arm.com> Approved-By: Alan Modra <amodra@gmail.com> Approved-By: Luis Machado <luis.machado@arm.com>
2025-04-28[gdb/testsuite] Avoid generating gdb_leak_detector.cpython-<n>.pycTom de Vries3-0/+18
After running test-case gdb.python/py-color-leak.exp in a container where I don't have PYTHONDONTWRITEBYTECODE set, I get: ... $ ls src/gdb/testsuite/gdb.python/__pycache__/ gdb_leak_detector.cpython-313.pyc ... Fix this by setting sys.dont_write_bytecode to True in the python scripts importing the module. Tested on x86_64-linux.
2025-04-28Update binutils/MAINTAINERS for PPCSurya Kumari Jangala1-0/+1
binutils/ * MAINTAINERS: Add myself as PPC maintainer.
2025-04-28PowerPC: Support for Prefixed Add Immediate Shifted Instruction (RFC02686)Surya Kumari Jangala3-1/+119
opcodes/ * ppc-opc.c (insert_si32, extract_si32, insert_nsi32, extract_nsi32): New functions. (SI32, NSI32, P_D_SI32_MASK, P_DRAPCREL_SI32_MASK): New macros. (IMM32): Update for new macros. (powerpc_opcodes): Add plis, paddis, psubis. gas/ * testsuite/gas/ppc/future.s: New test. * testsuite/gas/ppc/future.d: Likewise.
2025-04-28Automatic date update in version.inGDB Administrator1-1/+1
2025-04-27Automatic date update in version.inGDB Administrator1-1/+1
2025-04-26Add "maint canonicalize" commandTom Tromey4-0/+34
This adds a new "maint canonicalize" command that can be used to see the canonical form of a C++ name. I've needed this a few times when debugging gdb. Reviewed-By: Eli Zaretskii <eliz@gnu.org> Reviewed-By: Tom de Vries <tdevries@suse.de>
2025-04-26[gdb/contrib] Add codespell:ignore-begin/ignore-end (disabled)Tom de Vries1-0/+9
It would be useful to tell codespell to ignore blocks of code. A feature ignore-multiline-regex exists, which can be used to implement this: ... $ codespell --ignore-multiline-regex \ 'codespell:ignore-begin.*codespell:ignore-end' ... Unfortunately there's a bug in codespell where using -w in combination with --ignore-multiline-regex drops all newlines in the updated file. In absence of a fix, commit this solution disabled, to locally document the current state of this feature.
2025-04-26Automatic date update in version.inGDB Administrator1-1/+1
2025-04-25Fix d10v sim build with GCC 15Tom Tromey1-1/+1
The d10v sim fails when built with GCC 15. From the bug: d10v/table.c:171:17: error: initialization of ‘void (*)(struct sim_state *, SIM_CPU *)’ {aka ‘void (*)(struct sim_state *, struct _sim_cpu *)’} from incompatible pointer type ‘void (*)(void)’ [-Wincompatible-pointer-types] 171 | { 0,0,0,0,0,0,0,(void (*)())0,0,{0,0,0}}, | ^ d10v/table.c:171:17: note: (near initialization for ‘Simops[165].func’) The bug here is that this is the wrong function pointer type. Since '0' is perfectly fine here, this patch simply removes the cast. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32900 Approved-By: Tom de Vries <tdevries@suse.de>
2025-04-25[pre-commit] Add codespell-log commit-msg hookTom de Vries2-0/+103
Now that we're using codespell to check spelling in gdb files, can we use codespell to bring this spelling warning: ... $ echo usuable | codespell - 1: usuable usuable ==> usable ... to: ... $ git commit -a -m "Usuable stuff" ... ? First, let's look at a straightforward commit-msg hook implementation: ... - id: codespell name: codespell-commit-msg verbose: true always_run: true stages: [commit-msg] ... installed using: ... $ pre-commit install -t commit-msg ... When trying the commit, we get: ... $ echo "/* bla */" >> gdb/gdb.c $ git commit -a -m "Usuable stuff" black................................................(no files to check)Skipped flake8...............................................(no files to check)Skipped isort................................................(no files to check)Skipped codespell............................................(no files to check)Skipped check-include-guards.................................(no files to check)Skipped black................................................(no files to check)Skipped flake8...............................................(no files to check)Skipped codespell............................................(no files to check)Skipped codespell-commit-msg.....................................................Failed - hook id: codespell - duration: 0.06s - exit code: 65 .git/COMMIT_EDITMSG:1: Usuable ==> Usable check-include-guards.................................(no files to check)Skipped $ ... The commit was aborted, but the commit message is still there: ... $ cat .git/COMMIT_EDITMSG Usuable stuff ... We can retry and edit the commit message to clean up the typo: ... $ git commit -e -F .git/COMMIT_EDITMSG -a ... but it's a bit cumbersome. Furthermore, say we fix a typo and want to document this in the commit log, and do: ... $ git commit -m "Fixed typo: useable -> usable" -a ... This commit cannot succeed, unless we add a codespell ignore tag, which feels like taking it too far. Both these problems can be addressed by setting things up in such a way that the commit always succeeds, and codespell output is shown as a hint. Ideally, we'd tell to pre-commit to implement this using some setting, but there doesn't seem to be one. So we use some indirection. Instead of using native codespell, use a local hook that calls a script gdb/contrib/codespell-log.sh, which calls pre-commit, which calls codespell. Using this approach, we get: ... $ echo "/* bla */" >> gdb/gdb.c $ git commit -a -m "Usuable stuff" black................................................(no files to check)Skipped flake8...............................................(no files to check)Skipped isort................................................(no files to check)Skipped codespell............................................(no files to check)Skipped check-include-guards.................................(no files to check)Skipped black................................................(no files to check)Skipped flake8...............................................(no files to check)Skipped codespell............................................(no files to check)Skipped check-include-guards.................................(no files to check)Skipped codespell-log............................................................Passed - hook id: codespell-log - duration: 0.18s codespell-log-internal...................................................Failed - hook id: codespell - exit code: 65 .git/COMMIT_EDITMSG:1: Usuable ==> Usable [codespell/codespell-log-2 d081bd25a40] Usuable stuff 1 file changed, 1 insertion(+) $ ... This is obviously convoluted, but it works. Perhaps we can propose a pre-commit improvement (always_pass) and simplify this eventually. Checked new script codespell-log.sh with shell-check. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2025-04-25gdb: fix 32 bit buildGuinevere Larsen1-1/+1
The recent commit dbbb9cfd3708a5b09b449c6cbc4d74dfec13904d added a message using %ld to print an std::vector::size, which is of size_t type. on 64 bit machines, size_t will be an unsigned long int, making %ld work just fine, but on 32 bit ones, size_t will be unsigned int, which causes the build to fail. This commit fixes that by using %zu instead. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32901 Tested-By: Luis Machado <luis.machado@arm.com> Approved-By: Luis Machado <luis.machado@arm.com>
2025-04-25Revert "gdb: update corner case when canonicalizing riscv syscall names"Guinevere Larsen1-1/+1
This reverts commit b2aba1ce1326df73c03641e1cb01d2c5aa577015. That commit was pushed in error, as I confused which patch was approved in the list
2025-04-25BFD linker: Allow target backends to provide alternate entry names.Pali Roh?r6-19/+88
PR 30144
2025-04-24gdb/dwarf: add dwarf2_cu::find_die methodSimon Marchi2-5/+13
I added this small helper method in the series I'm writing, to make finding a DIE by section offset a bit nicer than using the unordered_set methods. It doesn't have any dependencies, so I thought I would submit it on its own. Change-Id: If7313194ab09d9bd6d6a52c24eb6fd9a9c1b76e0 Approved-by: Kevin Buettner <kevinb@redhat.com>
2025-04-25Automatic date update in version.inGDB Administrator1-1/+1
2025-04-24gdbsupport: add missing include guard to remote-args.hSimon Marchi1-1/+6
Also, fix a type in "namespace". Change-Id: I3e5d1d49c765a035217437c0635b12dc28e41bf6
2025-04-24pre-commit autoupdateSimon Marchi1-2/+2
Run `pre-commit autoupdate`. This brings in new versions of isort and flake8. Change-Id: I55f8b51b100e090e9a210338f46e10cf131a4aa7 Approved-By: Tom Tromey <tom@tromey.com>
2025-04-24gdb: fix some flake8 F824 warningsSimon Marchi12-36/+2
flake8 7.2.0 appears to have this new warning: F824: global name / nonlocal name is unused: name is never assigned in scope It points out a few places in our code base where "global" is not necessary, fix them. Change-Id: Ia6fb08686977559726fefe2a5bb95d8dcb298bb0 Approved-By: Tom Tromey <tom@tromey.com>
2025-04-24Use correct sign extension for enumeration typesTom Tromey1-22/+37
This changes update_enumeration_type_from_children to use the correct sign-extension method on the attribute. The logic here is a bit complicated: if the enum has an underlying type, then we use that type's signed-ness to interpret attributes; otherwise we must assume attributes are encoded as signed values. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32680
2025-04-24Use bool in update_enumeration_type_from_childrenTom Tromey1-6/+6
This is just a small preliminary cleanup to use 'bool' in update_enumeration_type_from_children.
2025-04-24Remove dead code from dwarf2_const_value_dataTom Tromey1-35/+16
dwarf2_const_value_data checks the size of the data like so: if (bits < sizeof (*value) * 8) ... else if (bits == sizeof (*value) * 8) ... else ... However, 'bits' can only be 8, 16, 32, or 64. And, because 'value' is a LONGEST, which is alwasy 64-bit, the final 'else' can never be taken. This patch removes the dead code. And, because this was the only reason for a non-void return value, the return type is changed as well. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32680
2025-04-24Use attribute::signed_constant in attribute::as_booleanTom Tromey1-1/+4
This changes attribute::as_boolean to use attribute::signed_constant. This is maybe overkill but lets any reasonable constant form through. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32680
2025-04-24Use correct sign for variant part discriminantsTom Tromey1-10/+24
The discriminant value for a variant part may be signed or unsigned, depending on the type of the variant. This patch changes the DWARF reader to delay interpretation of the relevant attribute until the signed-ness is known. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32680
2025-04-24Use correct sign in get_mpzTom Tromey2-2/+11
This changes dwarf2/read.c:get_mpz to use the correct sign-extension function. Normally a rational constant uses signed values, but a purely unsigned form also seems fine here. This adds a new attribute::form_is_strictly_unsigned, which is more precise than form_is_unsigned (which accepts a lot of forms that aren't really for ordinary constants). Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32680
2025-04-24Use attribute::unsigned_constant for DW_AT_data_member_locationTom Tromey1-3/+3
This changes the DWARF reader to use attribute::unsigned_constant for DW_AT_data_member_location. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32680
2025-04-24Use attribute::unsigned_constant for DW_AT_data_bit_offsetTom Tromey1-10/+16
This changes the DWARF reader to use attribute::unsigned_constant when examining DW_AT_data_bit_offset. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32680
2025-04-24Use correct sign for DW_AT_GNU_biasTom Tromey1-2/+7
DW_AT_GNU_bias may be signed or unsigned, depending on the underlying type. This patch changes the DWARF reader to examine the type before decoding the attribute. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32680
2025-04-24Use attribute::unsigned_constant for DW_AT_bit_strideTom Tromey1-1/+1
DW_AT_bit_stride uses an unsigned constant, so make this explicit in the reader. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32680
2025-04-24Use attribute::signed_constant for fixed-point scaleTom Tromey1-2/+2
This changes the DWARF reader to use attribute::signed_constant for DW_AT_binary_scale and DW_AT_decimal_scale. (FWIW these were the attributes that first lead me to find this problem.) Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32680
2025-04-24Introduce attribute::signed_constantTom Tromey3-0/+49
This introduces a new method, attribute::signed_constant. This should be used wherever DWARF specifies a signed integer constant, or where this is implied by the context. It properly handles sign-extension for DW_FORM_data*. To my surprise, there doesn't seem to be a pre-existing sign-extension function. I've added one to common-utils.h alongside the align functions. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32680
2025-04-24Use attribute::unsigned_constant for sizesTom Tromey1-17/+16
This changes the DWARF reader to use attribute::unsigned_constant for DW_AT_bit_size, DW_AT_byte_size, DW_AT_data_byte_size, and DW_AT_string_length. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32680
2025-04-24gdb: update corner case when canonicalizing riscv syscall namesGuinevere Larsen1-1/+1
The script syscalls/riscv-canonicalize-syscall-gen.py has been recently introduced to help support record-full in riscv systems. However, it was developed before commit 432eca4113d5748ad284a068873455f9962b44fe, which made the GDB enum more consistent, which forced the python script to have a corner case for the "gdb_old_mmap" case. Since the aforementioned commit has already been merged, we need to update the special case for the mmap syscall. A special case is still needed because the script would expect that the glibc sources call the syscall "old_mmap", or that gdb call it "gdb_sys_mmap", neither of which happens unfortunately. This commit doesn't change the .c file because it was already fixed by a different commit, 65ab41b7d5c612b6000b28f4c50bb256b2a9e22b, which was pushed as obvious to fix the build issues. Tested-By: Luis Machado <luis.machado@arm.com> Approved-By: Luis Machado <luis.machado@arm.com>
2025-04-24Fix documentation for gdb.blocked_signalsTom Tromey1-5/+5
gdb exports a context manager named gdb.blocked_signals, but the documentation erroneously refers to it as gdb.block_signals. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32891 Approved-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Tom de Vries <tdevries@suse.de>
2025-04-24Add TLS NEWS entry and document 'set force-internal-tls-address-lookup' commandKevin Buettner2-0/+70
Reviewed-By: Eli Zaretskii <eliz@gnu.org> Tested-By: Luis Machado <luis.machado@arm.com> Approved-By: Luis Machado <luis.machado@arm.com>
2025-04-24New test - gdb.base/tls-dlobj.expKevin Buettner3-0/+776
This test exercises musl_link_map_to_tls_module_id() and glibc_link_map_to_tls_module_id(), both of which are in solib-svr4.c. Prior to writing this test, I had only written what is now named 'musl_link_map_to_tls_module_id' and it worked for both GLIBC and MUSL. Once I wrote this new test, tls-dlobj.exp, there were a number of tests which didn't work with GLIBC. This led me to write a GLIBC-specific link map to module id function, i.e, 'glibc_link_map_to_tls_module_id'. It only has one compilation scenario, in which the pthread(s) library is used - as noted in a comment, it became too much of a hassle to try to KFAIL things, though it certainly could have been done in much the same was as was done in gdb.base/multiobj.exp. It didn't seem that important to do so, however, since I believe that the other tests have adequate coverage for different compilation scenarios. Tested-By: Luis Machado <luis.machado@arm.com> Approved-By: Luis Machado <luis.machado@arm.com>
2025-04-24New test - gdb.base/tls-multiobj.expKevin Buettner5-0/+397
This test exercises GDB's internal TLS support when both the main program and several shared libraries have TLS variables. It also tests existing (non-internal) TLS support too. It tests using two compilation scenarios, "default", in which libpthread is not linked with the program and libraries as well as one which does use libpthread. It tests link map address to module id mapping code in GDB in addition to the ability of GDB to traverse TLS data structures with several libraries in play. Tested-By: Luis Machado <luis.machado@arm.com> Approved-By: Luis Machado <luis.machado@arm.com>
2025-04-24New test - gdb.base/tls-nothreads.expKevin Buettner3-0/+355
This commit introduces a new test, gdb.base/tls-nothreads.exp. It has a test case, a C file, which has several TLS variables in the main program, which, once compiled and linked, should end up (in ELF files) in .tdata and .tbss. The test compiles the program in a number of different ways, making sure that each variable is accessible regardless of how it was compiled. Note that some of the compilation scenarios end up with a statically linked executable. Prior to this series of commits, accessing TLS variables from a statically linked program on Linux did not work. For certain targets (x86_64, aarch64, s390x, riscv, and ppc64), all on Linux, support has been added to GDB for accessing thread local storage in statically linked executables. This test is important for testing those build scenarios. But it's also important to make sure that GDB's internal TLS support works for other scenarios too. In order to accomplish that, the tests are also run in a mode which forces the internal support to be used. It also adds a new file, gdb.base/tls-common.exp.tcl, which includes some common definitions used by the three new TLS tests, including the one added by this commit. In particular, it sets a TCL variable, 'internal_tls_linux_targets' which list the targets mentioned earlier. This means that as internal TLS support is added for other targets, the target should be listed in just one file as opposed to three (or more if other tests using tls-common.exp.tcl are added). Tested-By: Luis Machado <luis.machado@arm.com> Approved-By: Luis Machado <luis.machado@arm.com>
generated by cgit v1.1 at 2025-09-23 14:52:13 +0000