| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This changes skip_perf_tests to invert the sense, and renames it to
allow_perf_tests.
|
|
This changes skip_opencl_tests to invert the sense, and renames it to
allow_opencl_tests.
|
|
This changes skip_ifunc_tests to invert the sense, and renames it to
allow_ifunc_tests.
|
|
This changes skip_hw_watchpoint_tests to invert the sense, and renames
it to allow_hw_watchpoint_tests.
|
|
This changes skip_hw_watchpoint_multi_tests to invert the sense, and
renames it to allow_hw_watchpoint_multi_tests.
|
|
This changes skip_hw_watchpoint_access_tests to invert the sense, and
renames it to allow_hw_watchpoint_access_tests.
|
|
This changes skip_go_tests to invert the sense, and renames it to
allow_go_tests.
|
|
This changes skip_gdbserver_tests to invert the sense, and renames it
to allow_gdbserver_tests.
|
|
This changes skip_fortran_tests to invert the sense, and renames it to
allow_fortran_tests.
|
|
This changes skip_d_tests to invert the sense, and renames it to
allow_d_tests.
|
|
This changes skip_dlmopen_tests to invert the sense, and renames it to
allow_dlmopen_tests.
|
|
This changes skip_debuginfod_tests to invert the sense, and renames it
to allow_debuginfod_tests.
|
|
This changes skip_ctf_tests to invert the sense, and renames it to
allow_ctf_tests.
|
|
This changes skip_cplus_tests to invert the sense, and renames it to
allow_cplus_tests. This one also converts skip_stl_tests to
allow_stl_tests, as that was convenient to do at the same time.
|
|
This changes skip_btrace_tests to invert the sense, and renames it to
allow_btrace_tests.
|
|
This changes skip_btrace_pt_tests to invert the sense, and renames it
to allow_btrace_pt_tests.
|
|
This changes skip_avx512fp16_tests to invert the sense, and renames it
to allow_avx512fp16_tests.
|
|
This changes skip_avx512bf16_tests to invert the sense, and renames it
to allow_avx512bf16_tests.
|
|
This changes skip_ada_tests to invert the sense, and renames it to
allow_ada_tests.
|
|
This changes skip_aarch64_sve_tests to invert the sense, and renames
it to allow_aarch64_sve_tests.
|
|
This changes gdb_skip_xml_test to invert the sense, and renames it to
allow_xml_test.
|
|
default_prompt_gdb_start mimics default_gdb_start, but does not set
the use_gdb_stub global. This caused one Python test to work only
because it used the ordinary gdb_start before later using
default_prompt_gdb_start.
This patch updates default_prompt_gdb_start to set this global as
well.
|
|
mi_skip_python_tests was necessary because skip_python_tests used the
running gdb, and so needed to know what prompt to expect. Now that
skip_python_tests has been rewritten, mi_skip_python_tests is no
longer needed.
|
|
This rewrites skip_python_tests to examine the output of
"gdb --configuration". This is a bit nicer because it
does not require an already-running gdb.
|
|
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.
|
|
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="".
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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.
|
|
On a x86_64-linux machine with pkru register, I run into:
...
(gdb) PASS: gdb.arch/i386-pkru.exp: set pkru value
info register pkru^M
pkru 0x12345678 305419896^M
(gdb) FAIL: gdb.arch/i386-pkru.exp: read value after setting value
...
This is a regression due to kernel commit e84ba47e313d ("x86/fpu: Hook up PKRU
onto ptrace()"). This is fixed by recent kernel commit 4a804c4f8356
("x86/fpu: Allow PKRU to be (once again) written by ptrace.").
The regression occurs for kernel versions v5.14-rc1 (the first tag containing
the regression) up to but excluding v6.2-rc1 (the first tag containing the fix).
Fix this by adding an xfail for the appropriate kernel versions.
Tested on x86_64-linux.
PR testsuite/29790
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29790
|
|
The Debugger Adapter Protocol is a JSON-RPC protocol that IDEs can use
to communicate with debuggers. You can find more information here:
https://microsoft.github.io/debug-adapter-protocol/
Frequently this is implemented as a shim, but it seemed to me that GDB
could implement it directly, via the Python API. This patch is the
initial implementation.
DAP is implemented as a new "interp". This is slightly weird, because
it doesn't act like an ordinary interpreter -- for example it doesn't
implement a command syntax, and doesn't use GDB's ordinary event loop.
However, this seemed like the best approach overall.
To run GDB in this mode, use:
gdb -i=dap
The DAP code will accept JSON-RPC messages on stdin and print
responses to stdout. GDB redirects the inferior's stdout to a new
pipe so that output can be encapsulated by the protocol.
The Python code uses multiple threads to do its work. Separate
threads are used for reading JSON from the client and for writing JSON
to the client. All GDB work is done in the main thread. (The first
implementation used asyncio, but this had some limitations, and so I
rewrote it to use threads instead.)
This is not a complete implementation of the protocol, but it does
implement enough to demonstrate that the overall approach works.
There is a rudimentary test suite. It uses a JSON parser written in
pure Tcl. This parser is under the same license as Tcl itself, so I
felt it was acceptable to simply import it into the tree.
There is also a bit of documentation -- just documenting the new
interpreter name.
|
|
This commit is the result of running the gdb/copyright.py script,
which automated the update of the copyright year range for all
source files managed by the GDB project to be updated to include
year 2023.
|
|
MI version 1 is long since obsolete. Several years ago, I filed
PR mi/23170 for this. I think it's finally time to remove this.
Any users of MI 1 can and should upgrade to a newer version.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23170
|
|
I found a few vestiges of MI version 0 in the test suite. This patch
removes them.
|
|
The following commit broke the readnow detection in the testsuite:
commit dfaa040b440084dd73ebd359326752d5f44fc02c
Date: Mon Mar 29 18:31:31 2021 -0600
Remove some "OBJF_READNOW" code from dwarf2_debug_names_index
The testsuite checks if GDB was started with the -readnow flag by
using the 'maintenance print objfiles' command, and looking for the
string 'faked for "readnow"' in the output. This is implemented in
two helper procs `readnow` (gdb.exp) and `mi_readnow` (mi-support.exp).
The following tests all currently depend on this detection:
gdb.base/maint.exp
gdb.cp/nsalias.exp
gdb.dwarf2/debug-aranges-duplicate-offset-warning.exp
gdb.dwarf2/dw2-stack-boundary.exp
gdb.dwarf2/dw2-zero-range.exp
gdb.dwarf2/gdb-index-nodebug.exp
gdb.mi/mi-info-sources.exp
gdb.python/py-symbol.exp
gdb.rust/traits.exp
The following test also includes detection of 'readnow', but does the
detection itself by checking $::GDBFLAGS for the readnow flag:
gdb.opt/break-on-_exit.exp
The above commit removed from GDB the code that produced the 'faked
for "readnow"' string, as a consequence the testsuite can no longer
correctly spot when readnow is in use, and many of the above tests
will fail (at least partially).
When looking at the above tests, I noticed that gdb.rust/traits.exp
does call `readnow`, but doesn't actually use the result, so I've
removed the readnow call, this simplifies the next part of this patch
as gdb.rust/traits.exp was the only place an extra regexp was passed
to the readnow call.
Next I have rewritten `readnow` to check the $GDBFLAGS for the
-readnow flag, and removed the `maintenance print objfiles` check. At
least for all the tests above, when using the readnow board, this is
good enough to get everything passing again.
For the `mi_readnow` proc, I changed this to just call `readnow` from
gdb.exp, I left the mi_readnow name in place - in the future it might
be the case that we want to do some different checks here.
Finally, I updated gdb.opt/break-on-_exit.exp to call the `readnow`
proc.
With these changes, all of the tests listed above now pass correctly
when using the readnow board.
|
|
When building GDB with the following CFLAGS and CXXFLAGS as part of
configure line:
CFLAGS=-std=gnu11 CXXFLAGS=-std=gnu++11
Then run the selftest.exp, I see:
======
Running /home/lee/dev/binutils-gdb/gdb/testsuite/gdb.gdb/selftest.exp
...
FAIL: gdb.gdb/selftest.exp: run until breakpoint at captured_main
WARNING: Couldn't test self
=== gdb Summary ===
# of unexpected failures 1
/home/lee/dev/binutils-gdb/gdb/gdb version 13.0.50.20221206-git -nw -nx
-iex "set height 0" -iex "set width 0" -data-directory
/home/lee/dev/binutils-gdb/gdb/testsuite/../data-directory
======
It is the fact that when I use the previously mentioned CFLAGS and
CXXFLAGS as part of the configuration line, the default value (-O2 -g)
is overridden, then GDB has no debug information. When there's no debug
information, GDB should not run the testcase in selftest.exp.
The root cause of this FAIL is that the $gdb_file_cmd_debug_info didn't
get the right value ("nodebug") during the gdb_file_cmd procedure.
That's because in this commit,
commit 3453e7e409f44a79ac6695589836edb8a49bfb08
Date: Sat May 19 11:25:20 2018 -0600
Clean up "Reading symbols" output
It changed "no debugging..." to "No debugging..." which causes the above
problem. This patch only updates the corresponding pattern to fix this
issue.
With this patch applied, I see:
======
Running /home/lee/dev/binutils-gdb/gdb/testsuite/gdb.gdb/selftest.exp
...
=== gdb Summary ===
# of untested testcases 1
/home/lee/dev/binutils-gdb/gdb/gdb version 13.0.50.20221206-git -nw -nx
-iex "set height 0" -iex "set width 0" -data-directory
/home/lee/dev/binutils-gdb/gdb/testsuite/../data-directory
======
Tested on x86_64-linux.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
PR compile/29541 points out that some of the C++ tests in gdb.compile
will time out when the glibc debuginfo is installed. This was
interfering with my hacking on gdb by making test runs extremely long,
so I looked into it.
Internally the bug seems to be that gdb tries to convert multiple
symbols named "var" via the compiler interface; one such symbol (I
didn't track it down too far) causes the C++ compiler plugin to crash.
Unfortunately, the crash is reported as a timeout, as the gdb side of
the plugin simply hangs. This seems like a bug in the plugin RPC
mechanism and, worse, apparently when I wrote this stuff I didn't
really consider error reporting very much at all, so gdb can't really
detect failures in the first place.
Anyway... this patch works around the timeout by compiling a simple
test that should provoke this bug, and then using "untested" if it
notices a GCC crash.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29541
|
|
skip_compile_feature_tests checks for "Command not supported on this
host", but this error was removed by commit e8d8cce6 ("Import mkdtemp
gnulib module, fix mingw build"). This patch removes the obsolete
test.
|
|
I noticed that there are two identical copies of
skip_compile_feature_tests in the test suite. This removes one from
gdb.exp, in favor of the one in compile-support.exp.
|
|
When I run the gdb testsuite on a powerpc64le-linux system with (slow) nfs
file system, I run into timeouts due to core generation, like for instance:
...
(gdb) gcore $outputs/gdb.ada/task_switch_in_core/crash.gcore^M
FAIL: gdb.ada/task_switch_in_core.exp: save a corefile (timeout)
...
Fix this by using with_timeout_factor 3 in gdb_gcore_cmd.
Tested on powerpc64le-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
In the failure seen by Philippe here:
https://inbox.sourceware.org/gdb-patches/20221120173024.3647464-1-philippe.waroquiers@skynet.be/
gdb_unload crashed GDB, leaving no trace in the test results. Change it
to use gdb_test_multiple, so that it leaves an UNRESOLVED result. I
think it is good practice anyway.
Make it return the result of gdb_test_multiple directly, change
gdb.python/py-objfile.exp accordingly.
Change gdb.base/endian.exp as well to avoid duplicate test names.
Change gdb.base/gnu-debugdata.exp to avoid recording a test result,
since gdb_unload does it already now.
Change-Id: I59a1e4947691330797e6ce23277942547c437a48
Approved-By: Tom de Vries <tdevries@suse.de>
|
|
In the failure seen by Philippe here:
https://inbox.sourceware.org/gdb-patches/20221120173024.3647464-1-philippe.waroquiers@skynet.be/
... the testsuite only outputs PASSes, and an ERROR, resulting from an
uncaught exception. This is a bit sneaky, because ERRORs are not
reported in the test summary. In certain circumstances, it can be easy
to miss.
Normally, gdb_test_multiple outputs an UNRESOLVED when GDB crashes. But
this is only if it manages to send the command, and it's that command
that crashes GDB. Here, the ERROR is due to the fact that GDB had
already crashed by the time we entered gdb_test_multiple and tried to
send a command. GDB was crashed by the previous "file" command, sent by
gdb_unload. Because gdb_unload uses bare expect, it didn't record a
test failure when crashing GDB (this will be addressed separately).
In this patch, I propose to make gdb_test_multiple call unresolved
directly and return -1 send_gdb fails. This way, if GDB is already
crashed by the time we enter gdb_test_multiple, it will leave a trace in
the test results in the form of an UNRESOLVED. It will also spare us
the not-so-useful-in-my-opinion TCL backtrace.
Before, it looks like:
ERROR: Couldn't send python print(objfile.filename) to GDB.
ERROR: : spawn id exp9 not open
while executing
"expect {
-i exp9 -timeout 10
-re ".*A problem internal to GDB has been detected" {
fail "$message (GDB internal error)"
gdb_internal_error..."
("uplevel" body line 1)
invoked from within
"uplevel $body" NONE : spawn id exp9 not open
And after:
Couldn't send python print(objfile.filename) to GDB.
UNRESOLVED: gdb.python/py-objfile.exp: objfile.filename after objfile is unloaded
Change-Id: I72af8dc0d687826fc3f76911c27a9e5f91b677ba
Approved-By: Tom de Vries <tdevries@suse.de>
|
|
The canonical form of 'if' in modern TCL is 'if {} {}'. But there's
still a bunch of places in the testsuite where we make use of the
'then' keyword, and sometimes these get copies into new tests, which
just spreads poor practice.
This commit removes all use of the 'then' keyword from the testsuite
library files (in boards/, config/, and lib/). Previous commits have
removed all uses of the 'then' keyword from the test script files,
this commit just cleans up the library files.
There should be no changes in what is tested after this commit.
|
|
When running test-case gdb.base/bt-on-fatal-signal.exp on powerpc64le-linux I
noticed:
...
FAIL: gdb.base/bt-on-fatal-signal.exp: SEGV: scan for backtrace (timeout)
...
The timeout is 10 seconds, but generating the core file takes more than a
minute, probably due to slow NFS.
I managed to reproduce this behaviour independently of gdb, by compiling
"int main (void) { __builtin_abort (); }" and running it, which took 1.5
seconds for a core file 50 times smaller than the one for gdb.
Fix this by preventing the core file from being generated, using a wrapper
around gdb that does "ulimit -c 0".
Tested on x86_64-linux.
|
|
ctxobj.exp fails randomly when computer is loaded.
With the addition of $gdb_prompt in the regexp testing for breakpoint hit,
I could not make it fail anymore.
Also fixed a typo in a comment.
|
|
$_hit_locno PR breakpoints/12464
This implements the request given in PR breakpoints/12464.
Before this patch, when a breakpoint that has multiple locations is reached,
GDB printed:
Thread 1 "zeoes" hit Breakpoint 1, some_func () at somefunc1.c:5
This patch changes the message so that bkpt_print_id prints the precise
encountered breakpoint:
Thread 1 "zeoes" hit Breakpoint 1.2, some_func () at somefunc1.c:5
In mi mode, bkpt_print_id also (optionally) prints a new table field "locno":
locno is printed when the breakpoint hit has more than one location.
Note that according to the GDB user manual node 'GDB/MI Development and Front
Ends', it is ok to add new fields without changing the MI version.
Also, when a breakpoint is reached, the convenience variables
$_hit_bpnum and $_hit_locno are set to the encountered breakpoint number
and location number.
$_hit_bpnum and $_hit_locno can a.o. be used in the command list of a
breakpoint, to disable the specific encountered breakpoint, e.g.
disable $_hit_bpnum.$_hit_locno
In case the breakpoint has only one location, $_hit_locno is set to
the value 1, so as to allow a command such as:
disable $_hit_bpnum.$_hit_locno
to disable the breakpoint even when the breakpoint has only one location.
This also fixes a strange behaviour: when a breakpoint X has only
one location,
enable|disable X.1
is accepted but transforms the breakpoint in a multiple locations
breakpoint having only one location.
The changes in RFA v4 handle the comments of Tom Tromey:
- Changed convenience var names from $bkptno/$locno to
$_hit_bpnum/$_hit_locno.
- updated the tests and user manual accordingly.
User manual also explictly describes that $_hit_locno is set to 1
for a breakpoint with a single location.
- The variable values are now set in bpstat_do_actions_1 so that
they are set for silent breakpoints, and when several breakpoints
are hit at the same time, that the variables are set to the printed
breakpoint.
The changes in RFA v3 handle the additional comments of Eli:
GDB/NEW:
- Use max 80-column
- Use 'code location' instead of 'location'.
- Fix typo $bkpno
- Ensure that disable $bkptno and disable $bkptno.$locno have
each their explanation inthe example
- Reworded the 'breakpoint-hit' paragraph.
gdb.texinfo:
- Use 'code location' instead of 'location'.
- Add a note to clarify the distinction between $bkptno and $bpnum.
- Use @kbd instead of examples with only one command.
Compared to RFA v1, the changes in v2 handle the comments given by
Keith Seitz and Eli Zaretskii:
- Use %s for the result of paddress
- Use bkptno_numopt_re instead of 2 different -re cases
- use C@t{++}
- Add index entries for $bkptno and $locno
- Added an example for "locno" in the mi interface
- Added examples in the Break command manual.
|
