| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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>
|
|
Currently the Fortran test suite does not run with armflang because the
compiler detection fails. This in turn means fortran_runto_main does not
know which main method to use to start a test case.
Fortran compiler detection was added in 44d469c5f85; however, the commit
message notes that it was not tested with armflang.
This commit tests and fixes up a minor issue to get the detection
working.
The goal here is to get the tests running and preventing further
regressions during future work. This change does not do anything to fix
existing failures.
>From what I can understand, the auto detection leverages the
preprocessor to extract the Fortran compiler identity from the defines.
This preprocessor output is then evaluated by the test suite to import
these defines.
In the case of armflang, this evaluation step is disrupted by the
presence of the following warning:
$ armflang -E -fdiagnostics-color=never testsuite/lib/compiler.F90 -o compiler.exp
$ clang-13: warning: argument unused during compilation: '-fdiagnostics-color=never' [-Wunused-command-line-argument]
The evaluation logic is already set up to filter this warning, but the
prefix differs.
This commit fixes the issue by updating the filter to exclude the
armflang flavour of warning.
gdb.fortran regression tests run with GNU, Intel and Intel LLVM. No
regressions detected.
The gdb.fortran test results with ACfL 23.04.1 are as follows.
Before:
# of expected passes 560
# of unexpected failures 113
# of unresolved testcases 2
# of untested testcases 5
# of duplicate test names 2
After:
# of expected passes 5388
# of unexpected failures 628
# of known failures 10
# of untested testcases 8
# of unsupported tests 5
# of duplicate test names 5
As can be seen from the above, there are now considerably more passing
assertions.
Reviewed-By: Luis Machado <luis.machado@arm.com>
Approved-By: Tom Tromey <tom@tromey.com>
|
|
I realized that I had only implemented DAP breakpoint conditions for
exception breakpoints, and not other kinds of breakpoints. This patch
corrects the oversight.
|
|
This implements the DAP breakpointLocations request.
|
|
Co-workers who work on a program that uses DAP asked for the ability
to have gdb stop at the main subprogram when launching. This patch
implements this extension.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
|
|
This adds a new "target" to the DAP attach request. This is passed to
"target remote". I thought "attach" made the most sense for this,
because in some sense gdb is attaching to a running process. It's
worth noting that all DAP "attach" parameters are defined by the
implementation.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
|
|
A DAP client can report the supportsVariableType capability in the
initialize request. In this case, gdb can include the type of a
variable or expression in various results.
|
|
This implements the DAP setExpression request.
|
|
This adds an 'assign' method to gdb.Value. This allows for assignment
without requiring the use of parse_and_eval.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
|
|
It occurred to me recently that gdb's DAP implementation should
probably check the types of objects coming from the client. This
patch implements this idea by reusing Python's existing type
annotations, and supplying a decorator that verifies these at runtime.
Python doesn't make it very easy to do runtime type-checking, so the
core of the checker is written by hand. I haven't tried to make a
fully generic runtime type checker. Instead, this only checks the
subset that is needed by DAP. For example, only keyword-only
functions are handled.
Furthermore, in a few spots, it wasn't convenient to spell out the
type that is accepted. I've added a couple of comments to this effect
in breakpoint.py.
I've tried to make this code compatible with older versions of Python,
but I've only been able to try it with 3.9 and 3.10.
|
|
I neglected to write a test for the DAP "pause" request. This patch
adds one.
|
|
A few DAP requests support a "singleThread" parameter, which is
somewhat similar to scheduler-locking. This patch implements support
for this.
|
|
This implements the DAP "stepOut" request.
|
|
This implements the DAP "attach" request.
Note that the copyright dates on the new test source file are not
incorrect -- this was copied verbatim from another directory.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
|
|
This implements the DAP setExceptionBreakpoints request for Ada. This
is a somewhat minimal implementation, in that "exceptionOptions" are
not implemented (or advertised) -- I wasn't completely sure how this
feature is supposed to work.
I haven't added C++ exception handling here, but it's easy to do if
needed.
This patch relies on the new MI command execution support to do its
work.
|
|
This changes the Ada catchpoint tests to use
gnat_runtime_has_debug_info. This simplifies the code.
|
|
gnat_runtime_has_debug_info starts a new gdb to do its work. However,
it also leaves this gdb running, which can potentially confuse the
calling test -- I encountered this when writing a new DAP test. This
patch changes the proc to shut down gdb.
|
|
With a gdb 13.2 based package on SLE-15 aarch64, I run into:
...
(gdb) PASS: gdb.python/py-rbreak.exp: nosharedlibrary
py sl = gdb.rbreak("^[^_]",minsyms=False)^M
Breakpoint 2 at 0x4004ac: file ../sysdeps/aarch64/crti.S, line 63.^M
...
(gdb) py print(len(sl))^M
12^M
(gdb) FAIL: gdb.python/py-rbreak.exp: check number of returned breakpoints is 11
...
The FAIL is due to:
- the glibc object crti.o containing debug information for function
call_weak_fn, and
- the test-case not expecting this.
The debug information is there due to compiling glibc using a binutils which
contains commit 591cc9fbbfd ("gas/Dwarf: record functions").
I've run into a similar issue before, see commit 3fbbcf473a5 ("[gdb/testsuite]
Fix regexp in py-rbreak.exp").
The fix I applied there was to use a regexp "^[^_]" to filter out
__libc_csu_fini and __libc_csu_init, but that doesn't work for call_weak_fn.
Fix this by:
- reverting the regexp to "", and
- rewriting the check to require at least 11 functions, rather than a precise
match.
Tested on x86_64-linux.
PR testsuite/30538
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30538
|
|
With a gdb 13.2 based package on openSUSE Tumbleweed i586, I ran into:
...
(gdb) run ^M
Starting program: out_of_line_in_inlined/foo_o224_021-all ^M
[Thread debugging using libthread_db enabled]^M
Using host libthread_db library "/lib/libthread_db.so.1".^M
^M
Breakpoint 1.1, foo_o224_021.child1.child2 (s=...) at foo_o224_021.adb:26^M
26 for C of S loop^M
(gdb) FAIL: gdb.ada/out_of_line_in_inlined.exp: scenario=all: \
run to foo_o224_021.child1.child2
...
I can reproduce the same issue with gdb trunk on x86_64, by using optimize=-O3
instead of optimize=-O2.
Fix this by using $bkptno_num_re.
Tested on x86_64-linux.
PR testsuite/30539
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30539
|
|
This commit implements a fix for a bug reported against GDB on
Fedora bugzilla...
https://bugzilla.redhat.com/show_bug.cgi?id=2166796
The test case in that bug report involved running gdb against the 'jq'
program (which is a command-line JSON processor) on Fedora 37. Since
the debug info is compiler (and compile-time option) dependent, it
won't necessarily show up in other distributions or even past or
future versions of Fedora. (E.g. when trying the example shown below
on Fedora 38, GDB says that the value of 'value' has been optimized
out. I.e. it does not demonstrate the same DWARF error that can be
see when using Fedora 37.)
That said, on Fedora 37, the bug could be reproduced as follows:
[kev@f37-1 ~]$ gdb jq -q -ex 'b src/util.c:415' -ex 'r </dev/null'
Reading symbols from jq...
This GDB supports auto-downloading debuginfo from the following URLs:
<https://debuginfod.fedoraproject.org/>
Enable debuginfod for this session? (y or [n]) y
Debuginfod has been enabled.
To make this setting permanent, add 'set debuginfod enabled on' to .gdbinit.
Reading symbols from /home/kev/.cache/debuginfod_client/9d3c8b4197350a190a74972d481de32abf641aa4/debuginfo...
No source file named src/util.c.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (src/util.c:415) pending.
Starting program: /usr/bin/jq </dev/null
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Breakpoint 1, jq_util_input_next_input (state=0x55555555d7f0) at src/util.c:416
416 if (state->parser == NULL) {
(gdb) p value
DWARF-2 expression error: DW_OP_GNU_uninit must always be the very last op.
This is undesirable - rather than output an error about the DWARF
info, we'd prefer to see a value, even if it is uninitialized.
Examination of the debuginfo showed the following:
<1><468f1>: Abbrev Number: 112 (DW_TAG_subprogram)
<468f2> DW_AT_external : 1
<468f2> DW_AT_name : (indirect string, offset: 0x4781): jq_util_input_next_input
<468f6> DW_AT_decl_file : 10
<468f6> DW_AT_decl_line : 411
<468f8> DW_AT_decl_column : 4
<468f9> DW_AT_prototyped : 1
<468f9> DW_AT_type : <0x3f2>
<468fd> DW_AT_sibling : <0x4692e>
...
<2><46921>: Abbrev Number: 102 (DW_TAG_variable)
<46922> DW_AT_name : (indirect string, offset: 0x8cb): value
<46926> DW_AT_decl_file : 10
<46926> DW_AT_decl_line : 414
<46928> DW_AT_decl_column : 6
<46929> DW_AT_type : <0x3f2>
Note that there's no DW_AT_location, so I looked for an abstract origin entry:
<2><2dfa0>: Abbrev Number: 90 (DW_TAG_variable)
<2dfa1> DW_AT_abstract_origin: <0x46921>
<2dfa5> DW_AT_location : 0x27cf1 (location list)
<2dfa9> DW_AT_GNU_locviews: 0x27ce1
(Note that the DW_AT_abstract_origin attribute's value is 0x46921 which
is the DIE for the local variable "value".)
Looking at the location list, I see:
00027cf1 v000000000000000 v000000000000000 views at 00027ce1 for:
000000000002f8fe 000000000002f92e (DW_OP_reg13 (r13); DW_OP_GNU_uninit; DW_OP_piece: 8; DW_OP_reg12 (r12); DW_OP_GNU_uninit; DW_OP_piece: 8)
While DW_OP_GNU_uninit is not the very last op, it is the last op
prior to DW_OP_piece. The fix involved changing the DW_OP_GNU_uninit
case in dwarf_expr_context::execute_stack_op in gdb/dwarf2/expr.c so
that DW_OP_GNU_uninit may appear just before DW_OP_piece.
With the fix in place, attempting to print 'value' now looks like
this:
(gdb) p value
$1 = [uninitialized] {kind_flags = 0 '\000', pad_ = 0 '\000', offset = 0,
size = 0, u = {ptr = 0x0, number = 0}}
Note that "[uninitialized]" is part of the output. (But also note
that there's an extra space character.)
I've made a new test case,
gdb.dwarf2/DW_OP_piece_with_DW_OP_GNU_uninit.exp, by adapting an
existing one, gdb.dwarf2/opt-out-not-implptr.exp. Since it uses the
DWARF assembler, the test case does not depend on a specific compiler
version or compiler options.
Tested on Fedora 37 and Fedora 38.
|
|
Say we're in TUI mode, and type "sun":
...
(gdb) sun
...
After switching to SingleKey mode using C-x s, we have just:
...
sun
...
After typing "d", we get:
...
sun
Undefined command: "sundown". Try "help".
...
The SingleKey "d" is supposed run the "down" command.
Fix this by clearing the readline line buffer when switching to SingleKey
mode.
Tested on x86_64-linux.
PR tui/30522
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30522
Reviewed-By: Tom Tromey <tom@tromey.com>
|
|
I noticed that there's no test-case excercising SingleKey mode, so add a test-case.
Tested on x86_64-linux.
Reviewed-By: Tom Tromey <tom@tromey.com>
|
|
Fix typos:
- reponse -> response
- inital -> initial
- a -> an
|
|
I noticed that the test-suite doesn't excercise the case in
tui_redisplay_readline that height (initially 1) is changed by this call:
...
tui_puts_internal (w, prompt, &height);
...
Add a test-case that excercises this.
Tested on x86_64-linux.
|
|
The gdb.dwarf2/dw2-prologue-end-2.exp test was failing for both AArch64 and
Arm.
As Tom pointed out here (https://inbox.sourceware.org/gdb-patches/6663707c-4297-c2f2-a0bd-f3e84fc62aad@suse.de/),
there are issues with both the prologue skipper for AArch64 and Arm and an
incorrect assumption by the testcase.
This patch fixes both of AArch64's and Arm's prologue skippers to not skip past
the end of a function. It also incorporates a fix to the testcase so it
doesn't assume the prologue skipper will stop at the first instruction of the
functions/labels.
Regression-tested on aarch64-linux/arm-linux Ubuntu 20.04/22.04 and
x86_64-linux Ubuntu 20.04.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30506
Co-Authored-By: Tom de Vries <tdevries@suse.de>
Co-Authored-By: Luis Machado <luis.machado@arm.com>
|
|
While working on PR tui/30526, I noticed a bug in test-case
gdb.python/tui-window-disabled.exp.
Here we send "tui enable" to gdb, but don't wait for it to arrive before
checking for a window box:
...
send_gdb "tui enable\n"
Term::check_box "check for python window" 0 0 80 16
...
Fix this by waiting for the prompt to be issued in TUI before doing the check.
Tested on x86_64-linux.
|
|
Fix two typos in test-case gdb.python/tui-window-disabled.exp.
|
|
gdb.threads/step-N-all-progress.exp
Using "taskset -c 0" I run into this timeout:
...
(gdb) PASS: gdb.threads/step-N-all-progress.exp: non-stop=on: \
target-non-stop=on: continue to breakpoint: break here
next 3^M
[New Thread 0x7ffff7dbd6c0 (LWP 10202)]^M
50 return 0;^M
(gdb) [Thread 0x7ffff7dbd6c0 (LWP 10202) exited]^M
FAIL: gdb.threads/step-N-all-progress.exp: non-stop=on: target-non-stop=on: \
next 3 (timeout)
...
The problem is that this test:
...
gdb_test "next 3" "return 0;"
...
expects no output after the prompt.
Fix this by using -no-prompt-anchor.
Tested on x86_64-linux.
|
|
History Of This Patch
=====================
This commit aims to address PR gdb/21699. There have now been a
couple of attempts to fix this issue. Simon originally posted two
patches back in 2021:
https://sourceware.org/pipermail/gdb-patches/2021-July/180894.html
https://sourceware.org/pipermail/gdb-patches/2021-July/180896.html
Before Pedro then posted a version of his own:
https://sourceware.org/pipermail/gdb-patches/2021-July/180970.html
After this the conversation halted. Then in 2023 I (Andrew) also took
a look at this bug and posted two versions:
https://sourceware.org/pipermail/gdb-patches/2023-April/198570.html
https://sourceware.org/pipermail/gdb-patches/2023-April/198680.html
The approach taken in my first patch was pretty similar to what Simon
originally posted back in 2021. My second attempt was only a slight
variation on the first.
Pedro then pointed out his older patch, and so we arrive at this
patch. The GDB changes here are mostly Pedro's work, but updated by
me (Andrew), any mistakes are mine.
The tests here are a combinations of everyone's work, and the commit
message is new, but copies bits from everyone's earlier work.
Problem Description
===================
Bug PR gdb/21699 makes the observation that using $_as_string with
GDB's printf can cause GDB to print unexpected data from the
inferior. The reproducer is pretty simple:
#include <stddef.h>
static char arena[100];
/* Override malloc() so value_coerce_to_target() gets a known
pointer, and we know we"ll see an error if $_as_string() gives
a string that isn't null terminated. */
void
*malloc (size_t size)
{
memset (arena, 'x', sizeof (arena));
if (size > sizeof (arena))
return NULL;
return arena;
}
int
main ()
{
return 0;
}
And then in a GDB session:
$ gdb -q test
Reading symbols from /tmp/test...
(gdb) start
Temporary breakpoint 1 at 0x4004c8: file test.c, line 17.
Starting program: /tmp/test
Temporary breakpoint 1, main () at test.c:17
17 return 0;
(gdb) printf "%s\n", $_as_string("hello")
"hello"xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
(gdb) quit
The problem above is caused by how value_cstring is used within
py-value.c, but once we understand the issue then it turns out that
value_cstring is used in an unexpected way in many places within GDB.
Within py-value.c we have a null-terminated C-style string. We then
pass a pointer to this string, along with the length of this
string (so not including the null-character) to value_cstring.
In value_cstring GDB allocates an array value of the given character
type, and copies in requested number of characters. However
value_cstring does not add a null-character of its own. This means
that the value created by calling value_cstring is only
null-terminated if the null-character is included in the passed in
length. In py-value.c this is not the case, and indeed, in most uses
of value_cstring, this is not the case.
When GDB tries to print one of these strings the value contents are
pushed to the inferior, and then read back as a C-style string, that
is, GDB reads inferior memory until it finds a null-terminator. For
the py-value.c case, no null-terminator is pushed into the inferior,
so GDB will continue reading inferior memory until a null-terminator
is found, with unpredictable results.
Patch Description
=================
The first thing this patch does is better define what the arguments
for the two function value_cstring and value_string should represent.
The comments in the header file are updated to describe whether the
length argument should, or should not, include a null-character.
Also, the data argument is changed to type gdb_byte. The functions as
they currently exist will handle wide-characters, in which case more
than one 'char' would be needed for each character. As such using
gdb_byte seems to make more sense.
To avoid adding casts throughout GDB, I've also added an overload that
still takes a 'char *', but asserts that the character type being used
is of size '1'.
The value_cstring function is now responsible for adding a null
character at the end of the string value it creates.
However, once we start looking at how value_cstring is used, we
realise there's another, related, problem. Not every language's
strings are null terminated. Fortran and Ada strings, for example,
are just an array of characters, GDB already has the function
value_string which can be used to create such values.
Consider this example using current GDB:
(gdb) set language ada
(gdb) p $_gdb_setting("arch")
$1 = (97, 117, 116, 111)
(gdb) ptype $
type = array (1 .. 4) of char
(gdb) p $_gdb_maint_setting("test-settings string")
$2 = (0)
(gdb) ptype $
type = array (1 .. 1) of char
This shows two problems, first, the $_gdb_setting and
$_gdb_maint_setting functions are calling value_cstring using the
builtin_char character, rather than a language appropriate type. In
the first call, the 'arch' case, the value_cstring call doesn't
include the null character, so the returned array only contains the
expected characters. But, in the $_gdb_maint_setting example we do
end up including the null-character, even though this is not expected
for Ada strings.
This commit adds a new language method language_defn::value_string,
this function takes a pointer and length and creates a language
appropriate value that represents the string. For C, C++, etc this
will be a null-terminated string (by calling value_cstring), and for
Fortran and Ada this can be a bounded array of characters with no null
terminator. Additionally, this new language_defn::value_string
function is responsible for selecting a language appropriate character
type.
After this commit the only calls to value_cstring are from the C
expression evaluator and from the default language_defn::value_string.
And the only calls to value_string are from Fortan, Ada, and ObjectC
related code.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=21699
Co-Authored-By: Simon Marchi <simon.marchi@efficios.com>
Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
Co-Authored-By: Pedro Alves <pedro@palves.net>
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
Fix grammar in some comments and docs:
- machines that doesn't -> machines that don't
- its a -> it's a
- its the -> it's the
- if does its not -> if it does it's not
- one more instructions if doesn't match ->
one more instruction if it doesn't match
- it's own -> its own
- it's first -> its first
- it's pointer -> its pointer
I also came across "it's performance" in gdb/stubs/*-stub.c in the HP public
domain notice, I've left that alone.
Tested on x86_64-linux.
|
|
Fix some more typos:
- distinquish -> distinguish
- actualy -> actually
- singe -> single
- frash -> frame
- chid -> child
- dissassembler -> disassembler
- uninitalized -> uninitialized
- precontidion -> precondition
- regsiters -> registers
- marge -> merge
- sate -> state
- garanteed -> guaranteed
- explictly -> explicitly
- prefices (nonstandard plural) -> prefixes
- bondary -> boundary
- formated -> formatted
- ithe -> the
- arrav -> array
- coresponding -> corresponding
- owend -> owned
- fials -> fails
- diasm -> disasm
- ture -> true
- tpye -> type
There's one code change, the name of macro SIG_CODE_BONDARY_FAULT changed to
SIG_CODE_BOUNDARY_FAULT.
Tested on x86_64-linux.
|
|
Fix a few typos:
- implemention -> implementation
- convertion(s) -> conversion(s)
- backlashes -> backslashes
- signoring -> ignoring
- (un)ambigious -> (un)ambiguous
- occured -> occurred
- hidding -> hiding
- temporarilly -> temporarily
- immediatelly -> immediately
- sillyness -> silliness
- similiar -> similar
- porkuser -> pokeuser
- thats -> that
- alway -> always
- supercede -> supersede
- accomodate -> accommodate
- aquire -> acquire
- priveleged -> privileged
- priviliged -> privileged
- priviledges -> privileges
- privilige -> privilege
- recieve -> receive
- (p)refered -> (p)referred
- succesfully -> successfully
- successfuly -> successfully
- responsability -> responsibility
- wether -> whether
- wich -> which
- disasbleable -> disableable
- descriminant -> discriminant
- construcstor -> constructor
- underlaying -> underlying
- underyling -> underlying
- structureal -> structural
- appearences -> appearances
- terciarily -> tertiarily
- resgisters -> registers
- reacheable -> reachable
- likelyhood -> likelihood
- intepreter -> interpreter
- disassemly -> disassembly
- covnersion -> conversion
- conviently -> conveniently
- atttribute -> attribute
- struction -> struct
- resonable -> reasonable
- popupated -> populated
- namespaxe -> namespace
- intialize -> initialize
- identifer(s) -> identifier(s)
- expection -> exception
- exectuted -> executed
- dungerous -> dangerous
- dissapear -> disappear
- completly -> completely
- (inter)changable -> (inter)changeable
- beakpoint -> breakpoint
- automativ -> automatic
- alocating -> allocating
- agressive -> aggressive
- writting -> writing
- reguires -> requires
- registed -> registered
- recuding -> reducing
- opeartor -> operator
- ommitted -> omitted
- modifing -> modifying
- intances -> instances
- imbedded -> embedded
- gdbaarch -> gdbarch
- exection -> execution
- direcive -> directive
- demanged -> demangled
- decidely -> decidedly
- argments -> arguments
- agrument -> argument
- amespace -> namespace
- targtet -> target
- supress(ed) -> suppress(ed)
- startum -> stratum
- squence -> sequence
- prompty -> prompt
- overlow -> overflow
- memember -> member
- languge -> language
- geneate -> generate
- funcion -> function
- exising -> existing
- dinking -> syncing
- destroh -> destroy
- clenaed -> cleaned
- changep -> changedp (name of variable)
- arround -> around
- aproach -> approach
- whould -> would
- symobl -> symbol
- recuse -> recurse
- outter -> outer
- freeds -> frees
- contex -> context
Tested on x86_64-linux.
Reviewed-By: Tom Tromey <tom@tromey.com>
|
|
When running the test-case gdb.tui/wrap-line.exp with a build configured with
--disable-tui, we run into:
...
(gdb) PASS: gdb.tui/wrap-line.exp: width-hard-coded: set width 50
tui new-layout command-layout cmd 1^M
Undefined command: "tui". Try "help".^M
(gdb) ERROR: Undefined command "tui new-layout command-layout cmd 1".
...
Fix this by guarding the command with allow_tui_tests.
Tested on x86_64-linux.
|
|
When running test-case gdb.tui/pr30056.exp with target board
native-extended-gdbserver, I run into:
...
Quit^[[K^M^[[B(gdb) PASS: gdb.tui/pr30056.exp: Control-C
Remote debugging from host ::1, port 38810^M
^M(failed reverse-i-search)`xyz': ^M(gdb) target extended-remote \
localhost:2346^[[7GWARNING: Timed out waiting for EOF in server after \
monitor exit
...
This is due to the fact that ^C doesn't abort the reverse-i-search. This
appears to be due to a readline problem. A PR is open about this: PR
cli/30498.
Add a KFAIL for the PR, and ensure that the isearch is aborted by using ^G,
such that we have a responsive prompt to handle the "monitor exit" command
that native-extended-gdbserver issues.
Tested on x86_64-linux.
|
|
I added a cmd-only layout:
...
(gdb) tui new-layout cmd cmd 1
...
and set it:
...
(gdb) layout cmd
...
which gave me the expect result: only the cmd window in the screen.
However, after going back to layout src:
...
(gdb) layout src
...
I got a source window with only one line in it, and the cmd window taking most
of the screen.
I traced this back to tui_set_layout, where for both the old and the new
layout the fingerprint of the cmd window in the layout is taken. If the
fingerprint is the same, an effort will be done to preserve the command
window size.
The fingerprint is "VC" for both the old (cmd) and new (src) layouts, which
explains the behaviour.
I think this is essentially a bug in the finger print calculation, and it
should be "C" for the cmd layout.
Fix this by not adding a V or H in the fingerprint if the list size is one.
Tested on x86_64-linux.
Reviewed-By: Tom Tromey <tom@tromey.com>
|
|
This commit adds a new format for the printf and dprintf commands:
'%V'. This new format takes any GDB expression and formats it as a
string, just as GDB would for a 'print' command, e.g.:
(gdb) print a1
$a = {2, 4, 6, 8, 10, 12, 14, 16, 18, 20}
(gdb) printf "%V\n", a1
{2, 4, 6, 8, 10, 12, 14, 16, 18, 20}
(gdb)
It is also possible to pass the same options to %V as you might pass
to the print command, e.g.:
(gdb) print -elements 3 -- a1
$4 = {2, 4, 6...}
(gdb) printf "%V[-elements 3]\n", a1
{2, 4, 6...}
(gdb)
This new feature would effectively replace an existing feature of GDB,
the $_as_string builtin convenience function. However, the
$_as_string function has a few problems which this new feature solves:
1. $_as_string doesn't currently work when the inferior is not
running, e.g:
(gdb) printf "%s", $_as_string(a1)
You can't do that without a process to debug.
(gdb)
The reason for this is that $_as_string returns a value object with
string type. When we try to print this we call value_as_address,
which ends up trying to push the string into the inferior's address
space.
Clearly we could solve this problem, the string data exists in GDB, so
there's no reason why we have to push it into the inferior, but this
is an existing problem that would need solving.
2. $_as_string suffers from the fact that C degrades arrays to
pointers, e.g.:
(gdb) printf "%s\n", $_as_string(a1)
0x404260 <a1>
(gdb)
The implementation of $_as_string is passed a gdb.Value object that is
a pointer, it doesn't understand that it's actually an array. Solving
this would be harder than issue #1 I think. The whole array to
pointer transformation is part of our expression evaluation. And in
most cases this is exactly what we want. It's not clear to me how
we'd (easily) tell GDB that we didn't want this reduction in _some_
cases. But I'm sure this is solvable if we really wanted to.
3. $_as_string is a gdb.Function sub-class, and as such is passed
gdb.Value objects. There's no super convenient way to pass formatting
options to $_as_string. By this I mean that the new %V feature
supports print formatting options. Ideally, we might want to add this
feature to $_as_string, we might imagine it working something like:
(gdb) printf "%s\n", $_as_string(a1,
elements = 3,
array_indexes = True)
where the first item is the value to print, while the remaining
options are the print formatting options. However, this relies on
Python calling syntax, which isn't something that convenience
functions handle. We could possibly rely on strictly positional
arguments, like:
(gdb) printf "%s\n", $_as_string(a1, 3, 1)
But that's clearly terrible as there's far more print formatting
options, and if you needed to set the 9th option you'd need to fill in
all the previous options.
And right now, the only way to pass these options to a gdb.Function is
to have GDB first convert them all into gdb.Value objects, which is
really overkill for what we want.
The new %V format solves all these problems: the string is computed
and printed entirely on the GDB side, we are able to print arrays as
actual arrays rather than pointers, and we can pass named format
arguments.
Finally, the $_as_string is sold in the manual as allowing users to
print the string representation of flag enums, so given:
enum flags
{
FLAG_A = (1 << 0),
FLAG_B = (1 << 1),
FLAG_C = (1 << 1)
};
enum flags ff = FLAG_B;
We can:
(gdb) printf "%s\n", $_as_string(ff)
FLAG_B
This works just fine with %V too:
(gdb) printf "%V\n", ff
FLAG_B
So all functionality of $_as_string is replaced by %V. I'm not
proposing to remove $_as_string, there might be users currently
depending on it, but I am proposing that we don't push $_as_string in
the documentation.
As %V is a feature of printf, GDB's dprintf breakpoints naturally gain
access to this feature too. dprintf breakpoints can be operated in
three different styles 'gdb' (use GDB's printf), 'call' (call a
function in the inferior), or 'agent' (perform the dprintf on the
remote).
The use of '%V' will work just fine when dprintf-style is 'gdb'.
When dprintf-style is 'call' the format string and arguments are
passed to an inferior function (printf by default). In this case GDB
doesn't prevent use of '%V', but the documentation makes it clear that
support for '%V' will depend on the inferior function being called.
I chose this approach because the current implementation doesn't place
any restrictions on the format string when operating in 'call' style.
That is, the user might already be calling a function that supports
custom print format specifiers (maybe including '%V') so, I claim, it
would be wrong to block use of '%V' in this case. The documentation
does make it clear that users shouldn't expect this to "just work"
though.
When dprintf-style is 'agent' then GDB does no support the use of
'%V' (right now). This is handled at the point when GDB tries to
process the format string and send the dprintf command to the remote,
here's an example:
Reading symbols from /tmp/hello.x...
(gdb) dprintf call_me, "%V", a1
Dprintf 1 at 0x401152: file /tmp/hello.c, line 8.
(gdb) set sysroot /
(gdb) target remote | gdbserver --once - /tmp/hello.x
Remote debugging using | gdbserver --once - /tmp/hello.x
stdin/stdout redirected
Process /tmp/hello.x created; pid = 3088822
Remote debugging using stdio
Reading symbols from /lib64/ld-linux-x86-64.so.2...
(No debugging symbols found in /lib64/ld-linux-x86-64.so.2)
0x00007ffff7fd3110 in _start () from /lib64/ld-linux-x86-64.so.2
(gdb) set dprintf-style agent
(gdb) c
Continuing.
Unrecognized format specifier 'V' in printf
Command aborted.
(gdb)
This is exactly how GDB would handle any other invalid format
specifier, for example:
Reading symbols from /tmp/hello.x...
(gdb) dprintf call_me, "%Q", a1
Dprintf 1 at 0x401152: file /tmp/hello.c, line 8.
(gdb) set sysroot /
(gdb) target remote | gdbserver --once - /tmp/hello.x
Remote debugging using | gdbserver --once - /tmp/hello.x
stdin/stdout redirected
Process /tmp/hello.x created; pid = 3089193
Remote debugging using stdio
Reading symbols from /lib64/ld-linux-x86-64.so.2...
(No debugging symbols found in /lib64/ld-linux-x86-64.so.2)
0x00007ffff7fd3110 in _start () from /lib64/ld-linux-x86-64.so.2
(gdb) set dprintf-style agent
(gdb) c
Continuing.
Unrecognized format specifier 'Q' in printf
Command aborted.
(gdb)
The error message isn't the greatest, but improving that can be put
off for another day I hope.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Acked-By: Simon Marchi <simon.marchi@efficios.com>
|
|
Simon reported that the new test-case gdb.tui/pr30056.exp fails with system
readline.
This is because the test-case requires a fix in readline that's present in our
in-repo copy of readline, but most likely not in any system readline yet.
Fix this by:
- mentioning --with-system-readline or --without-system-readline in the
configuration string.
- adding a new proc with_system_readline that makes this information available
in the testsuite.
- using this in test-case gdb.tui/pr30056.exp to declare it unsupported for
--with-system-readline.
Tested on x86_64-linux.
Reported-By: Simon Marchi <simon.marchi@efficios.com>
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
I came across a bug in the implementation of line feed in tuiterm, and added a
unit test that exposes it.
Before sending the line feed we have:
...
Screen Dump (size 8 columns x 4 rows, cursor at column 0, row 3):
0 abcdefgh
1 ijklmnop
2 qrstuvwx
3 yz01234
...
and after it we have:
...
Screen Dump (size 8 columns x 4 rows, cursor at column 0, row 1):
0 ijklmnop
1 qrstuvwx
2 yz01234
3 yz01234
...
Note how the cursor started at row 3 and after the line feed ended up at
row 1, while it should have stayed in row 3.
Fix this by moving "incr _cur_row -1" one level up in the loop nest in
proc _ctl_0x0a.
Tested on x86_64-linux.
|
|
I stumbled on the mi_proceeded and running_result_record_printed
globals, which are shared by all MI interpreter instances (it's unlikely
that people use multiple MI interpreter instances, but it's possible).
After poking at it, I found this bug:
1. Start GDB in MI mode
2. Add a second MI interpreter with the new-ui command
3. Use -exec-run on the second interpreter
This is the output I get on the first interpreter:
=thread-group-added,id="i1"
~"Reading symbols from a.out...\n"
~"New UI allocated\n"
(gdb)
=thread-group-started,id="i1",pid="94718"
=thread-created,id="1",group-id="i1"
^running
*running,thread-id="all"
And this is the output I get on the second intepreter:
=thread-group-added,id="i1"
(gdb)
-exec-run
=thread-group-started,id="i1",pid="94718"
=thread-created,id="1",group-id="i1"
*running,thread-id="all"
The problem here is that the `^running` reply to the -exec-run command
is printed on the wrong UI. It is printed on the first one, it should
be printed on the second (the one on which we sent the -exec-run).
What happens under the hood is that captured_mi_execute_command, while
executing a command for the second intepreter, clears the
running_result_record_printed and mi_proceeded globals.
mi_about_to_proceed then sets mi_proceeded. Then, mi_on_resume_1 gets
called for the first intepreter first. Since the
!running_result_record_printed && mi_proceeded
condition is true, it prints a ^running, and sets
running_result_record_printed. When mi_on_resume_1 gets called for the
second interpreter, running_result_record_printed is already set, so
^running is not printed there.
It took me a while to understand the relationship between these two
variables. I think that in the end, this is what we want to track:
1. When executing an MI command, take note if that command causes a
"proceed". This is done in mi_about_to_proceed.
2. In mi_on_resume_1, if the command indeed caused a "proceed", we want
to output a ^running record. And we want to remember that we did,
because...
3. Back in captured_mi_execute_command, if we did not output a
^running, we want to output a ^done.
Moving those two variables to the mi_interp struture appears to fix it.
Only for the interpreter doing the -exec-run command does the
running_result_record_printed flag get cleared, and therefore only or
that one does the ^running record get printed.
Add a new test for this, that does pretty much what the reproducer above
shows. Without the fix, the test fails because
mi_send_resuming_command_raw never sees the ^running record.
Change-Id: I63ea30e6cb61a8e1dd5ef03377e6003381a9209b
Tested-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
|
|
Consider the following scenario. We start gdb in TUI mode:
...
$ gdb -q -tui
...
and type ^R which gives us the reverse-isearch prompt in the cmd window:
...
(reverse-i-search)`':
...
and then type "foo", right-arrow-key, and ^C.
In TUI mode, gdb uses a custom rl_getc_function tui_getc.
When pressing the right-arrow-key, tui_getc:
- attempts to scroll the TUI src window, without any effect, and
- returns 0.
The intention of returning 0 is mentioned here in tui_dispatch_ctrl_char:
...
/* We intercepted the control character, so return 0 (which readline
will interpret as a no-op). */
return 0;
...
However, after this 0 is returned by the rl_read_key () call in
_rl_search_getchar, _rl_read_mbstring is called, which incorrectly interprets
0 as the first part of an utf-8 multibyte char, and tries to read the next
char.
In this state, the ^C takes effect and we run into a double free because
_rl_isearch_cleanup is called twice.
Both these issues need fixing independently, though after fixing the first we
no longer trigger the second.
The first issue is caused by the subtle difference between:
- a char array containing 0 chars, which is zero-terminated, and
- a char array containing 1 char, which is zero.
In mbrtowc terms, this is the difference between:
...
mbrtowc (&wc, "", 0, &ps);
...
which returns -2, and:
...
mbrtowc (&wc, "", 1, &ps);
...
which returns 0.
Note that _rl_read_mbstring calls _rl_get_char_len without passing it an
explicit length parameter, and consequently it cannot distinguish between the
two, and defaults to the "0 chars" choice.
Note that the same problem doesn't exist in _rl_read_mbchar.
Fix this by defaulting to the "1 char" choice in _rl_get_char_len:
...
- if (_rl_utf8locale && l > 0 && UTF8_SINGLEBYTE(*src))
+ if (_rl_utf8locale && l >= 0 && UTF8_SINGLEBYTE(*src))
...
The second problem happens when the call to _rl_search_getchar in
_rl_isearch_callback returns. At that point _rl_isearch_cleanup has already
been called from the signal handler, but we proceed regardless, using a cxt
pointer that has been freed.
Fix this by checking for "RL_ISSTATE (RL_STATE_ISEARCH)" after the call to
_rl_search_getchar:
...
c = _rl_search_getchar (cxt);
+ if (!RL_ISSTATE (RL_STATE_ISEARCH))
+ return 1;
...
Tested on x86_64-linux.
Approved-By: Chet Ramey <chet.ramey@case.edu>
PR tui/30056
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30056
|
|
Add a test-case that sets a prompt with color in TUI.
The line containing the prompt is shown by get_line_with_attrs as follows:
...
<fg:31>(gdb) <fg:default>
...
The 31 means red, but only for foreground colors, for background colors 41
means red.
Make this more readable by using color names for both foreground and
background, such that we have instead:
....
<fg:red>(gdb) <fg:default>
...
Tested on x86_64-linux.
|
|
I noticed curses using the invisible and blinking attributes.
Add these in tuiterm.
Tested on x86_64-linux.
|
|
I noticed in proc Term::_csi_m arguments that while parameters 7 and 27 are
supposed to set the reverse attribute to 1 and 0, in fact it's set to 1 in
both cases:
...
7 {
set _attrs(reverse) 1
}
...
27 {
set _attrs(reverse) 1
}
...
Fix this and add a regression test in gdb.tui/tuiterm.exp.
Tested on x86_64-linux.
|
|
After this commit:
commit ed32754a8c7919feffc6ddb66ff1c532e4a4d1cd
Date: Thu Mar 9 10:45:03 2023 +0100
[gdb/testsuite] Fix gdb.server/multi-ui-errors.exp for remote target
I noticed the occasional failure in gdb.server/multi-ui-errors.exp,
which looked like this:
(gdb) PASS: gdb.server/multi-ui-errors.exp: interact with GDB's main UI
interrupt
(gdb)
Program received signal SIGINT, Interrupt.
0x00007ffff7d501e7 in nanosleep () from /lib64/libc.so.6
FAIL: gdb.server/multi-ui-errors.exp: interrupt (timeout)
PASS: gdb.server/multi-ui-errors.exp: interrupt arrived
p server_pid
$1 = 718174
(gdb) PASS: gdb.server/multi-ui-errors.exp: p server_pid
This is triggered by this code in gdb.server/multi-ui-errors.exp:
gdb_test "interrupt"
gdb_test_multiple "" "interrupt arrived" {
-re "Program received signal SIGINT, Interrupt\\.\r\n" {
pass $gdb_test_name
}
}
The problem here is that the first interrupt will trigger the prompt
to be printed, and then, after some time the inferior will be
interrupted.
However the default pattern for gdb_test includes a '$' end anchor.
If expect sees the prompt with nothing following it then everything is
fine, and the test passes.
However, if the interrupt is quick and so what expect sees is this:
(gdb)
Program received signal SIGINT, Interrupt.
0x00007ffff7d501e7 in nanosleep () from /lib64/libc.so.6
In this case the end anchor means that the gdb_test fails to match,
and eventually times out.
Fix this by passing -no-prompt-anchor to gdb_test.
Reviewed-By: Tom de Vries <tdevries@suse.de>
|
|
If a header file defining a static function is included in multiple source
files, each calling the function, and GDB is asked to jump to a line inside
that function, there would be multiple locations matching the target. The
solution in this commit is to select the location in the current symtab.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
This patch augments the DAP launch request with some optional new
parameters that let the client control the command-line arguments and
the environment of the inferior.
Reviewed-By: Andrew Burgess <aburgess@redhat.com>
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
|
|
This adds two new attributes and three new methods to gdb.Inferior.
The attributes let Python code see the command-line arguments and the
name of "main". Argument setting is also supported.
The methods let Python code manipulate the inferior's environment
variables.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
|
|
DAP specifies that if an evaluate request does not have a frameID
parameter, then the expression is evaluated in the global scope.
|
|
This adds a 'global_context' parse_and_eval to gdb.parse_and_eval.
This lets users request a parse that is done at "global scope".
I considered letting callers pass in a block instead, with None
meaning "global" -- but then there didn't seem to be a clean way to
express the default for this parameter.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
|
|
This implements the DAP loadedSources request, using gdb.execute_mi to
avoid having to write another custom Python API.
|
