aboutsummaryrefslogtreecommitdiff
path: root/gdb
AgeCommit message (Collapse)AuthorFilesLines
2024-06-04Add myself to gdb/MAINTAINERSDmitry Neverov1-0/+1
2024-06-04gdb/testsuite: tests for debug lookup within the sysrootAndrew Burgess2-0/+215
Add tests for looking up debug information within the sysroot via both build-id and gnu_debuglink. I wanted to ensure that the gnu_debuglink test couldn't make use of build-ids, so I added the 'no-build-id' flag to gdb_compile. As these tests rely on setting the sysroot, if I'm running a dynamically linked executable, GDB will try to find all shared libraries within the sysroot. This would mean I'd have to figure out and copy all shared libraries the executable uses, certainly possible, but a bit of a pain. So instead, I've just compiled the test executable as a static binary. Now there are no shared library dependencies. I can now split the debug information out from the test binary, and place it within the sysroot. When GDB is started and the executable loaded, we can check that GDB is finding the debug information within the sysroot. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31804 Approved-By: Tom de Vries <tdevries@suse.de>
2024-06-04gdb/testsuite: make gdb_gnu_strip_debug consistentAndrew Burgess3-37/+25
While writing a test I realised that the default behaviour of gdb_gnu_strip_debug doesn't match its comment. The comment says that the function takes a FILENAME, and splits the file into FILENAME.stripped and FILENAME.debug, leaving FILENAME unchanged. The comment says that a .gnu_debuglink will be added to FILENAME.stripped. However, this is not true, FILENAME.stripped is created, with no debug information. FILENAME.debug is created containing the debug information. But, when adding the .gnu_debuglink we take FILENAME.stripped as the input, and then overwrite FILENAME with the output. As a result, FILENAME.stripped does not include a .gnu_debuglink, while FILENAME contains the .gnu_debuglink and no debug information! The users of gdb_gnu_strip_debug can be split into two groups, those who are using the .gnu_debuglink, these tests are all written assuming that FILENAME is updated. Then there are some tests that only rely on gdb_gnu_strip_debug's ability to split out the debug information, these tests are then going to do a lookup based on the build-id, these tests don't require the .gnu_debuglink. These tests use the FILENAME.stripped output file. This all seems too confused to me. As most uses of gdb_gnu_strip_debug assume that FILENAME is updated, I propose that we just make that the actual, advertised behaviour of this proc. So now, gdb_gnu_strip_debug will take FILENAME, and will split the debug information out into FILENAME.debug. The debug information will then be stripped from FILENAME, and by default a .gnu_debuglink will be added to FILENAME pointing to FILENAME.debug. I've updated the two tests that actually relied on FILENAME.stripped to instead just use FILENAME. One of the tests was doing a build-id based lookup, but was still allowing the .gnu_debuglink to be added to FILENAME, I've updated this test to pass the no-debuglink flag to gdb_gnu_strip_debug, which stops the .gnu_debuglink from being added. All of the tests that call gdb_gnu_strip_debug still pass for me. Acked-By: Tom de Vries <tdevries@suse.de>
2024-06-04gdb/Makefile.in: silence recipe for creating .deps/ directoriesAndrew Burgess1-1/+1
When building in a fresh directory we'll see some output like this: /bin/sh ../../src/gdb/../mkinstalldirs arch/.deps mkdir -p -- arch/.deps /bin/sh ../../src/gdb/../mkinstalldirs cli/.deps mkdir -p -- cli/.deps /bin/sh ../../src/gdb/../mkinstalldirs dwarf2/.deps mkdir -p -- dwarf2/.deps ... etc ... this commit uses silent-rules.mk to silence this output, now we'll see: GEN arch/.deps GEN cli/.deps GEN dwarf2/.deps ... etc ... The recipe that currently generates these directories uses mkinstalldirs, as I mention in commit 032e5e0c0c08977, mkinstalldirs is deprecated and 'install-sh -d' should be used instead. This silences the 'mkdir -p -- ...' part of the output. There should be no change in what is actually built after this commit. Approved-By: Tom Tromey <tom@tromey.com>
2024-06-03Remove one call to can_box from TUITom Tromey1-9/+3
This removes a call to can_box from tui_source_window_base::show_source_content. can_box will always return true here. Approved-By: Andrew Burgess <aburgess@redhat.com>
2024-06-03Fix deprecation textTom Tromey1-1/+1
I noticed one spot where deprecate_cmd is called with a second argument that is not a command name. This patch fixes the problem. Regression tested on x86-64 Fedora 38.
2024-06-03Enable call of overloaded subscript operator from pythonHannes Domani3-1/+12
If you try to use the overloaded subscript operator of a class in python, it fails like this: (gdb) py print(gdb.parse_and_eval('b')[5]) Traceback (most recent call last): File "<string>", line 1, in <module> gdb.error: Cannot subscript requested type. Error while executing Python code. This simply checks if such an operator exists, and calls it instead, making this possible: (gdb) py print(gdb.parse_and_eval('b')[5]) 102 'f' Approved-By: Tom Tromey <tom@tromey.com>
2024-06-03Allow calling of convenience functions with pythonHannes Domani2-5/+24
As mentioned in PR13326, currently when you try to call a convenience function with python, you get this error: (gdb) py print(gdb.convenience_variable("_isvoid")(3)) Traceback (most recent call last): File "<string>", line 1, in <module> RuntimeError: Value is not callable (not TYPE_CODE_FUNC or TYPE_CODE_METHOD). Error while executing Python code. So this extends valpy_call to handle TYPE_CODE_INTERNAL_FUNCTION as well, making this possible: (gdb) py print(gdb.convenience_variable("_isvoid")(3)) 0 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=13326 Approved-By: Tom Tromey <tom@tromey.com>
2024-06-03[gdb/testsuite] Fix timeout in gdb.tui/resize-2.expTom de Vries1-3/+15
When running test-case gdb.tui/resize-2.exp with taskset -c 0, I sometimes run into: ... tui disable^[[40;1H^M(gdb) PASS: $exp: tui disable ^M^[[K(gdb) FAIL: $exp: two prompt redisplays after resize (timeout) ... The test-case does "Term::resize 24 80 0" while having the settings of an earlier "Term::resize 40 90", so both dimensions change. When TUI is enabled, we call Term::resize with wait_for_msg == 1, and the proc: - calls stty to change one dimension, - waits for the message (enabled by "maint set tui-resize-message on") confirming the resize has happened, - calls stty to change the other dimension, and again - waits for the message confirming the resize has happened. Since TUI is disabled, we call Term::resize with wait_for_msg == 0 because the message is not printed, so stty is called twice, and afterwards we check for the results of the two resizes, which is the test that is failing. The problem is that not waiting for a response after each stty call opens up the possibility of the responses being merged. Fix this by calling Term::resize twice, changing one dimension at a time, and waiting for a single prompt redisplay after each one. Tested on x86_64-linux. Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com> PR testsuite/31822 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31822
2024-06-02Fix typo in tui-data.hTom Tromey1-1/+1
I noticed a typo in a comment in tui-data.h.
2024-05-31[gdb/testsuite] New test: gdb.base/errno.expKevin Buettner2-0/+300
Printing the value of 'errno' from GDB is sometimes problematic. The situation has improved in recent years, though there are still scenarios for which "print errno" doesn't work. The test, gdb.base/errno.exp, introduced by this commit, tests whether or not GDB can print errno using a binary compiled in the following different ways: - default: no switches aside from -g (and whatever else is added by the testing framework) - macros: macro info is included in the debuginfo; this is enabled by using -g3 when using gcc or clang - static: statically linked binary - static-macros: statically linked binary w/ macro definitions included in debuginfo - pthreads: libpthread linked binary - pthreads-macros: libpthread linked binary w/ macro definitions included in debuginfo - pthreads-static: Statically linked against libpthread - pthreads-static-macros: Statically linked against libpthread w/ macro definitions For each of these, the test also creates a corefile, then loads the corefile and attempts to print errno again. Additionally, the test checks that a "masking" errno declared as a local variable will print correctly. On Linux, if the machine is missing glibc debuginfo (or you have debuginfod disabled), it's likely you'll see: (gdb) print errno 'errno' has unknown type; cast it to its declared type But if you add a cast, the value of errno is often available: (gdb) print (int) errno $1 = 42 The test detects this situation along with several others and does 'setup_xfail' for tests that will almost certainly fail. It could be argued that some of these ought to be KFAILs due to deficiencies in GDB, but I'm not entirely certain which, if any, are fixable yet. On Fedora 39, without glibc debuginfo, there are no failures, but I do see the following XFAILS: XFAIL: gdb.base/errno.exp: default: print errno XFAIL: gdb.base/errno.exp: default: check errno value from corefile XFAIL: gdb.base/errno.exp: macros: print errno XFAIL: gdb.base/errno.exp: macros: print (int) errno XFAIL: gdb.base/errno.exp: macros: check errno value from corefile XFAIL: gdb.base/errno.exp: static: print errno XFAIL: gdb.base/errno.exp: static: print (int) errno XFAIL: gdb.base/errno.exp: static: check errno value from corefile XFAIL: gdb.base/errno.exp: static-macros: print errno XFAIL: gdb.base/errno.exp: static-macros: print (int) errno XFAIL: gdb.base/errno.exp: static-macros: check errno value from corefile XFAIL: gdb.base/errno.exp: pthreads: print errno XFAIL: gdb.base/errno.exp: pthreads: check errno value from corefile XFAIL: gdb.base/errno.exp: pthreads-macros: print errno XFAIL: gdb.base/errno.exp: pthreads-macros: print (int) errno XFAIL: gdb.base/errno.exp: pthreads-macros: check errno value from corefile XFAIL: gdb.base/errno.exp: pthreads-static: print errno XFAIL: gdb.base/errno.exp: pthreads-static: print (int) errno XFAIL: gdb.base/errno.exp: pthreads-static: check errno value from corefile XFAIL: gdb.base/errno.exp: pthreads-static-macros: print errno XFAIL: gdb.base/errno.exp: pthreads-static-macros: print (int) errno XFAIL: gdb.base/errno.exp: pthreads-static-macros: check errno value from corefile On Fedora 39, with glibc debug info, but without libc.a (for static linking), there are 2 XFAILs, 2 UNSUPPORTED tests, and 4 UNTESTED tests. So, even when testing in less than ideal conditions, either due to lack of glibc debuginfo or lack of a libc to link against to make a static binary, there are no failures. With glibc debuginfo installed, on Fedora 38, Fedora 39, Fedora 40, Fedora rawhide (41), and Ubuntu 22.04.1 LTS, I see these XFAILs: XFAIL: gdb.base/errno.exp: macros: check errno value from corefile XFAIL: gdb.base/errno.exp: static: print errno XFAIL: gdb.base/errno.exp: static: print (int) errno XFAIL: gdb.base/errno.exp: static: check errno value from corefile XFAIL: gdb.base/errno.exp: static-macros: print errno XFAIL: gdb.base/errno.exp: static-macros: print (int) errno XFAIL: gdb.base/errno.exp: static-macros: check errno value from corefile XFAIL: gdb.base/errno.exp: pthreads-macros: check errno value from corefile XFAIL: gdb.base/errno.exp: pthreads-static: print errno XFAIL: gdb.base/errno.exp: pthreads-static: print (int) errno XFAIL: gdb.base/errno.exp: pthreads-static: check errno value from corefile XFAIL: gdb.base/errno.exp: pthreads-static-macros: print errno XFAIL: gdb.base/errno.exp: pthreads-static-macros: print (int) errno XFAIL: gdb.base/errno.exp: pthreads-static-macros: check errno value from corefile On FreeBSD 13.1, the total number of XFAILs are fewer, and could be even better still if it had debug info for glibc: XFAIL: gdb.base/errno.exp: default: print errno XFAIL: gdb.base/errno.exp: default: check errno value from corefile XFAIL: gdb.base/errno.exp: macros: print errno XFAIL: gdb.base/errno.exp: macros: print (int) errno XFAIL: gdb.base/errno.exp: macros: check errno value from corefile XFAIL: gdb.base/errno.exp: static-macros: check errno value from corefile XFAIL: gdb.base/errno.exp: pthreads: print errno XFAIL: gdb.base/errno.exp: pthreads: check errno value from corefile XFAIL: gdb.base/errno.exp: pthreads-macros: print errno XFAIL: gdb.base/errno.exp: pthreads-macros: print (int) errno XFAIL: gdb.base/errno.exp: pthreads-macros: check errno value from corefile XFAIL: gdb.base/errno.exp: pthreads-static-macros: check errno value from corefile Starting with glibc-2.34, most of the pthreads library has been incorporated into libc, so finding thread-local variables using libthread_db is possible for several scenarios in which it previously wasn't. But, prior to this, accessing errno for the default scenario was a problem. This is borne out by running this new test on Fedora 34, which uses glibc-2.33: XFAIL: gdb.base/errno.exp: default: print errno XFAIL: gdb.base/errno.exp: default: print (int) errno XFAIL: gdb.base/errno.exp: default: check errno value from corefile XFAIL: gdb.base/errno.exp: macros: check errno value from corefile XFAIL: gdb.base/errno.exp: static: print errno XFAIL: gdb.base/errno.exp: static: print (int) errno XFAIL: gdb.base/errno.exp: static: check errno value from corefile XFAIL: gdb.base/errno.exp: static-macros: print errno XFAIL: gdb.base/errno.exp: static-macros: print (int) errno XFAIL: gdb.base/errno.exp: static-macros: check errno value from corefile XFAIL: gdb.base/errno.exp: pthreads-macros: check errno value from corefile XFAIL: gdb.base/errno.exp: pthreads-static: print errno XFAIL: gdb.base/errno.exp: pthreads-static: check errno value from corefile XFAIL: gdb.base/errno.exp: pthreads-static-macros: print errno XFAIL: gdb.base/errno.exp: pthreads-static-macros: print (int) errno XFAIL: gdb.base/errno.exp: pthreads-static-macros: check errno value from corefile In the v3 version of this test, Tom de Vries tested on openSUSE Leap 15.5 and found a number of cases which showed a FAIL instead of an XFAIL. The v4 version of this test fixed those problems. On Leap 15.5, which uses glibc-2.31, with glibc debug info, I now see: XFAIL: gdb.base/errno.exp: default: print errno XFAIL: gdb.base/errno.exp: default: print (int) errno XFAIL: gdb.base/errno.exp: default: check errno value from corefile XFAIL: gdb.base/errno.exp: macros: check errno value from corefile XFAIL: gdb.base/errno.exp: static: print errno XFAIL: gdb.base/errno.exp: static: print (int) errno XFAIL: gdb.base/errno.exp: static: check errno value from corefile XFAIL: gdb.base/errno.exp: static-macros: check errno value from corefile XFAIL: gdb.base/errno.exp: pthreads-macros: check errno value from corefile XFAIL: gdb.base/errno.exp: pthreads-static: print errno XFAIL: gdb.base/errno.exp: pthreads-static: print (int) errno XFAIL: gdb.base/errno.exp: pthreads-static: check errno value from corefile XFAIL: gdb.base/errno.exp: pthreads-static-macros: check errno value from corefile On Leap 15.5, with glibc debuginfo missing, the results are a little worse: XFAIL: gdb.base/errno.exp: default: print errno XFAIL: gdb.base/errno.exp: default: print (int) errno XFAIL: gdb.base/errno.exp: default: check errno value from corefile XFAIL: gdb.base/errno.exp: macros: print errno XFAIL: gdb.base/errno.exp: macros: print (int) errno XFAIL: gdb.base/errno.exp: macros: check errno value from corefile XFAIL: gdb.base/errno.exp: static: print errno XFAIL: gdb.base/errno.exp: static: print (int) errno XFAIL: gdb.base/errno.exp: static: check errno value from corefile XFAIL: gdb.base/errno.exp: static-macros: check errno value from corefile XFAIL: gdb.base/errno.exp: pthreads: print errno XFAIL: gdb.base/errno.exp: pthreads: check errno value from corefile XFAIL: gdb.base/errno.exp: pthreads-macros: print errno XFAIL: gdb.base/errno.exp: pthreads-macros: print (int) errno XFAIL: gdb.base/errno.exp: pthreads-macros: check errno value from corefile XFAIL: gdb.base/errno.exp: pthreads-static: print errno XFAIL: gdb.base/errno.exp: pthreads-static: print (int) errno XFAIL: gdb.base/errno.exp: pthreads-static: check errno value from corefile XFAIL: gdb.base/errno.exp: pthreads-static-macros: check errno value from corefile The v5 version of this test fixed failures when testing with check-read1. (Thanks to Linaro CI for finding these.) I revised the regular expressions being used so that the failures were eliminated, but the results mentioned above have not changed. The v6 version of this test fixes some nits pointed out by both Tom de Vries and Pedro Alves. One of Pedro's suggestions was to rename the test from check-errno.exp to errno.exp, so in v5, the name has changed. Tom also noticed that there were failures when using --target_board=native-extended-gdbserver. For v6, I've tested on 10 different Linux machines (F38, F39, F39 w/o glibc debuginfo, F39 w/o static glibc, F40, rawhide, Ubuntu 22.04, Leap 15.5, Leap 15.5 w/o glibc debuginfo, and Fedora 34) using "make check" and "make check-read1" using target boards "unix", "native-extended-gdbserver", and "native-gdbserver", with CC_FOR_TARGET set to both gcc and clang, for a total of 12 distinct test runs on each machine. I've also tested the native-only cases on FreeBSD. (Attempting to test against gdbserver on FreeBSD resulted in hangs while running the test suite.) The v7 version of this test simplifies the REs used in the uses of gdb_test_multiple by adding -wrap and removing parts of the REs which match the GDB prompt. In cases where there was a leading '.*', those were removed too. Thanks to Pedro for explaining how to use -wrap. So, bottom line, this test does not introduce any new failures on the platforms on which I've tested, but the XFAILs are certainly unfortunate. Some aren't fixable - e.g. when attempting to make a function call while debugging a core file - but I think that some of them are. I'm using this new test case as a starting point for investigating problems with printing errno. Co-Authored-By: Jan Kratochvil Approved-By: Tom de Vries <tdevries@suse.de>
2024-05-31Move dwarf2_per_bfd::index_addrmap to mapped_gdb_indexTom Tromey5-37/+25
dwarf2_per_bfd::index_addrmap is only used by the .gdb_index reader, so this field can be moved to mapped_gdb_index instead. Then, cooked_index_functions::find_per_cu can be removed in favor of a method on the index object. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31821 Approved-By: Simon Marchi <simon.marchi@efficios.com>
2024-05-31gdb, amd64: remove unused forward declarationsFelix Willgerodt1-12/+0
These structs are not referenced anywhere anymore and seemed to have been missed at some point when their usage was removed. Co-authored-by: Nils-Christian Kempke <nils-christian.kempke@intel.com> Approved-By: Tom Tromey <tom@tromey.com>
2024-05-31gdb, doc: Fix AVX-512 documentation.Felix Willgerodt1-1/+9
org.gnu.gdb.i386.avx512 adds k registers, but these aren't mentioned in the docs yet. Fix that. In addition the documentation describes xmm registers with an `h` (e.g. xmm16h). I am assuming that we follow the register xml files here, which don't have the h suffix. So this removes that as well. Approved-By: Eli Zaretskii <eliz@gnu.org>
2024-05-30gdb: remove unused includes in utils.hSimon Marchi45-6/+45
Remove some includes reported as unused by clangd. Add some includes in other files that were previously relying on the transitive include. Change-Id: Ibdd0a998b04d21362a20d0ca8e5267e21e2e133e
2024-05-30gdb: remove unused includes in symfile.cSimon Marchi1-9/+1
Remove some includes reported as unused by clangd. Change-Id: Iebd986eaf42409f1e526f09df0fcb0ce45c2fad6
2024-05-30gdb: remove unused includes in breakpoint.{c,h}Simon Marchi2-3/+0
Remove some includes reported as unused by clangd. Change-Id: I36d388bcff166f6baafa212f0bcbe8af64b2946d
2024-05-29gdb/doc: don't have .pod targets separate to man page targetsAndrew Burgess1-6/+19
While preparing the new release it was discovered that commit: commit 824083f34c222aa7419e2ea58e82d6f230d5f531 Date: Fri Apr 12 17:47:20 2024 +0100 gdb/doc: use silent-rules.mk in the Makefile was causing problems. Given a release tar file, an attempt to build and install GDB would give an error like this: [...] TEXI2POD gdb.pod cannot find GDBvn.texi at ../../../gdb-15.0.50.20240508/gdb/doc/../../etc/texi2pod.pl line 251, <GEN0> line 16. make[5]: *** [Makefile:663: gdb.pod] Error 2 The problem here is how the man pages are built, and how they are distributed within a release. Within the development (git) tree, the man page files are not part of the source tree, these files are built as needed. Within a release tar file though, the man pages are included. The idea being that a user can build and install GDB, including getting the man pages, without having to install the tools needed to generate the man pages. The man pages are generated in a two step process. First the .texi file is processed with texi2pod to create a .pod file, then this .pod file is processed to create the .1 or .5 man file. Prior to the above commit these two steps were combined into a single recipe, this meant that when a user performed a build/install from a release tree all of the dependencies, as well as the final result, were all present in the source tree, and so nothing needed to be rebuilt. However, the above commit split the two steps apart. Now we had a separate rule for building the .pod files, and the .1/.5 man page files depended on the relevant .pod file. As the .pod files are not shipped in a GDB release, this meant that one of the dependencies of the man page files was now missing. As a result if a user tried to install from a release tree a rebuild of the .pod files would be attempted, and if that succeeded then building the man pages would follow that. Unfortunately, building the .pod files would fail as the GDBvn.texi file, though present in the source tree, was not present in the build tree, which is where it is needed for the .pod file generation to work. To fix this, I propose merging the .pod creation and the .1/.5 man page creation back into a single recipe. Having these two steps split is probably the "cleaner" solution, but makes it harder for us to achieve our goal of shipping the prebuilt man page files. I've added a comment explaining what's going on (such a comment would have prevented this mistake having been made in the first place). One possibly weird thing here is that I have left both an ECHO_TEXI2POD and a ECHO_TEXI2MAN in the rule $(MAN1S) and $(MAN5S) recipes. This is 100% not going to break anything, these just print two different progress messages while executing the recipes, but I'm not sure if this is considered poor style or not. Maybe we're only supposed to have a single ECHO_* per recipe? Anyway, even if this is poor style, I figure it really is just a style thing. We can tweak this later as needed. Otherwise, this commit should fix the current issue blocking the next GDB release. Approved-By: Tom Tromey <tom@tromey.com>
2024-05-28Make tui_win_info::make_window non-virtualTom Tromey1-1/+2
Nothing overrides tui_win_info::make_window, so remove the "virtual". Tested by rebuilding.
2024-05-28Use bool in thread_eventsTom Tromey7-16/+16
This changes target_ops::thread_events and target_thread_events to use 'bool'. The callers were already doing this. Tested by rebuilding. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2024-05-27Re-run make-target-delegates.pyTom Tromey1-8/+6
I re-ran make-target-delegates.py and discovered that the tree was out of sync. This patch corrects the problem.
2024-05-26Update gdb/NEWS after GDB 15 branch creation.Joel Brobecker1-1/+3
This commit a new section for the next release branch, and renames the section of the current branch, now that it has been cut.
2024-05-26Bump version to 16.0.50.DATE-git.Joel Brobecker2-2/+2
Now that the GDB 15 branch has been created, this commit bumps the version number in gdb/version.in to 16.0.50.DATE-git For the record, the GDB 15 branch was created from commit 3a624d9f1c5ccd8cefdd5b7ef12b41513f9006cd. Also, as a result of the version bump, the following changes have been made in gdb/testsuite: * gdb.base/default.exp: Change $_gdb_major to 16.
2024-05-24[gdb/testsuite] Add PR26286 kfail in ↵Tom de Vries1-1/+24
gdb.threads/attach-many-short-lived-threads.exp When running test-case gdb.threads/attach-many-short-lived-threads.exp, I run regularly into PR26286: ... (gdb) continue^M Continuing.^M [LWP ... exited]^M ... [LWP ... exited]^M ^M Program terminated with signal SIGTRAP, Trace/breakpoint trap.^M The program no longer exists.^M (gdb) FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 9: \ break at break_fn: 1 ... Add a kfail for this, such that we have: ... (gdb) KFAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 9: \ break at break_fn: 1 (PRMS: threads/26286) ... Reviewed-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org> Tested on x86_64-linux.
2024-05-23gdb, testsuite: Fix return value in gdb.base/foll-fork.expFelix Willgerodt1-1/+1
In a remote testing setup, I saw this error: ~~~ (gdb) FAIL: gdb.base/foll-fork.exp: check_fork_catchpoints: runto: run to main ERROR: tcl error sourcing gdb/gdb/testsuite/gdb.base/foll-fork.exp. ERROR: expected boolean value but got "" while executing "if { ![check_fork_catchpoints] } { untested "follow-fork not supported" return }" (file "gdb/gdb/testsuite/gdb.base/foll-fork.exp" line 434) invoked from within "source gdb/gdb/testsuite/gdb.base/foll-fork.exp" ("uplevel" body line 1) invoked from within "uplevel #0 source gdb/gdb/testsuite/gdb.base/foll-fork.exp" invoked from within "catch "uplevel #0 source $test_file_name"" Remote debugging from host 172.0.1.3, port 37766 Killing process(es): 1171 Quit ~~~ The actual reason for this were some connection problems. Though the function check_fork_catchpoints shouldn't return an empty string, especially as it promises to always return 0 or 1. Fix that. Approved-By: Tom Tromey <tom@tromey.com>
2024-05-23gdb/testsuite: Restore libc_has_debug_info's less strict behaviourThiago Jung Bauermann1-11/+10
The code that was factored out from gdb.base/relativedebug.exp assumed that libc has debug info and only determined that it doesn't if it saw a specific message from GDB to that effect. In the process of factoring it into a require predicate, I made it stricter by trying to make a specific determination of whether or not debug info is available. Pedro noticed that "It'll disable the testcase on systems that link with their libc statically (even if has debug info), or systems that name their libc something else." Which is something I hadn't considered. This patch returns libc_has_debug_info to the original behaviour. Also, remove a verbose message that is redundant with the $message variable. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31700 Approved-By: Tom Tromey <tom@tromey.com>
2024-05-22Default dwarf_synchronous to trueTom Tromey1-1/+1
Unfortunately the background DWARF reading series introduced a number of races, as repored by thread sanitizer. This patch changes gdb to disable this feature for the time being -- in particular for the gdb 15 release. I've filed a bug and linked all the known races to it. Once those are fixed we can re-enable this feature by default. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31751
2024-05-21Clarify documentation for pretty_printer.childTom Tromey1-2/+3
An Ada pretty-printer had a bug where its 'child' method returned a gdb.Value rather than a tuple. Kévin suggested that the documentation for this method could be improved to clarify this. Reviewed-By: Kévin Le Gouguec <legouguec@adacore.com> Approved-By: Eli Zaretskii <eliz@gnu.org>
2024-05-20gdb: Fix Windows build after #include shuffleKévin Le Gouguec1-0/+1
Without this patch, the build chokes on: ../../src/gdb/windows-nat.c:384:21: error: field 'm_debug_event_pending' has incomplete type 'std::atomic<bool>' 384 | std::atomic<bool> m_debug_event_pending { false }; | ^~~~~~~~~~~~~~~~~~~~~ In file included from […gcc tree…]/include/c++/13.2.1/bits/shared_ptr_atomic.h:33, from […gcc tree…]/include/c++/13.2.1/memory:81, from ../../src/gdb/../gdbsupport/gdb_unique_ptr.h:23, from ../../src/gdb/../gdbsupport/common-utils.h:26, from ../../src/gdb/../gdbsupport/common-defs.h:199, from ./../../src/gdb/defs.h:26, from <command-line>: […gcc tree…]/include/c++/13.2.1/bits/atomic_base.h:174:12: note: declaration of 'struct std::atomic<bool>' 174 | struct atomic; | ^~~~~~ make.exe[2]: *** [Makefile:1947: windows-nat.o] Error 1 Presumably windows-nat.c relied on objfiles.h including <atomic>, which was undone in 2024-05-16 "gdb: remove unused includes in objfiles.{c,h}" (f617661c110).
2024-05-20[gdb/testsuite] Fix can_spawn_for_attach_1 consistency checkTom de Vries1-0/+7
When running test-case gdb.testsuite/gdb-caching-proc-consistency.exp with target board native-gdbserver, we run into: ... (gdb) ERROR: tcl error sourcing gdb.testsuite/gdb-caching-proc-consistency.exp. ERROR: gdbserver does not support attach 4827 without extended-remote while executing "error "gdbserver does not support $command without extended-remote"" (procedure "gdb_test_multiple" line 51) invoked from within "gdb_test_multiple "attach $test_pid" "can spawn for attach" { -re -wrap "$attaching_re\r\n.*ptrace: Operation not permitted\\." { # Not permitte..." (procedure "gdb_real__can_spawn_for_attach_1" line 27) invoked from within "gdb_real__can_spawn_for_attach_1" ... The problem is that: - can_spawn_for_attach_1 is a helper function for can_spawn_for_attach, designed to be called only from that function, and - can_spawn_for_attach_1 is a gdb_caching_proc, and consequently test-case gdb.testsuite/gdb-caching-proc-consistency.exp calls can_spawn_for_attach_1 directly. Fix this by copying the early-outs from can_spawn_for_attach to can_spawn_for_attach_1. Tested on x86_64-linux. Reported-By: Simon Marchi <simark@simark.ca> Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
2024-05-18Remove unnecessary block from execute_fn_to_ui_fileTom Tromey1-14/+12
I noticed that execute_fn_to_ui_file has an extra, unnecessary block. This patch removes it.
2024-05-17Remove gdb_stdtargerrTom Tromey12-21/+3
This patch removes gdb_stdtargerr. There doesn't seem to be a need for this -- it is always the same as stdtarg, and (I believe) has been for many years. Approved-By: Andrew Burgess <aburgess@redhat.com>
2024-05-17Don't allow new-ui to start the TUITom Tromey7-5/+25
The TUI can't really work properly with new-ui, at least not as currently written. This patch changes new-ui to reject an attempt. Attempting to make a DAP ui this way is also now rejected. Regression tested on x86-64 Fedora 38. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29273 Approved-By: Andrew Burgess <aburgess@redhat.com>
2024-05-17Inline some ui_out methodsTom Tromey2-50/+10
I noticed a few ui_out methods that are just trivial wrappers. This patch moves these to ui-out.h, as it seems like they should be inlineable. Approved-By: Andrew Burgess <aburgess@redhat.com>
2024-05-17gdb/symtab: use symbol name matcher for all segments in a qualified nameDmitry Neverov1-10/+25
2024-05-17gdb/symtab: compute match_type outside the loopDmitry Neverov1-2/+3
It will be used for all segments in a qualified name, not only the last one. Approved-By: Tom Tromey <tom@tromey.com>
2024-05-17gdb/symtab: reuse last segment lookup name info by creating it outside the loopDmitry Neverov1-3/+3
2024-05-17gdb/symtab: check name matches before expanding a CUDmitry.Neverov1-3/+19
The added check fixes the case when an unqualified lookup name without template arguments causes expansion of many CUs which contain the name with template arguments. This is similar to what dw2_expand_symtabs_matching_symbol does before expanding the CU. In the referenced issue the lookup name was wxObjectDataPtr and many CUs had names like wxObjectDataPtr<wxBitmapBundleImpl>. This caused their expansion and the lookup took around a minute. The added check helps to avoid the expansion and makes the symbol lookup to return in a second or so. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30520
2024-05-16[gdb/testsuite] Add missing terminator in Dwarf::_macro_unitTom de Vries2-0/+13
When printing complaints with one of the execs from test-case gdb.dwarf2/macro-source-path.exp, we run into: ... $ gdb -q -batch \ -iex "set complaints 100" \ macro-source-path-clang14-dw4-absolute-cwd-32 \ -ex "p main" During symbol reading: debug info runs off end of .debug_macro section \ [in module macro-source-path-clang14-dw4-absolute-cwd-32] $1 = {int ()} 0x4004b7 <main> ... and readelf complains more specifically: ... Contents of the .debug_macro section: Offset: 0 Version: 5 Offset size: 4 Offset into .debug_line: 0xe3 DW_MACRO_define - lineno : 0 macro : ONE 1 DW_MACRO_define_strp - lineno : 0 macro : THREE 3 DW_MACRO_start_file - lineno: 0 filenum: 1 filename: test.c DW_MACRO_define - lineno : 1 macro : TWO 2 DW_MACRO_end_file readelf: Error: .debug_macro section not zero terminated ... Fix this by adding the missing terminator in Dwarf::_macro_unit. Tested on x86_64-linux. Approved-By: Tom Tromey <tom@tromey.com>
2024-05-16gdb: remove unused includes in objfiles.{c,h}Simon Marchi2-9/+0
Remove some includes reported as unused by clangd. Change-Id: I7768232c28b9b86b0a03628a1d15dede2b30c76a
2024-05-16gdb, testsuite: Handle unused compiler option fdiagnostics-color=never.Ijaz, Abdul B1-10/+44
The 'univeral_compile_options' in gdb.exp file only verifies the support of '-fdiagnostics-color=never' for the "C" source file. So while running tests with assembly source file (.s), many of them are not able to run on icx/clang compilers because '-fdiagnostics-color=never' option is not supported. This problem is not seen for the ".S" assembly source files so these files are not handled separately. After this change, this function is split into multiple functions to check the support for different type of sources individually. Before this change, in the case of clang and ICX compiler, this error is shown for assembly source files (.s): ''' icx -fdiagnostics-color=never -Wno-unknown-warning-option -fno-pie -c -O0 -o amd64-entry-value0.o gdb/testsuite/gdb.arch/amd64-entry-value.s (timeout = 300) icx: warning: argument unused during compilation: '-fdiagnostics-color=never' [-Wunused-command-line-argument] gdb compile failed, icx: warning: argument unused during compilation: '-fdiagnostics-color=never' [-Wunused-command-line-argument] UNTESTED: gdb.arch/amd64-entry-value.exp: failed to prepare ''' Similarly this error is shown for the clang compiler: ''' clang -fdiagnostics-color=never -Wno-unknown-warning-option -fno-pie -c -O0 -o amd64-entry-value0.o gdb/testsuite/gdb.arch/amd64-entry-value.s clang: warning: argument unused during compilation: '-fdiagnostics-color=never' [-Wunused-command-line-argument] ''' Approved-By: Tom Tromey <tom@tromey.com>
2024-05-16gdb: define type aliases for `fork_inferior()` callbacksSimon Marchi2-15/+18
The `fork_inferior()` function accepts multiple callbacks, making its signature a bit hard to read. Define some type aliases to make it a bit clearer. Use function view for all, while at it. Change-Id: Ide8d1fa533d0c5eaf3249860f8c0d339baa09bce Approved-By: Tom Tromey <tom@tromey.com>
2024-05-16gdb: initialize packet_result::m_textual_err_msgSimon Marchi1-1/+1
When building GDB with -O2 and --enable-ubsan, I get some random errors in the packet_result self test: /home/smarchi/src/binutils-gdb/gdb/remote.c:161:7: runtime error: load of value 92, which is not a valid value for type 'bool' This happens because packet_result::m_textual_err_msg is uninitialized when using the second constructor. When such a packet_result object gets copied, an invalid value for m_textual_err_msg (a bool field) is loaded, which triggers ubsan. Avoid this by initializing m_textual_err_msg. Change-Id: I3ce44816bb0bfc6e442067292f993e5c17301b85 Approved-By: Tom Tromey <tom@tromey.com>
2024-05-16gdb: remove unused include in infcmd.cSimon Marchi1-1/+0
clangd reports this header as unused. Change-Id: I7bf413f57b2840a52d83bd4f8b9415728bc0917b
2024-05-16gdb: remove unused includes from progspace.{c,h}Simon Marchi2-3/+0
Remove some include files reported as unused by clangd. Change-Id: I39f9d40b9d5bbf040250b41ef258fb8f32dd5c0a
2024-05-16gdb: move lm_info to solib in dsbt_current_sosSimon Marchi1-0/+1
Commit 8971d2788e79 ("gdb: link so_list using intrusive_list") mistakenly removed the line that moves the lm_info unique pointer to sop->lm_info, probably due to a bad conflict resolution. Restore that line. Unfortunately, this code is only used for TI C66, which is not widely tested (if used at all). Change-Id: I9f64eb4430c324bc93ddb4bd00d820dee34adfbb Approved-By: Tom Tromey <tom@tromey.com>
2024-05-16Stop 'configure --enable-threading' if std::thread doesn't workPedro Alves1-3/+11
Currently, if you configure gdb with explicit --enable-threading, but then configure detects std::thread does not work, configure silently disables threading support and continues configuring. This patch makes that scenario cause a configuration error, like so: $ /home/pedro/gdb/src/configure --enable-threading && make ... configure: error: std::thread does not work; disable threading make[1]: *** [Makefile:11225: configure-gdbsupport] Error 1 make[1]: Leaving directory '/home/pedro/gdb/build-windows-threads' make: *** [Makefile:1041: all] Error 2 $ Additionally, if you don't explicitly pass --enable-threading, and std::thread does not work, we will now get a warning (and the build continues): $ /home/pedro/gdb/src/configure && make ... configure: WARNING: std::thread does not work; disabling threading ... This is similar to how we handle --enable-tui and missing curses. The code and error/warning messages were borrowed from there. Change-Id: I73a8b580d1e2a796b23136920c0e181408ae1b22 Approved-By: Tom Tromey <tom@tromey.com>
2024-05-16[gdb/testsuite] Generate DW_MACRO_define_strp in dwarf assemblyTom de Vries2-1/+29
Add support for DW_MACRO_define_strp in dwarf assembly, and use it in test-case gdb.dwarf2/macro-source-path.exp. Tested on x86_64-linux. Approved-By: Tom Tromey <tom@tromey.com>
2024-05-14Add spaceship operator to cp-name-parser.yTom Tromey1-1/+18
While debugging gdb, I saw this: During symbol reading: unexpected demangled name 'operator<=><std::chrono::_V2::system_clock, std::chrono::duration<long int>, std::chrono::duration<long int> >' This happens because cp-name-parser.y does not handle the spaceship operator. This patch implements this. Approved-By: John Baldwin <jhb@FreeBSD.org>
2024-05-14Allow function types as template parameters in name canonicalizerTom Tromey2-7/+4
This adds function types as template parameters in the C++ name canonicalizer. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=11907 Approved-By: John Baldwin <jhb@FreeBSD.org>
generated by cgit v1.1 at 2024-11-13 23:28:51 +0000