aboutsummaryrefslogtreecommitdiff
path: root/gdb
AgeCommit message (Collapse)AuthorFilesLines
2023-01-13Use require !skip_cplus_testsTom Tromey171-265/+171
This changes some tests to use "require !skip_cplus_tests".
2023-01-13Use require is_x86_like_targetTom Tromey18-77/+18
This changes some tests to use "require is_x86_like_target".
2023-01-13Use require dwarf2_supportTom Tromey215-661/+215
This changes some tests to use "require dwarf2_support".
2023-01-13Use require supports_process_recordTom Tromey10-66/+26
This changes some tests to use "require supports_process_record".
2023-01-13Use require supports_reverseTom Tromey30-101/+30
This changes some tests to use "require supports_reverse".
2023-01-13Use unsupported in 'require'Tom Tromey1-1/+1
This changes 'require' to use 'unsupported' rather than 'untested'. The latter doesn't really seem to be correct according to the DejaGNU documentation: Declares a test was not run. `untested' writes in the log file a message beginning with _UNTESTED_, appending the `message' argument. For example, you might use this in a dummy test whose only role is to record that a test does not yet exist for some feature. The example there, and some text elsewhere, is what makes me think this isn't a great fit. On the other hand, 'unsupported' says: Declares that a test case depends on some facility that does not exist in the testing environment.
2023-01-13Change 'require' to accept a list of predicatesTom Tromey11-41/+30
This changes 'require' to accept a list of simple predicates. For now, each predicate is just the name of a proc, optionally prefixed with "!" to indicate that the result should be inverted. It's possible to make this fancier, but so far I haven't done so. One idea I had is to allow a predicate to have associated text to display on failure. Another is to convert the predicates that need a running gdb (e.g., skip_python_tests) to start their own gdb, and then 'require' could enforce the rule that gdb not be running when it is called.
2023-01-13Don't use ensure_gdb_index with requireTom Tromey6-6/+24
This series changes 'require' to take a list of simple predicates. This patch backs out the one use of 'require' that doesn't conform to this -- calling ensure_gdb_index.
2023-01-13gdb/infrun: add debug print in print_signal_received_reasonAndrew Burgess1-0/+2
It would have helped me to see an infrun debug line being printed from print_signal_received_reason, so I'm adding one.
2023-01-13gdb: int to bool conversion for normal_stopAndrew Burgess3-9/+7
Change the return type of normal_stop (infrun.c) from int to bool. Update callers. I've also converted the (void) to () in the function declaration and definition, given I was changing those lines anyway. There should be no user visible changes after this commit.
2023-01-12Disable ptype/o for dynamic typesTom Tromey3-0/+82
A user pointed out that "ptype/o" of a certain Ada type -- while in C mode -- caused gdb to crash. The bug here is that dynamic types can't really be printed this way. This patch avoids the bug by disabling the "/o" feature in this case. Note that using "ptype/o" in this way makes sense for the time being, because the Ada code doesn't support the "/o" feature (yet); and in any case gdb should not crash.
2023-01-11gdb/doc: fix install-html with Texinfo 7Simon Marchi1-3/+12
Starting with Texinfo 7 (this commit [1]), the output directory for the HTML doc format is gdb/doc/gdb_html, rather than gdb/doc/gdb previously. This breaks the install-html target, which expects the HTML doc to be in gdb/doc/gdb: $ make install-html MAKEINFO=makeinfo DESTDIR=/tmp/install make[1]: Entering directory '/home/simark/build/binutils-gdb/gdb' make[2]: Entering directory '/home/simark/build/binutils-gdb/gdb/doc' makeinfo -DHAVE_MAKEINFO_CLICK --html -I /home/simark/src/binutils-gdb/gdb/doc/../../readline/readline/doc -I /home/simark/src/binutils-gdb/gdb/doc/../mi -I /home/simark/src/binutils-gdb/gdb/doc /home/simark/src/binutils-gdb/gdb/doc/gdb.texinfo makeinfo -DHAVE_MAKEINFO_CLICK --html -I /home/simark/src/binutils-gdb/gdb/doc /home/simark/src/binutils-gdb/gdb/doc/stabs.texinfo makeinfo -DHAVE_MAKEINFO_CLICK --html -I /home/simark/src/binutils-gdb/gdb/doc /home/simark/src/binutils-gdb/gdb/doc/annotate.texinfo test -z "/usr/local/share/doc/gdb" || /bin/sh /home/simark/src/binutils-gdb/gdb/doc/../../mkinstalldirs "/tmp/install/usr/local/share/doc/gdb" /usr/bin/install -c -m 644 '/home/simark/src/binutils-gdb/gdb/doc/gdb' '/tmp/install/usr/local/share/doc/gdb/gdb' /usr/bin/install: cannot stat '/home/simark/src/binutils-gdb/gdb/doc/gdb': No such file or directory /usr/bin/install -c -m 644 '/home/simark/src/binutils-gdb/gdb/doc/stabs' '/tmp/install/usr/local/share/doc/gdb/stabs' /usr/bin/install: cannot stat '/home/simark/src/binutils-gdb/gdb/doc/stabs': No such file or directory /usr/bin/install -c -m 644 '/home/simark/src/binutils-gdb/gdb/doc/annotate' '/tmp/install/usr/local/share/doc/gdb/annotate' /usr/bin/install: cannot stat '/home/simark/src/binutils-gdb/gdb/doc/annotate': No such file or directory make[2]: *** [Makefile:278: install-html] Error 1 make[2]: Leaving directory '/home/simark/build/binutils-gdb/gdb/doc' make[1]: *** [Makefile:2240: subdir_do] Error 1 make[1]: Leaving directory '/home/simark/build/binutils-gdb/gdb' make: *** [Makefile:2006: install-html] Error 2 Fix this by adding -o switches to the HTML targets, to force the output directories. [1] https://git.savannah.gnu.org/cgit/texinfo.git/commit/?id=a868421baf9c44227c43490687f8d6b8d6c95414 Change-Id: Ie147dc7b4a52eb2348005b8dc006a41b0784621f
2023-01-11gdb: Update gdbarch.py with latest changes in gdbarch.cThiago Jung Bauermann1-3/+3
Commit 2b16913cdca2 ("gdb: make gdbarch_alloc take ownership of the tdep") changed gdbarch.c without updating gdbarch.py. As a result, running gdbarch.py reverts those changes and causes the build to fail. So change gdbarch.py to generate the current version of gdbarch.c. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-01-11Set _WIN32_WINNT in common.m4 configure checkTom Tromey1-1/+11
GCC recently added support for the Windows thread model, enabling libstdc++ to support Windows natively. However, this supporrt requires a version of Windows later than the minimum version that is supported by GDB. PR build/29966 points out that the GDB configure test for std::thread does not work in this situation, because _WIN32_WINNT is not defined in test program, and so <thread> seems to be fine. This patch is an attempt to fix the problem, by using the same setting for _WIN32_WINNT at configure time as is used at build time. I don't have access to one of the older systems so I don't think I can truly test this. I did do a mingw cross build, though. I'm going to ask the bug reporter to test it. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29966
2023-01-11[gdb/testsuite] Fix regexp in gdb.threads/dlopen-libpthread.expSimon Marchi1-2/+2
Fix regexp in gdb.threads/dlopen-libpthread.exp: 'libpthread\\.so' -> '/libpthread\\.so'. Tested on x86_64-linux.
2023-01-11[gdb/testsuite] Fix gdb.threads/dlopen-libpthread.exp for upstream glibc, againTom de Vries2-6/+41
On an x86_64 laptop running ubuntu 22.04.1 with unity desktop: ... $ echo $XDG_CURRENT_DESKTOP Unity:Unity7:ubuntu ... I have: ... $ echo $LD_PRELOAD libgtk3-nocsd.so.0 ... due to package gtk3-nocsd, a package recommended by unity-session. Consequently, for each exec these dependencies are pulled in, including libpthread.so.0: ... $ lddtree /lib/x86_64-linux-gnu/libgtk3-nocsd.so.0 libgtk3-nocsd.so.0 => /lib/x86_64-linux-gnu/libgtk3-nocsd.so.0 (interpreter => none) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 ld-linux-x86-64.so.2 => /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 ... So, while test-case gdb.threads/dlopen-libpthread.exp appears to run ok: ... # of expected passes 12 # of unsupported tests 1 ... with LD_PRELOAD="" we have instead: ... (gdb) PASS: gdb.threads/dlopen-libpthread.exp: continue to breakpoint: notify info sharedlibrary^M From To Syms Read Shared Object Library^M $hex $hex Yes /lib64/ld-linux-x86-64.so.2^M $hex $hex Yes /lib/x86_64-linux-gnu/libc.so.6^M $hex $hex Yes dlopen-libpthread.so^M (gdb) FAIL: gdb.threads/dlopen-libpthread.exp: libpthread.so found ... The problem is that libpthread is expected as dependency of dlopen-libpthread.so, but it's missing: ... $ lddtree dlopen-libpthread.so dlopen-libpthread.so => ./dlopen-libpthread.so (interpreter => none) libc.so.6 => $outputs/gdb.threads/dlopen-libpthread/dlopen-libpthread.so.d/libc.so.6 ld-linux-x86-64.so.2 => /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 ... due to having glibc 2.35, which has libpthread integrated into libc. Fix this by: - adding a proc has_dependency - using [has_dependency $exec libpthread.so] as hint that libpthread may be preloaded - using ![has_dependency $shlib libpthread.so] to detect that the libpthread.so dependency is missing. Also add a missing return after untested "no matching probes". Tested on x86_64-linux, with and without LD_PRELOAD="".
2023-01-10Fix bug in 'say_where' transformTom Tromey1-2/+2
The patch to change say_where into a method introduced a bug. This patch fixes it.
2023-01-10gdb/dwarf2: Fix 'rw_pieced_value' for values casted to different type.Rohr, Stephan2-4/+51
The 'rw_pieced_value' function is executed when fetching a (lazy) variable described by 'DW_OP_piece' or 'DW_OP_bit_piece'. The function checks the 'type' and 'enclosing_type' fields of the value for identity. * The 'type' field describes the type of a value. * In most cases, the 'enclosing_type' field is identical to the 'type' field. * Scenarios where the 'type' and 'enclosing_type' of an object differ are described in 'gdb/value.c'. Possible cases are: * If a value represents a C++ object, then the 'type' field gives the object's compile-time type. If the object actually belongs to some class derived from `type', perhaps with other base classes and additional members, then `type' is just a subobject of the real thing, and the full object is probably larger than `type' would suggest. * If 'type' is a dynamic class (i.e. one with a vtable), then GDB can actually determine the object's run-time type by looking at the run-time type information in the vtable. GDB may then elect to read the entire object. * If the user casts a variable to a different type (e.g. 'print (<type> []) <variable>'), the value's type is updated before reading the value. If a lazy value is fetched, GDB allocates space based on the enclosing type's length and typically reads the 'full' object. This is not implemented for pieced values and causes an internal error if 'type' and 'enclosing_type' of a value are not identical. However, GDB can read the value based on its type. Thus, this patch fixes the previously mentioned cases by removing the check for identity. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28605 gdb/ChangeLog: 2022-04-13 Stephan Rohr <stephan.rohr@intel.com> * dwarf2/loc.c (rw_pieced_value): Fix check on 'type' and 'enlcosing_type' when reading pieced value 'v'. gdb/testsuite/ChangeLog: 2022-04-13 Stephan Rohr <stephan.rohr@intel.com> * gdb.dwarf2/shortpiece.exp: Added test cases.
2023-01-10Convert say_where to method on code_breakpointTom Tromey2-25/+28
'say_where' is only useful (and only called for) code breakpoints, so convert it to be a protected method on code_breakpoint.
2023-01-10gdb/doc: use @value{GDBP} in some spotsSimon Marchi1-117/+117
Examples are supposed to use @value{GDBP} instead of the literal "(gdb)" (many of them already do). Update a bunch of spots where it wasn't the case. Change-Id: I601adaad61fd277a5fceea1759e49cede72e456d
2023-01-10gdb/doc: use @value{GDBN} in some spotsSimon Marchi1-4/+4
Change some spots to use "@value{GDBN}" instead of just "GDB". Change-Id: I3fc26438e603538271cf33e4d148be5fda9ece7e
2023-01-10gdb/doc: some whitespace fixesSimon Marchi2-24/+24
For consistency, replace tabs with spaces in all gdb.texinfo menus. Change-Id: I0801a72cf82a8afe49ec842244f42d30719634ce
2023-01-09gdb/linespec.c: Fix missing source file during breakpoint re-setAaron Merey2-2/+11
During breakpoint re-setting, the source_filename of an explicit_location_spec is used to lookup the symtabs associated with the breakpoint being re-set. This source_filename is compared with each known symtab filename in order to retrieve the breakpoint's symtabs. However the source_filename may have been originally copied from a symtab's fullname (the path where GDB found the source file) when the breakpoint was first created. If a breakpoint symtab's filename and fullname differ and there is no substitute-path rule that converts the fullname to the filename, this will cause a NOT_FOUND_ERROR to be thrown during re-setting. Fix this by using a symtab's filename to set the explicit_location_spec source_filename instead of the symtab's fullname.
2023-01-09gdb/linespec.c: Fix -Wmaybe-uninitialized warningAaron Merey1-1/+1
Although the bool want_start_sal isn't actually used without being assigned a value, initialize it to be false in order to prevent the following -Wmaybe-uninitialized warning: linespec.c: In function ‘void minsym_found(linespec_state*, objfile*, minimal_symbol*, std::vector<symtab_and_line>*)’: linespec.c:4150:19: warning: ‘want_start_sal’ may be used uninitialized [-Wmaybe-uninitialized] 4150 | if (is_function && want_start_sal)
2023-01-09Fix crash with C++ qualified namesTom Tromey2-0/+3
PR c++/29503 points out that something like "b->Base::member" will crash when 'b' does not have pointer type. This seems to be a simple oversight in eval_op_member. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29503 Reviewed-By: Bruno Larsen <blarsen@redhat.com>
2023-01-09gdb/doc: fix @code{GDBN} -> @value{GDBN}Simon Marchi1-1/+1
Change-Id: I928d6f8d6e6bc41d8c7ddbfae8f6ae0614f4993e
2023-01-09testsuite: add -O0 to Intel compilers if no 'optimize' option is givenTankut Baris Aktemur1-0/+41
icpx/icx give the following warning if '-g' is used without '-O'. icpx: remark: Note that use of '-g' without any optimization-level option will turn off most compiler optimizations similar to use of '-O0'; use '-Rno-debug-disables-optimization' to disable this remark [-Rdebug-disables-optimization] The warning makes dejagnu think that compilation has failed. E.g.: $ make check TESTS="gdb.cp/local.exp" RUNTESTFLAGS="CXX_FOR_TARGET='icpx' CC_FOR_TARGET=icx" ... gdb compile failed, icpx: remark: Note that use of '-g' without any optimization-level option will turn off most compiler optimizations similar to use of '-O0'; use '-Rno-debug-disables-optimization' to disable this remark [-Rdebug-disables-optimization] === gdb Summary === # of untested testcases 1 Furthermore, if no -O flag is passed, icx/icc optimize the code by default. This breaks assumptions in many GDB tests that the code is unoptimized by default. E.g.: $ make check TESTS="gdb.cp/cmpd-minsyms.exp" RUNTESTFLAGS="CXX_FOR_TARGET='icpx' CC_FOR_TARGET=icx" ... FAIL: gdb.cp/cmpd-minsyms.exp: gdb_breakpoint: set breakpoint at 'GDB<int>::a() const' FAIL: gdb.cp/cmpd-minsyms.exp: gdb_breakpoint: set breakpoint at 'GDB<int>::b() volatile' FAIL: gdb.cp/cmpd-minsyms.exp: gdb_breakpoint: set breakpoint at 'GDB<int>::c() const volatile' FAIL: gdb.cp/cmpd-minsyms.exp: gdb_breakpoint: set breakpoint at GDB<int>::operator == FAIL: gdb.cp/cmpd-minsyms.exp: gdb_breakpoint: set breakpoint at GDB<int>::operator==(GDB<int> const&) FAIL: gdb.cp/cmpd-minsyms.exp: gdb_breakpoint: set breakpoint at GDB<char>::harder(char) FAIL: gdb.cp/cmpd-minsyms.exp: gdb_breakpoint: set breakpoint at GDB<int>::harder(int) FAIL: gdb.cp/cmpd-minsyms.exp: gdb_breakpoint: set breakpoint at "int GDB<char>::even_harder<int>(char)" FAIL: gdb.cp/cmpd-minsyms.exp: gdb_breakpoint: set breakpoint at GDB<int>::simple() === gdb Summary === # of expected passes 1 # of unexpected failures 9 To fix both problems, pass the -O0 flag explicitly, if no optimization option is given. With this patch we get, e.g.: $ make check TESTS="gdb.cp/cmpd-minsyms.exp gdb.cp/local.exp" RUNTESTFLAGS="CXX_FOR_TARGET='icpx' CC_FOR_TARGET=icx" ... === gdb Summary === # of expected passes 19 # of known failures 1 Approved-By: Tom Tromey <tom@tromey.com>
2023-01-09testsuite: handle icc and icpc deprecated remarksNils-Christian Kempke1-7/+30
Starting with icc/icpc version 2021.7.0 and higher both compilers emit a deprecation remark when used. E.g. >> icc --version icc: remark #10441: The Intel(R) C++ Compiler Classic (ICC) is deprecated and will be removed from product release in the second half of 2023. The Intel(R) oneAPI DPC++/C++ Compiler (ICX) is the recommended compiler moving forward. Please transition to use this compiler. Use '-diag-disable=10441' to disable this message. icc (ICC) 2021.7.0 20220713 Copyright (C) 1985-2022 Intel Corporation. All rights reserved. >> icpc --version icpc: remark #10441: The Intel(R) C++ Compiler Classic (ICC) is deprecated ... icpc (ICC) 2021.7.0 20220720 Copyright (C) 1985-2022 Intel Corporation. All rights reserved. As the testsuite compile fails when unexpected output by the compiler is seen this change in the compiler breaks all existing icc and icpc tests. This patch makes the gdb testsuite more forgiving by a) allowing the output of the remark when trying to figure out the compiler version and by b) adding '-diag-disable=10441' to the compile command whenever gdb_compile is called without the intention to detect the compiler. Approved-By: Tom Tromey <tom@tromey.com>
2023-01-06gdb/c++: Detect ambiguous variables in imported namespacesBruno Larsen2-27/+83
When running gdb.cp/nsusing.cc and stopping at line 17, we can ask GDB to print x and get a compiler-dependent answer. Using gcc 12.2.1, GDB will print M::x, and using clang 16.0.0 prints N::x. Not only is this behavior confusing to users, it is also not consistent with compiler behaviors, which would warn that using x is ambiguous at this point. This commit makes GDB behavior consistent with compilers. it achieves this by making it so instead of exiting early when finding any symbol with the correct name, GDB continues searching through all include directives, storing all matching symbols in a relational map betwen the mangled name and the found symbols. If the resulting map has more than one entry, GDB says that the reference is ambiguous and lists all possibilities. Otherwise it returns the block_symbol structure for the desired symbol, or an empty struct if nothing was found. The commit also changes gdb.cp/nsusing.exp to test the ambiguous detection.
2023-01-06gdb/mi: add no-history stop reasonBruno Larsen6-2/+14
When executing in reverse and runs out of recorded history, GDB prints a warning to the user, but does not add a reason in the stopped record, for example: *stopped,frame={addr="0x000000000040113e",func="main",args=[],file="/home/blarsen/Documents/fsf_build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.reverse/solib-reverse.c",fullname="/home/blarsen/Documents/binutils-gdb/gdb/testsuite/gdb.reverse/solib-reverse.c",line="27",arch="i386:x86-64"},thread-id="1",stopped-threads="all",core="1" This problem was reported as record/29260. This commit adds the reason no-history to the record, making it easier for interfaces using the mi interpreter to report the result. It also changes the test gdb.mi/mi-reverse.exp to test that the reason shows up correctly. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29260
2023-01-06gdb/testsuite: Fix FAILs in gdb.linespec/cpcompletion.exp when using clangBruno Larsen1-15/+18
When using clang 16.0.0 to test gdb.linespec/cpcompletion.exp, I get 99 unexpected failures. They all fail to produce a complete list of completion options for a function, either overload2_function, overload3_function or anon_ns_function. This happens because clang is optimizing them away, since they are never used. Fix this by adding __attribute__((used)) to all declarations to the aforementioned functions.
2023-01-05gdbsupport: add gdb::string_view_hashSimon Marchi1-1/+1
Add the string_view_hash type, which will be useful to be able to use gdb::string_view as std::unordered_map keys. Use it in gdb/symtab.c, to exercise it. Change-Id: Id69a466ab19a9f6620b5df8a2dd29b5cddd94c00 Approved-By: Andrew Burgess <aburgess@redhat.com>
2023-01-05gdbsupport: move fast_hash to gdbsupport/common-utils.hSimon Marchi1-19/+0
The following patch adds a hash type for gdb::string_view in gdbsupport, which will use the fast_hash function. Move the latter to gdbsupport. Change-Id: Id74510e17801e775bd5ffa5f443713d79adf14ad Approved-By: Andrew Burgess <aburgess@redhat.com>
2023-01-05gdbsupport: move libxxhash configure check to gdbsupportSimon Marchi2-537/+514
The following patch moves the fast_hash function, which uses libxxhash, to gdbsupport. Move the libxxhash configure check to gdbsupport (and transitively to gdbserver). Change-Id: I242499e50c8cd6fe9f51e6e92dc53a1b3daaa96e Approved-By: Andrew Burgess <aburgess@redhat.com>
2023-01-05gdb: make gdbarch_alloc take ownership of the tdepSimon Marchi46-149/+148
It's currently not clear how the ownership of gdbarch_tdep objects works. In fact, nothing ever takes ownership of it. This is mostly fine because we never free gdbarch objects, and thus we never free gdbarch_tdep objects. There is an exception to that however: when initialization fails, we do free the gdbarch object that is not going to be used, and we free the tdep too. Currently, i386 and s390 do it. To make things clearer, change gdbarch_alloc so that it takes ownership of the tdep. The tdep is thus automatically freed if the gdbarch is freed. Change all gdbarch initialization functions to pass a new gdbarch_tdep object to gdbarch_alloc and then retrieve a non-owning reference from the gdbarch object. Before this patch, the xtensa architecture had a single global instance of xtensa_gdbarch_tdep. Since we need to pass a dynamically allocated gdbarch_tdep_base instance to gdbarch_alloc, remove this global instance, and dynamically allocate one as needed, like we do for all other architectures. Make the `rmap` array externally visible and rename it to the less collision-prone `xtensa_rmap` name. Change-Id: Id3d70493ef80ce4bdff701c57636f4c79ed8aea2 Approved-By: Andrew Burgess <aburgess@redhat.com>
2023-01-05gdb/testsuite: add back needed -re clause in gdb_breakpointSimon Marchi1-0/+6
Commit 4b9728be ("gdb: use gdb_test_multiple in gdb_breakpoint") caused, amongst others: (gdb) break 1^M No line 1 in the current file.^M Make breakpoint pending on future shared library load? (y or [n]) n^M (gdb) FAIL: gdb.dwarf2/dw2-main-no-line-number.exp: gdb_breakpoint: set breakpoint at 1 FAIL: gdb.dwarf2/dw2-main-no-line-number.exp: !$breakpoint_at_missing_lineno_set This is because it removed one empty -re clause (matching just the prompt) that is necessary after replying "n" to the pending breakpoint question. Add this clause back. Change-Id: Ibfaa059d58bbea660bc29f0547e2f75c323fcbc6 Approved-By: Tom de Vries <tdevries@suse.de>
2023-01-05[gdb/python] Avoid queue.SimpleQueue for python 3.6Tom de Vries2-2/+10
On openSUSE Leap 15.4 with python 3.6, the gdb.dap/basic-dap.exp test-case fails as follows: ... ERROR: eof reading json header while executing "error "eof reading json header"" invoked from within "expect { -i exp19 -timeout 10 -re "^Content-Length: (\[0-9\]+)\r\n" { set length $expect_out(1,string) exp_continue } -re "^(\[^\r\n\]+)..." ("uplevel" body line 1) invoked from within "uplevel $body" NONE eof reading json header UNRESOLVED: gdb.dap/basic-dap.exp: startup - initialize ... Investigation using a "catch throw" shows that: ... (gdb) at gdb/python/py-utils.c:396 396 error (_("Error occurred in Python: %s"), msg.get ()); (gdb) p msg.get () $1 = 0x2b91d10 "module 'queue' has no attribute 'SimpleQueue'" ... The python class queue.SimpleQueue was introduced in python 3.7. Fix this by falling back to queue.Queue for python <= 3.6. Tested on x86_64-linux, by successfully running the test-case: ... # of expected passes 47 ...
2023-01-05Add type to expression dump of symbolTom Tromey1-0/+1
I recently had cause to dump some expressions from gdb. I got output like this: Operation: BINOP_GTR Operation: OP_VAR_VALUE Block symbol: Symbol: small_value Block: 0x39b4c20 Operation: OP_LONG Operation: OP_LONG Type: int Constant: 0x0000000000000014 This is ok, but it would have been handy to see the type of the symbol. This patch adds this information. Reviewed-By: Bruno Larsen <blarsen@redhat.com>
2023-01-04gdb: ensure test_name is initialized in gdb_breakpointLancelot SIX1-1/+2
A refactoring in 4b9728bec15 (gdb: use gdb_test_multiple in gdb_breakpoint) left the $test_name variable undefined. This patch fixes this. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-01-04Use first_opcode in another spotTom Tromey1-1/+1
I found one place that could use expression::first_opcode. Reviewed-By: Lancelot Six <lancelot.six@amd.com>
2023-01-04Convert exp_uses_objfile to a method of expressionTom Tromey6-17/+16
This changes the exp_uses_objfile function to be a method of 'expression'. Reviewed-By: Lancelot Six <lancelot.six@amd.com>
2023-01-04gdb: use gdb_test_multiple in gdb_breakpointSimon Marchi1-34/+2
When running the testsuite in a non-optimized build on a slow machine, I sometimes get: UNTESTED: gdb.gdb/selftest.exp: Cannot set breakpoint at captured_main, skipping testcase. do_self_tests, in lib/selftest-support.exp, uses `with_timeout_factor 10`, to account for the fact that reading the debug info of the gdb binary (especially in a non-optimized GDB) can take time. But then it ends up calling gdb_breakpoint, which uses gdb_expect with a hard-coded timeout of 30 seconds. Fix this by making gdb_breakpoint use gdb_test_multiple, which is a desired change anyway for this kind of simple command / expected output case. Change-Id: I9b06ce991cc584810d8cc231b2b4893980b8be75 Reviewed-By: Lancelot Six <lancelot.six@amd.com>
2023-01-04gdb: fix some #ifdef logic in bt-utils.hAndrew Burgess1-1/+1
In passing I spotted some incorrect #ifdef logic in bt-utils.h. The logic in question has existed since the file was originally added in commit: commit abbbd4a3e0ca51132e7fb31a43f896d29894dae0 Date: Wed Aug 11 13:24:33 2021 +0100 gdb: use libbacktrace to create a better backtrace for fatal signals The code is trying to select between using libbacktrace or using the execinfo supplied backtrace API. First we check to see if we can use libbacktrace. If we can then we include some header files, and then set some defines to indicate that libbacktrace is being used. Then we check if execinfo is available, if it is then we include <execinfo.h> and set some alternative defines. In theory the second block of logic should not trigger if the first block (that uses libbacktrace) has also triggered, but we incorrectly check the define 'PRINT_BACKTRACE_ON_FATAL_SIGNAL' instead of checking for 'GDB_PRINT_INTERNAL_BACKTRACE_USING_LIBBACKTRACE', so the second block triggers more than it should. The 'PRINT_BACKTRACE_ON_FATAL_SIGNAL' define is not defined anywhere, this was a mistake in the original commit. In reality this is harmless, we include <execinfo.h> when we don't need too, but in by-utils.c the libbacktrace define is always checked for before the execinfo define, so we never actually end up using the execinfo path (when libbacktrace is available). But I figure its still worth cleaning this up. I've tested GDB in a "default" build where libbacktrace is used, and when configuring with --disable-libbacktrace which causes the execinfo backtrace API to be used instead, both still appear to work fine. There should be no user visible changes after this commit.
2023-01-04gdb: add 'maintenance print record-instruction' commandBruno Larsen5-0/+211
While chasing some reverse debugging bugs, I found myself wondering what was recorded by GDB to undo and redo a certain instruction. This commit implements a simple way of printing that information. If there isn't enough history to print the desired instruction (such as when the user hasn't started recording yet or when they request 2 instructions back but only 1 was recorded), GDB warns the user like so: (gdb) maint print record-instruction Not enough recorded history If there is enough, GDB prints the instruction like so: (gdb) maint print record-instruction 4 bytes of memory at address 0x00007fffffffd5dc changed from: 01 00 00 00 Register eflags changed: [ IF ] Register rip changed: (void (*)()) 0x401115 <main+15> Approved-by: Eli Zaretskii <eliz@gnu.org> Reviewed-by: Alexandra Hajkova <ahajkova@redhat.com> Reviewed-by: Lancelot Six <lsix@lancelotsix.com> Approved-by: Tom Tromey <tom@tromey.com>
2023-01-03Add test case for "finish" with variably-sized typesTom Tromey5-2/+123
This adds a test case for "finish" with variably-sized types, and for inferior calls as well. This also extends the "runto" proc to handle temporary breakpoints.
2023-01-03Use value_at_non_lval in get_call_return_valueTom Tromey1-6/+1
get_call_return_value can handle RETURN_VALUE_STRUCT_CONVENTION, because the call is completely managed by gdb. However, it does not handle variably-sized types correctly. The simplest way to fix this is to use value_at_non_lval, which does type resolution.
2023-01-03Fix inferior calls with variably-sized return typeTom Tromey7-89/+91
This patch updates the gdbarch_return_value_as_value implementations to work correctly with variably-sized return types.
2023-01-03Convert selected architectures to gdbarch_return_value_as_valueTom Tromey9-20/+81
This converts a few selected architectures to use gdbarch_return_value_as_value rather than gdbarch_return_value. The architectures are just the ones that I am able to test. This patch should not introduce any behavior changes.
2023-01-03Don't let property evaluation affect the current languageTom Tromey1-0/+5
On PPC, we saw that calling an inferior function could sometimes change the current language, because gdb would select the call dummy frame -- associated with _start. This patch changes gdb so that the current language is never affected by DWARF property evaluation.
2023-01-03Introduce value_at_non_lvalTom Tromey2-0/+14
In some cases, while a value might be read from memory, gdb should not record the value as being equivalent to that memory. In Ada, the inferior call code will call ada_convert_actual -- and here, if the argument is already in memory, that address will simply be reused. However, for a call like "f(g())", the result of "g" might be on the stack and thus overwritten by the call to "f". This patch introduces a new function that is like value_at but that ensures that the result is non-lvalue.
generated by cgit v1.1 at 2024-10-17 00:06:32 +0000