| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This changes some tests to use "require !skip_ada_tests".
|
|
This changes some tests to use "require !skip_fortran_tests".
|
|
This changes some tests to use "require !skip_rust_tests".
|
|
This changes some tests to use "require !skip_stl_tests".
|
|
This changes some tests to use "require !skip_dlmopen_tests".
|
|
This changes some tests to use "require !skip_shlib_tests".
|
|
This changes some tests to use "require !skip_cplus_tests".
|
|
This changes some tests to use "require is_x86_like_target".
|
|
This changes some tests to use "require dwarf2_support".
|
|
This changes some tests to use "require supports_process_record".
|
|
This changes some tests to use "require supports_reverse".
|
|
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.
|
|
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.
|
|
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.
|
|
It would have helped me to see an infrun debug line being printed from
print_signal_received_reason, so I'm adding one.
|
|
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.
|
|
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.
|
|
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
|
|
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>
|
|
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
|
|
Fix regexp in gdb.threads/dlopen-libpthread.exp:
'libpthread\\.so' -> '/libpthread\\.so'.
Tested on x86_64-linux.
|
|
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="".
|
|
The patch to change say_where into a method introduced a bug. This
patch fixes it.
|
|
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.
|
|
'say_where' is only useful (and only called for) code breakpoints, so
convert it to be a protected method on code_breakpoint.
|
|
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
|
|
Change some spots to use "@value{GDBN}" instead of just "GDB".
Change-Id: I3fc26438e603538271cf33e4d148be5fda9ece7e
|
|
For consistency, replace tabs with spaces in all gdb.texinfo menus.
Change-Id: I0801a72cf82a8afe49ec842244f42d30719634ce
|
|
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.
|
|
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)
|
|
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>
|
|
Change-Id: I928d6f8d6e6bc41d8c7ddbfae8f6ae0614f4993e
|
|
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>
|
|
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>
|
|
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.
|
|
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
|
|
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.
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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
...
|
|
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>
|
|
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>
|
|
I found one place that could use expression::first_opcode.
Reviewed-By: Lancelot Six <lancelot.six@amd.com>
|
|
This changes the exp_uses_objfile function to be a method of
'expression'.
Reviewed-By: Lancelot Six <lancelot.six@amd.com>
|
|
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>
|
|
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.
|
|
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>
|
