| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Simon pointed out that commit a2bbca9fa5e ("Use std::vector<bool> for
agent_expr::reg_mask") caused a regression in libstdc++ debug mode.
This was due to an off-by-one error in a vector resize. This patch
fixes the problem.
|
|
Python 3.11 changed the AttributeError message - see commit
0cb765b2cec9 ("bpo-46730: Add more info to @property AttributeError
messages (GH-31311)"). Add the new message to the expectations.
Approved-By: Tom Tromey <tom@tromey.com>
Link: https://sourceware.org/pipermail/gdb-patches/2023-June/200433.html
|
|
In commit e2adba909e7 ("[gdb/testsuite] Clean up before compilation in
gdb.ada/call-no-debug.exp") I added some code in the test-case to remove some
files at the start of the test-case:
...
remote_file host delete [standard_output_file prog.o]
remote_file host delete [standard_output_file prog.ali]
...
Then in commit b7b77500dc5 ("[gdb/testsuite] Clean standard_output_file dir in
gdb_init") I tried to do this more structurally, by cleaning up the entire
standard_output_file directory, for all test-cases.
This caused a regression when using "make check -j 2", due to the cleanup
removing the active gdb.log, so I reverted the commit.
Try again, this time handling the two cases separately.
If the standard_output_file directory contains an active gdb.log, check that
the directory contains no files other than gdb.log and gdb.sum. This puts
the reponsibility for the cleanup at the callers in gdb/testsuite/Makefile.in
which use --outdir.
If the standard_output_file directory doesn't contain an active gdb.log, clean
it by removing the entire directory.
An exception is made for performance tests, where cleaning up the
standard_output_file dir is the wrong thing to do, because an invocation with
GDB_PERFTEST_MODE == run is intended to reuse binaries left there by an
earlier invocation with GDB_PERFTEST_MODE == compile.
Tested on x86_64-linux.
Suggested-By: Tom Tromey <tom@tromey.com>
Reviewed-By: Tom Tromey <tom@tromey.com>
Tested-By: Luis Machado <luis.machado@arm.com>
|
|
A DAP client can request that an expression be evaluated in "hover"
context, meaning that it should not cause side effects. In gdb, this
can be implemented by temporarily setting a few "may-" parameters to
"off".
In order to make this work, I had to also change "may-write-registers"
so that it can be changed while the program is running. I don't think
there was any reason for this prohibition in the first place.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30476
|
|
DAP allows a source breakpoint to specify a log message. When this is
done, the breakpoint acts more like gdb's dprintf: it logs a message
but does not cause a stop.
I looked into implement this using dprintf with the new %V printf
format. However, my initial attempt at this did not work, because
when the inferior is continued, the dprintf output is captured by the
gdb.execute call. Maybe this could be fixed by having all
inferior-continuation commands use the "&" form; the main benefit of
this would be that expressions are only parsed a single time.
|
|
A bug report about the supportsVariablePaging capability in DAP
resulted in a clarification: when this capability is not present, DAP
implementations should ignore the paging parameters to the "variables"
request. This patch implements this clarification.
|
|
I realized that with a small refactoring, it is possible to type-check
the parameters to the various DAP breakpoint requests. This would
have caught the earlier bug involving hitCondition.
|
|
When creating a DAP breakpoint, a failure should be returned by
setting "verified" to False. gdb didn't properly implement this, and
there was a FIXME comment to this effect. This patch fixes the
problem.
|
|
The DAP breakpoint code tries to reuse a breakpoint when possible.
Currently it uses the condition and the hit condition (aka ignore
count) when making this determination. However, these attributes are
just going to be reset anyway, so this patch changes the code to
exclude these from the reuse decision.
|
|
DAP specifies a breakpoint's hitCondition as a string, meaning it is
an expression to be evaluated. However, gdb implemented this as if it
were an integer instead. This patch fixes this oversight.
|
|
v2.
EvaluateResult does not need a name, just as what Tom pointed out in
previous review. It's only the *children* that need to be made sure that
their names are valid. An identifier for a variable, can't ever have an
integer as a name, anyhow (not as far as I am aware, no programming
languages allow for that).
Removed the f-strings and use str() instead as pointed out that
f-strings might not be supported fully.
v1.
This patch fixes a few bugs.
First of all, name of VariableReferences must always be of string type.
This patch makes sure that this is the case by formatting the name. If
(when) the name is an integer, this will cause clients to fail or throw
errors.
Fixes a bug in NoOpArrayPrinter that calculated children to be N, but
only ever retrieves N-1 children, which makes Python at some time later
(during fetch_children -> fetch_one_child(N) ) raise an exception (out
of list index) which makes the entire request go bad.
The result[self.result_name] also f-strings the printer.to_string()
value, because this can potentially be a LazyString (which is a Python
object, not a string) and is not serializable by json.dumps.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
A user on irc noticed a missing backslash on one line in
update-gnulib.sh. This patch adds it.
Re-running update-gnulib.sh causes a few copyright notices to change.
Presumably these are from upstream gnulib and shouldn't be touched by
our yearly update. I've updated the script to account for this, but I
did not want to try testing it...
|
|
With test-case gdb.tui/pr30056.exp, I run into:
...
sh: warning: setlocale: LC_ALL: cannot change locale (C.UTF-8)^M
...
and then subsequently into:
...
WARNING: timeout in accept_gdb_output
FAIL: gdb.tui/pr30056.exp: Control-C
...
This is on a CentOS 7 distro for powerpc64le.
Either it has no C.UTF-8 support, or it's not installed:
...
$ locale -a | grep ^C
C
$
...
Fix this by:
- adding a new proc have_host_locale, and
- using it in all test-cases using setenv LC_ALL.
Tested on powerpc64le-linux and x86_64-linux.
|
|
PR testsuite/30458 reports the following FAIL:
...
PASS: gdb.tui/wrap-line.exp: width-auto-detected: cli: wrap
^CQuit
(gdb) WARNING: timeout in accept_gdb_output
Screen Dump (size 50 columns x 24 rows, cursor at column 6, row 3):
0 Quit
1 (gdb) 7890123456789012345678901234567890123456789
2 W^CQuit
3 (gdb)
...
FAIL: gdb.tui/wrap-line.exp: width-auto-detected: cli: prompt after wrap
...
The problem is that the regexp doesn't account for the ^C:
...
gdb_assert { [Term::wait_for "^WQuit"] } "prompt after wrap"
...
The ^C occurs occasionally. This is something we'd like to fix. It's
reported as a readline problem here (
https://lists.gnu.org/archive/html/bug-readline/2023-06/msg00000.html ).
For now, fix this by updating the regexp, and likewise in another place in the
test-case where we use ^C.
Tested on x86_64-linux.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30458
|
|
Say we run test-case gdb.tui/basic.exp. It calls Term::enter_tui, which does:
...
command_no_prompt_prefix "tui enable"
...
The proc command_no_prompt_prefix is documented as:
...
# As proc command, but don't wait for an initial prompt. This is used for
# initial terminal commands, where there's no prompt yet.
...
Indeed, before the "tui enable" command, the tuiterm is empty, so there is no
prompt and just before switching to TUI we have in the tuiterm:
...
tui enable
...
The reason that there is no prompt, is that:
- in order for tuiterm to show something, its input processing procs need to
be called, and
- the initial gdb prompt, and subsequent prompts generated by gdb_test-style
procs, are all consumed by those procs instead.
This is in principle not a problem, but the absence of a prompt makes a
tuiterm session look less like a session on an actual xterm.
Add a new proc gen_prompt, that:
- generates a prompt using echo
- consumes the response before the prompt using gdb_expect
- consumes the prompt using Term::wait_for "".
This allows us to reimplement Term::command_no_prompt_prefix using
Term::command, and just before switching to TUI we have in the tuiterm:
...
(gdb) tui enable
...
Tested on x86_64-linux.
|
|
The semantics of Term::wait_for is:
...
# Accept some output from gdb and update the screen. WAIT_FOR is
# a regexp matching the line to wait for. Return 0 on timeout, 1
# on success.
proc wait_for {wait_for} {
...
Note that besides the regexp, also a subsequent gdb prompt is matched.
I recently used wait_for "" in a few test-cases, thinking that this would
match just a prompt, but in fact that's not the case.
Fix this in wait_for, and add a corresponding test in gdb.tui/tuiterm-2.exp.
Tested on x86_64-linux.
|
|
This changes a couple of spots in ax-general.c to use ARRAY_SIZE.
While making this change, I noticed that one of the bounds checks was
incorrect.
Reviewed-by: John Baldwin <jhb@FreeBSD.org>
|
|
aop_last is only used for an assertion. However, due to the '.def'
construct in the sources, this assert could never plausibly trigger
(the assert predates the use of a .def file here). This patch removes
the constant and the assert.
Reviewed-by: John Baldwin <jhb@FreeBSD.org>
|
|
This changes aop_map to be 'static'.
Reviewed-by: John Baldwin <jhb@FreeBSD.org>
|
|
This changese agent_expr::tracing to have type bool, allowing inline
initialization and cleaning up the code a little.
Reviewed-by: John Baldwin <jhb@FreeBSD.org>
|
|
This simplifies the agent_expr constructor a bit, and removes the
destructor entirely.
Reviewed-by: John Baldwin <jhb@FreeBSD.org>
|
|
agent_expr::reg_mask implements its own packed boolean vector. This
patch replaces it with a std::vector<bool>, simplifying the code.
Reviewed-by: John Baldwin <jhb@FreeBSD.org>
|
|
This changes agent_expr to use gdb::byte_vector rather than manually
reimplementing a vector.
Reviewed-by: John Baldwin <jhb@FreeBSD.org>
|
|
tracepoint.c has a 'mem2hex' function that is functionally equivalent
to bin2hex. This patch removes the redundancy.
Reviewed-by: John Baldwin <jhb@FreeBSD.org>
|
|
do_set_command manually updates a string, only to copy it to a
std::string and free the working copy. This patch changes this code
to use std::string for everything, simplifying the code and removing a
copy.
Reviewed-by: John Baldwin <jhb@FreeBSD.org>
|
|
This patch changes the remote.c readahead_cache to use
gdb::byte_vector. This simplifies the code by removing manual memory
management.
Reviewed-by: John Baldwin <jhb@FreeBSD.org>
|
|
I found some code in linux-osdata that manually managed a string.
Replacing this with std::string simplifies it.
Reviewed-by: John Baldwin <jhb@FreeBSD.org>
|
|
This changes mi_parse::command to be a unique_xmalloc_ptr and fixes up
all the uses. This avoids some manual memory management. std::string
is not used here due to how the Python API works -- this approach
avoids an extra copy there.
Reviewed-by: Keith Seitz <keiths@redhat.com>
|
|
This changes the MI "token" to be a std::string, removing some manual
memory management. It also makes current_token 'const' in order to
support this change.
Reviewed-by: Keith Seitz <keiths@redhat.com>
|
|
This reverts commit b7b77500dc56e5bc21473dd4f3dde2543d894557.
|
|
Python formatting errors fixed, introduced by this commit.
|
|
Fixes failure reported by buildbot regarding ill-formatted Python code.
|
|
v6:
Fix comments.
Fix copyright
Remove unnecessary test suite stuff. save_var had to stay, as it mutates
some test suite state that otherwise fails.
v5:
Did what Tom Tromey requested in v4; which can be found here: https://pi.simark.ca/gdb-patches/87pmjm0xar.fsf@tromey.com/
v4:
Doc formatting fixed.
v3:
Eli:
Updated docs & NEWS to reflect new changes. Added
a reference from the .ptid attribute of the ThreadExitedEvent
to the ptid attribute of InferiorThread. To do this,
I've added an anchor to that attribute.
Tom:
Tom requested that I should probably just emit the thread object;
I ran into two issues for this, which I could not resolve in this patch;
1 - The Thread Object (the python type) checks it's own validity
by doing a comparison of it's `thread_info* thread` to nullptr. This
means that any access of it's attributes may (probably, since we are
in "async" land) throw Python exceptions because the thread has been
removed from the thread object. Therefore I've decided in v3 of this
patch to just emit most of the same fields that gdb.InferiorThread has, namely
global_num, name, num and ptid (the 3-attribute tuple provided by
gdb.InferiorThread.ptid).
2 - A python user can hold a global reference to an exiting thread. Thus
in order to have a ThreadExit event that can provide attribute access
reliably (both as a global reference, but also inside the thread exit
handler, as we can never guarantee that it's executed _before_ the
thread_info pointer is removed from the gdbpy thread object),
the `thread_info *` thread pointer must not be null. However, this
comes at the cost of gdb.InferiorThread believing it is "valid" - which means,
that if a user holds takes a global reference to that
exiting event thread object, they can some time later do `t.switch()` at which
point GDB will 'explode' so to speak.
v2:
Fixed white space issues and NULL/nullptr stuff,
as requested by Tom Tromey.
v1:
Currently no event is emitted for a thread exit.
This adds this functionality by emitting a new gdb.ThreadExitedEvent.
It currently provides four attributes:
- global_num: The GDB assigned global thread number
- num: the per-inferior thread number
- name: name of the thread or none if not set
- ptid: the PTID of the thread, a 3-attribute tuple, identical to
InferiorThread.ptid attribute
Added info to docs & the NEWS file as well.
Added test to test suite.
Fixed formatting.
Feedback wanted and appreciated.
|
|
Renamed thread_name according to convention (_ first)
When testing firefox tests, it is apparent that
_get_threads returns threads with name field = None.
I had initially thought that this was due to Firefox setting the names
using /proc/pid/task/tid/comm, by writing directly to the proc fs the
names, but apparently GDB seems to catch this, because I re-wrote
the basic-dap.exp/c to do this specifically and it saw the changes.
So I couldn't determine right now, what operation of name change that
GDB does not pick up, but with this patch, GDB will pick up the thread
names for an applications that set the name of a thread in ways that
aren't obvious.
|
|
Test-case gdb.ada/catch_ex_std.exp passes for me with package
libada7-debuginfo installed, but after removing it I get:
...
(gdb) catch exception some_kind_of_error^M
Your Ada runtime appears to be missing some debugging information.^M
Cannot insert Ada exception catchpoint in this configuration.^M
(gdb) FAIL: gdb.ada/catch_ex_std.exp: catch exception some_kind_of_error
...
The test-case contains a require gnat_runtime_has_debug_info to deal with
this, but the problem is that this checks the static gnat runtime, while this
test-case uses the shared one.
Fix this by introducing shared_gnat_runtime_has_debug_info, and requiring that
one instead.
Tested on x86_64-linux.
PR testsuite/30094
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30094
|
|
Simplify tui_update_variables by using template function
assign_return_if_changed.
Tested on x86_64-linux.
|
|
Add template functions assign_return_if_changed and assign_set_if_changed in
gdb/utils.h:
...
template<typename T> void assign_set_if_changed (T &lval, const T &val, bool &changed)
{ ... }
template<typename T> bool assign_return_if_changed (T &lval, const T &val)
{ ... }
...
This allows us to rewrite code like this:
...
if (tui_border_attrs != entry->value)
{
tui_border_attrs = entry->value;
need_redraw = true;
}
...
into this:
...
need_redraw |= assign_return_if_changed<int> (tui_border_attrs, entry->value);
...
or:
...
assign_set_if_changed<int> (tui_border_attrs, entry->value, need_redraw);
...
The names are a composition of the functionality. The functions:
- assign VAL to LVAL, and either
- return true if the assignment changed LVAL, or
- set CHANGED to true if the assignment changed LVAL.
Tested on x86_64-linux.
|
|
In commit e2adba909e7 ("[gdb/testsuite] Clean up before compilation in
gdb.ada/call-no-debug.exp") I added some code in the test-case to remove some
files at the start of the test-case:
...
remote_file host delete [standard_output_file prog.o]
remote_file host delete [standard_output_file prog.ali]
...
Replace this with cleaning up the entire directory instead, for all
test-cases.
Tested on x86_64-linux.
Suggested-By: Tom Tromey <tom@tromey.com>
Reviewed-By: Tom Tromey <tom@tromey.com>
|
|
on openSUSE Leap 42.3, with python 3.4, I run into a
"SyntaxError: invalid syntax" due to usage of an f-string in test-case
gdb.python/py-unwind.py.
Fix this by using string concatenation using '+' instead.
Tested on x86_64-linux.
|
|
When running test-case gdb.arch/i386-disp-step.exp with target board
unix/-m32/-fPIE/-pie we run into:
...
gdb compile failed, ld: i386-disp-step0.o: warning: relocation in read-only section `.text'
ld: warning: creating DT_TEXTREL in a PIE
...
Fix this by adding nopie in the compilation flags.
Likewise in a few other test-cases.
Tested on x86_64-linux.
|
|
In test-case gdb.dwarf2/implptr.exp I noticed:
...
} elseif {![is_x86_like_target]} {
# This test can only be run on x86 targets.
unsupported "needs x86-like target"
return 0
}
...
Use instead "require is_x86_like_target".
Tested on x86_64-linux.
|
|
Running test-case gdb.ada/call-no-debug.exp with target board unix/-m64 works
fine, but if we run it again with target board unix-m32, we run into:
...
gnatlink prog.ali -m32 -g -o prog^M
ld: i386:x86-64 architecture of input file `b~prog.o' is incompatible with \
i386 output^M
...
This is due to compiling with no-force.
The test-case:
- first compiles pck.adb into pck.o (without debug info), and
- then compiles prog.adb and pck.o into prog (with debug info).
Using no-force in the second compilation make sure that pck.adb is not
compiled again, with debug info.
But it also means it will pick up intermediate files related to prog.adb from
a previous compilation.
Fix this by removing prog.o and prog.ali before compilation.
Tested on x86_64-linux.
|
|
In commit 0f2cd53cf4f ("[gdb/testsuite] Handle missing .note.GNU-stack") I
updated a gdb.arch/arm*.S test-case to use %progbits rather than @progbits,
but failed to do so for gdb.arch/thumb*.S. Fix this oversight.
Tested on arm-linux-gnueabihf.
|
|
It's been some time since the switch from Freenode to Libera.Chat,
however, there's still a reference to Freenode in the 'gdb --help'
output. Lets update that.
|
|
In test-case gdb.base/step-over-exit.exp, we set a breakpoint on _exit and
continue, expecting to hit the breakpoint.
Without glibc debug info installed, we have with target board unix/-m64:
...
Thread 2.1 "step-over-exit" hit Breakpoint 2.2, 0x00007ffff7d46aee in \
_exit () from /lib64/libc.so.6^M
(gdb) PASS: gdb.base/step-over-exit.exp: continue to exit
...
and with target board unix/-m32:
...
Thread 2.1 "step-over-exit" hit Breakpoint 2.2, 0xf7d84c25 in _exit () from \
/lib/libc.so.6^M
(gdb) PASS: gdb.base/step-over-exit.exp: continue to exit
...
However after installing debug info (packages glibc-debuginfo and
glibc-32bit-debuginfo), we have for -m64 (note: __GI__exit instead of _exit):
...
Thread 2.1 "step-over-exit" hit Breakpoint 2.2, \
__GI__exit (status=<optimized out>) at \
../sysdeps/unix/sysv/linux/_exit.c:27^M
27 {^M
(gdb) PASS: gdb.base/step-over-exit.exp: continue to exit
...
and -m32 (note: _Exit instead of _exit):
...
Thread 2.1 "step-over-exit" hit Breakpoint 2.2, _Exit () at \
../sysdeps/unix/sysv/linux/i386/_exit.S:24^M
24 ../sysdeps/unix/sysv/linux/i386/_exit.S: No such file or directory.^M
(gdb) FAIL: gdb.base/step-over-exit.exp: continue to exit
...
The gdb_test allows for both _exit and __GI__exit, but not _Exit:
...
gdb_test "continue" \
"Continuing\\..*Breakpoint $decimal.*_exit \\(.*\\).*" \
"continue to exit"
...
Fix this by allowing _Exit as well.
Tested on x86_64-linux.
|
|
When running test-case gdb.tui/long-prompt.exp with check-read1, we get:
...
(gdb) FAIL: gdb.tui/long-prompt.exp: prompt size == width + 1: \
end of screen: at last line
...
The problem is in these commands:
...
Term::command "echo \\n"
Term::command "echo \\n"
Term::command "echo \\n"
Term::command "echo \\n"
...
The last one makes the terminal scroll, and the scrolling makes the expected
output match on a different line.
Fix this by replacing the sequence with a single command:
...
Term::command "echo \\n\\n\\n\\n\\n\\n"
...
which avoids scrolling.
Tested on x86_64-linux.
|
|
There is a test-case that contains a unit test for tuiterm:
gdb.tui/tuiterm.exp.
However, this only excercises the tuiterm itself, and not the functions that
interact with it, like Term::command.
Add a new test-case gdb.tui/tuiterm-2.exp that:
- overrides proc accept_gdb_output (to be able simulate incorrect responses
while avoiding the timeout),
- overrides proc send_gdb (to be able to call Term::command without a gdb
instance, such that all tuiterm input is generated by the test-case).
- issues Term::command calls, and
- checks whether they behave correctly.
This exposes a problem in Term::command. The "prompt before command" regexp
starts with a bit that is supposed to anchor the prompt to the border:
...
set str "(^|\|)$gdb_prompt $str"
...
but that doesn't work due to insufficient escaping. Fix this by adding the
missing escape:
...
set str "(^|\\|)$gdb_prompt $str"
...
Futhermore, the "prompt after command" regexp in Term::wait_for has no
anchoring at all:
...
set prompt_wait_for "$gdb_prompt \$"
...
so add that as well.
Tested on x86_64-linux.
|
|
Currently proc with_override does not work with procs with default value args.
Fix this, and add a test-case excercising this scenario.
Tested on x86_64-linux.
|
|
On openSUSE Leap 15.4 with system python 3.6, I run into:
...
(gdb) python check_everything()^M
(gdb) FAIL: gdb.dap/type_check.exp: type checker
...
In check_everything, the hasattr test fails silently:
...
def check_everything():
# Older versions of Python can't really implement this.
if hasattr(typing, "get_origin"):
...
and that makes the gdb_test in the test-case fail.
Fix this by emitting UNSUPPORTED instead in check_everything, and detecting
this in the test-case.
Tested on x86_64-linux.
|
|
We recently realized that symbol_needs_eval_fail.exp and
symbol_needs_eval_timeout.exp invalidly dereference an int (4 bytes on
x86_64) by reading 8 bytes (the size of a pointer).
Here how it goes:
In gdb/testsuite/gdb.dwarf2/symbol_needs_eval.c a global variable is
defined:
int exec_mask = 1;
and later both tests build some DWARF using the assembler doing:
set exec_mask_var [gdb_target_symbol exec_mask]
...
DW_TAG_variable {
{DW_AT_name a}
{DW_AT_type :$int_type_label}
{DW_AT_location {
DW_OP_addr $exec_mask_var
DW_OP_deref
...
}
}
The definition of the DW_OP_deref (from Dwarf5 2.5.1.3 Stack Operations)
says that "The size of the data retrieved from the dereferenced address
is the size of an address on the target machine."
On x86_64, the size of an int is 4 while the size of an address is 8.
The result is that when evaluating this expression, the debugger reads
outside of the `a` variable.
Fix this by using `DW_OP_deref_size $int_size` instead. To achieve
this, this patch adds the necessary steps so we can figure out what
`sizeof(int)` evaluates to for the current target.
While at it, also change the definition of the int type in the assembled
DWARF information so we use the actual target's size for an int instead
of the literal 4.
Tested on x86_64 Linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
