This changes the value_lazy and set_value_lazy functions to be methods
of value. Much of this patch was written by script.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
This commit introduces the idea of loading only part of an array in
order to print it, what I call "limited length" arrays.
The motivation behind this work is to make it possible to print slices
of very large arrays, where very large means bigger than
`max-value-size'.
Consider this GDB session with the current GDB:
(gdb) set max-value-size 100
(gdb) p large_1d_array
value requires 400 bytes, which is more than max-value-size
(gdb) p -elements 10 -- large_1d_array
value requires 400 bytes, which is more than max-value-size
notice that the request to print 10 elements still fails, even though 10
elements should be less than the max-value-size. With a patched version
of GDB:
(gdb) p -elements 10 -- large_1d_array
$1 = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9...}
So now the print has succeeded. It also has loaded `max-value-size'
worth of data into value history, so the recorded value can be accessed
consistently:
(gdb) p -elements 10 -- $1
$2 = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9...}
(gdb) p $1
$3 = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19,
20, 21, 22, 23, 24, <unavailable> <repeats 75 times>}
(gdb)
Accesses with other languages work similarly, although for Ada only
C-style [] array element/dimension accesses use history. For both Ada
and Fortran () array element/dimension accesses go straight to the
inferior, bypassing the value history just as with C pointers.
Co-Authored-By: Maciej W. Rozycki <macro@embecosm.com>
This commit splits the `set/show print elements' option into two. We
retain `set/show print elements' for controlling how many elements of an
array we print, but a new `set/show print characters' setting is added
which is used for controlling how many characters of a string are
printed.
The motivation behind this change is to allow users a finer level of
control over how data is printed, reflecting that, although strings can
be thought of as arrays of characters, users often want to treat these
two things differently.
For compatibility reasons by default the `set/show print characters'
option is set to `elements', which makes the limit for character strings
follow the setting of the `set/show print elements' option, as it used
to. Using `set print characters' with any other value makes the limit
independent from the `set/show print elements' setting, however it can
be restored to the default with the `set print characters elements'
command at any time.
A corresponding `-characters' option for the `print' command is added,
with the same semantics, i.e. one can use `elements' to make a given
`print' invocation follow the limit of elements, be it set with the
`-elements' option also given with the same invocation or taken from the
`set/show print elements' setting, for characters as well regardless of
the current setting of the `set/show print characters' option.
The GDB changes are all pretty straightforward, just changing references
to the old 'print_max' to use a new `get_print_max_chars' helper which
figures out which of the two of `print_max' and `print_max_chars' values
to use.
Likewise, the documentation is just updated to reference the new setting
where appropriate.
To make people's life easier the message shown by `show print elements'
now indicates if the setting also applies to character strings:
(gdb) set print characters elements
(gdb) show print elements
Limit on string chars or array elements to print is 200.
(gdb) set print characters unlimited
(gdb) show print elements
Limit on array elements to print is 200.
(gdb)
and the help text shows the dependency as well:
(gdb) help set print elements
Set limit on array elements to print.
"unlimited" causes there to be no limit.
This setting also applies to string chars when "print characters"
is set to "elements".
(gdb)
In the testsuite there are two minor updates, one to add `-characters'
to the list of completions now shown for the `print' command, and a bare
minimum pair of checks for the right handling of `set print characters'
and `show print characters', copied from the corresponding checks for
`set print elements' and `show print elements' respectively.
Co-Authored-By: Maciej W. Rozycki <macro@embecosm.com>
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Rather than just `unlimited' allow the integer set commands (or command
options) to define arbitrary keywords for the user to use, removing
hardcoded arrangements for the `unlimited' keyword.
Remove the confusingly named `var_zinteger', `var_zuinteger' and
`var_zuinteger_unlimited' `set'/`show' command variable types redefining
them in terms of `var_uinteger', `var_integer' and `var_pinteger', which
have the range of [0;UINT_MAX], [INT_MIN;INT_MAX], and [0;INT_MAX] each.
Following existing practice `var_pinteger' allows extra negative values
to be used, however unlike `var_zuinteger_unlimited' any number of such
values can be defined rather than just `-1'.
The "p" in `var_pinteger' stands for "positive", for the lack of a more
appropriate unambiguous letter, even though 0 obviously is not positive;
"n" would be confusing as to whether it stands for "non-negative" or
"negative".
Add a new structure, `literal_def', the entries of which define extra
keywords allowed for a command and numerical values they correspond to.
Those values are not verified against the basic range supported by the
underlying variable type, allowing extra values to be allowed outside
that range, which may or may not be individually made visible to the
user. An optional value translation is possible with the structure to
follow the existing practice for some commands where user-entered 0 is
internally translated to UINT_MAX or INT_MAX. Such translation can now
be arbitrary. Literals defined by this structure are automatically used
for completion as necessary.
So for example:
const literal_def integer_unlimited_literals[] =
{
{ "unlimited", INT_MAX, 0 },
{ nullptr }
};
defines an extra `unlimited' keyword and a user-visible 0 value, both of
which get translated to INT_MAX for the setting to be used with.
Similarly:
const literal_def zuinteger_unlimited_literals[] =
{
{ "unlimited", -1, -1 },
{ nullptr }
};
defines the same keyword and a corresponding user-visible -1 value that
is used for the requested setting. If the last member were omitted (or
set to `{}') here, then only the keyword would be allowed for the user
to enter and while -1 would still be used internally trying to enter it
as a part of a command would result in an "integer -1 out of range"
error.
Use said error message in all cases (citing the invalid value requested)
replacing "only -1 is allowed to set as unlimited" previously used for
`var_zuinteger_unlimited' settings only rather than propagating it to
`var_pinteger' type. It could only be used for the specific case where
a single extra `unlimited' keyword was defined standing for -1 and the
use of numeric equivalents is discouraged anyway as it is for historical
reasons only that they expose GDB internals, confusingly different
across variable types. Similarly update the "must be >= -1" Guile error
message.
Redefine Guile and Python parameter types in terms of the new variable
types and interpret extra keywords as Scheme keywords and Python strings
used to communicate corresponding parameter values. Do not add a new
PARAM_INTEGER Guile parameter type, however do handle the `var_integer'
variable type now, permitting existing parameters defined by GDB proper,
such as `listsize', to be accessed from Scheme code.
With these changes in place it should be trivial for a Scheme or Python
programmer to expand the syntax of the `make-parameter' command and the
`gdb.Parameter' class initializer to have arbitrary extra literals along
with their internal representation supplied.
Update the testsuite accordingly.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
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.
PR c++/29243 points out that "info func" on a certain C++ executable
will cause an infinite loop in gdb.
I tracked this down to a bug introduced by commit 6b5a7bc76 ("Handle
member pointers directly in generic_value_print"). Before this
commit, the C++ code to print a member pointer would wind up calling
value_print_scalar_formatted; but afterward it simply calls
generic_value_print and gets into a loop.
This patch restores the previous behavior and adds a regression test.
A user noticed that gdb would crash when printing a packed array after
doing "set lang c". Packed arrays don't exist in C, but it's
occasionally useful to print things in C mode when working in a non-C
language -- this lets you see under the hood a little bit.
The bug here is that generic value printing does not handle packed
arrays at all. This patch fixes the bug by introducing a new function
to extract a value from a bit offset and width.
The new function includes a hack to avoid problems with some existing
test cases when using -fgnat-encodings=all. Cleaning up this code
looked difficult, and since "all" is effectively deprecated, I thought
it made sense to simply work around the problems.
Currently, every internal_error call must be passed __FILE__/__LINE__
explicitly, like:
internal_error (__FILE__, __LINE__, "foo %d", var);
The need to pass in explicit __FILE__/__LINE__ is there probably
because the function predates widespread and portable variadic macros
availability. We can use variadic macros nowadays, and in fact, we
already use them in several places, including the related
gdb_assert_not_reached.
So this patch renames the internal_error function to something else,
and then reimplements internal_error as a variadic macro that expands
__FILE__/__LINE__ itself.
The result is that we now should call internal_error like so:
internal_error ("foo %d", var);
Likewise for internal_warning.
The patch adjusts all calls sites. 99% of the adjustments were done
with a perl/sed script.
The non-mechanical changes are in gdbsupport/errors.h,
gdbsupport/gdb_assert.h, and gdb/gdbarch.py.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Change-Id: Ia6f372c11550ca876829e8fd85048f4502bdcf06
print_wchar keeps track of when escape sequences are emitted, to force
an escape sequence if needed by a subsequent character. For example
for the string concatenation "\0" "1", gdb will print "\000\061" --
because printing "\0001" might be confusing.
However, this code has two errors. First, this logic is not needed
for octal escapes, because there is a length limit of 3 for octal
escapes, and gdb always prints these with "%.3o". Second, though,
this *is* needed for hex escapes, because those do not have a length
limit.
This patch fixes these problems and adds the appropriate tests.
print_wchar uses wchar_printable, but this isn't needed -- all the
relevant cases are already handled by the 'switch'. This changes the
code to use gdb_iswprint, and removes a somewhat confusing comment
related to this code.
generic_printstr prints an empty string like:
fputs_filtered ("\"\"", stream);
However, this seems wrong to me if the quote character is something
other than double quote. This patch fixes this latent bug. Thanks to
Andrew for the test case.
Co-authored-by: Andrew Burgess <aburgess@redhat.com>
When debugging cc1 I heavily rely on simple one-parameter debug functions
that allow me to inspect a variable of a common type, like:
- debug_generic_expr
- debug_gimple_stmt
- debug_rtx
and I miss similar functions in gdb.
Add functions to dump variables of types 'value' and 'expression':
- debug_exp, and
- debug_val.
Tested on x86_64-linux, by breaking on varobj_create, and doing:
...
(gdb) call debug_exp (var->root->exp.get ())
&"Operation: OP_VAR_VALUE\n"
&" Block symbol:\n"
&" Symbol: aaa\n"
&" Block: 0x2d064f0\n"
(gdb)
...
and:
...
(gdb) call debug_val (value)
&"5"
(gdb)
...
'finish_print' does not really belong in value_print_options -- this
is consulted only when deciding whether or not to print a value, and
never during the course of printing. This patch removes it from the
structure and makes it a static global in infcmd.c instead.
Tested on x86-64 Fedora 34.
Make an introduction of a new print setting that can be set by 'set
print nibbles [on|off]'. The default value if OFF, which can be changed
by user manually. Of course, 'show print nibbles' is also included in
the patch.
The new feature displays binary values by group, with four bits per
group. The motivation for this work is to enhance the readability of
binary values.
Here's a GDB session before this patch is applied.
(gdb) print var_a
$1 = 1230
(gdb) print/t var_a
$2 = 10011001110
With this patch applied, we can use the new print setting to display the
new form of the binary values.
(gdb) print var_a
$1 = 1230
(gdb) print/t var_a
$2 = 10011001110
(gdb) set print nibbles on
(gdb) print/t var_a
$3 = 0100 1100 1110
Tested on x86_64 openSUSE Tumbleweed.
target_read_string takes a byte order parameter, but only uses this to
check whether a given character is zero. This is readily done without
requiring the parameter, so remove it.
Now that filtered and unfiltered output can be treated identically, we
can unify the printf family of functions. This is done under the name
"gdb_printf". Most of this patch was written by script.
Now that filtered and unfiltered output can be treated identically, we
can unify the putc family of functions. This is done under the name
"gdb_putc". Most of this patch was written by script.
Now that filtered and unfiltered output can be treated identically, we
can unify the puts family of functions. This is done under the name
"gdb_puts". Most of this patch was written by script.
I noticed that generic_value_print assumes that a subrange type is
always a subrange of an integer type. However, this isn't necessarily
the case. In Ada, for example, one has subranges of character and
enumeration types.
This code isn't often exercised, I think, because languages with real
subrange types tend to implement their own printers. However, it
still seemed worth fixing.
The only caller of do_val_print just does a small bit of work before
the call. This patch merges the two functions, and removes an
unnecessary local variable, making gdb a bit simpler.
I think it only really makes sense to call wrap_here with an argument
consisting solely of spaces. Given this, it seemed better to me that
the argument be an int, rather than a string. This patch is the
result. Much of it was written by a script.
This commit brings all the changes made by running gdb/copyright.py
as per GDB's Start of New Year Procedure.
For the avoidance of doubt, all changes in this commits were
performed by the script.
There's a common pattern to call add_basic_prefix_cmd and
add_show_prefix_cmd to add matching set and show commands. Add the
add_setshow_prefix_cmd function to factor that out and use it at a few
places.
Change-Id: I6e9e90a30e9efb7b255bf839cac27b85d7069cfd
The bug fixed by this [1] patch was caused by an out-of-bounds access to
a value's content. The code gets the value's content (just a pointer)
and then indexes it with a non-sensical index.
This made me think of changing functions that return value contents to
return array_views instead of a plain pointer. This has the advantage
that when GDB is built with _GLIBCXX_DEBUG, accesses to the array_view
are checked, making bugs more apparent / easier to find.
This patch changes the return types of these functions, and updates
callers to call .data() on the result, meaning it's not changing
anything in practice. Additional work will be needed (which can be done
little by little) to make callers propagate the use of array_view and
reap the benefits.
[1] https://sourceware.org/pipermail/gdb-patches/2021-September/182306.html
Change-Id: I5151f888f169e1c36abe2cbc57620110673816f3
When printing a variable x in a subroutine foo:
...
subroutine foo (x)
integer(4) :: x (*)
x(3) = 1
end subroutine foo
...
where x is an array with unknown bounds, we get:
...
$ gdb -q -batch outputs/gdb.fortran/array-no-bounds/array-no-bounds \
-ex "break foo" \
-ex run \
-ex "print x"
Breakpoint 1 at 0x4005cf: file array-no-bounds.f90, line 18.
Breakpoint 1, foo (x=...) at array-no-bounds.f90:18
18 x(3) = 1
$1 = <error reading variable>
...
Improve the error message by printing the details of the error, such that we
have instead:
...
$1 = <error reading variable: failed to get range bounds>
...
This is a change in gdb/valprint.c, and grepping through the sources reveals
that this is a common pattern.
Tested on x86_64-linux.
Remove the `TYPE_FIELD_NAME` and `FIELD_NAME` macros, changing all the
call sites to use field::name directly.
Change-Id: I6900ae4e1ffab1396e24fb3298e94bf123826ca6
The "val_print_type_code_flags ()" function is responsible for
extraction of fields for "flags" data type. These data types are
used when describing a custom register type in a target description
XML. The logic used for the extraction though is not sound:
unsigned field_len = TYPE_FIELD_BITSIZE (type, field);
ULONGEST field_val
= val >> (TYPE_FIELD_BITPOS (type, field) - field_len + 1);
TYPE_FIELD_BITSIZE: The bit length of the field to be extracted.
TYPE_FIELD_BITPOS: The starting position of the field; 0 is LSB.
val: The register value.
Imagine you have a field that starts at position 1 and its length
is 4 bits. According to the third line of the code snippet the
shifting right would become "val >> -2", or "val >> 0xfff...fe"
to be precise. That will result in a "field_val" of 0.
The correct extraction should be:
ULONGEST field_val = val >> TYPE_FIELD_BITPOS (type, field);
The rest of the algorithm that masks out the higher bits is OK.
Co-Authored-By: Simon Marchi <simon.marchi@efficios.com>
Same idea as previous patch, but for add_alias_cmd. Remove the overload
that accepts the target command as a string (the target command name),
leaving only the one that takes the cmd_list_element.
gdb/ChangeLog:
* command.h (add_alias_cmd): Accept target as
cmd_list_element. Update callers.
Change-Id: I546311f411e9e7da9302322d6ffad4e6c56df266
Previously, the prefixname field of struct cmd_list_element was manually
set for prefix commands. This seems verbose and error prone as it
required every single call to functions adding prefix commands to
specify the prefix name while the same information can be easily
generated.
Historically, this was not possible as the prefix field was null for
many commands, but this was fixed in commit
3f4d92ebdf by Philippe Waroquiers, so
we can rely on the prefix field being set when generating the prefix
name.
This commit also fixes a use after free in this scenario:
* A command gets created via Python (using the gdb.Command class).
The prefix name member is dynamically allocated.
* An alias to the new command is created. The alias's prefixname is set
to point to the prefixname for the original command with a direct
assignment.
* A new command with the same name as the Python command is created.
* The object for the original Python command gets freed and its
prefixname gets freed as well.
* The alias is updated to point to the new command, but its prefixname
is not updated so it keeps pointing to the freed one.
gdb/ChangeLog:
* command.h (add_prefix_cmd): Remove the prefixname argument as
it can now be generated automatically. Update all callers.
(add_basic_prefix_cmd): Ditto.
(add_show_prefix_cmd): Ditto.
(add_prefix_cmd_suppress_notification): Ditto.
(add_abbrev_prefix_cmd): Ditto.
* cli/cli-decode.c (add_prefix_cmd): Ditto.
(add_basic_prefix_cmd): Ditto.
(add_show_prefix_cmd): Ditto.
(add_prefix_cmd_suppress_notification): Ditto.
(add_prefix_cmd_suppress_notification): Ditto.
(add_abbrev_prefix_cmd): Ditto.
* cli/cli-decode.h (struct cmd_list_element): Replace the
prefixname member variable with a method which generates the
prefix name at runtime. Update all code reading the prefix
name to use the method, and remove all code setting it.
* python/py-cmd.c (cmdpy_destroyer): Remove code to free the
prefixname member as it's now a method.
(cmdpy_function): Determine if the command is a prefix by
looking at prefixlist, not prefixname.
The current_top_target function is a hidden dependency on the current
inferior. Since I'd like to slowly move towards reducing our dependency
on the global current state, remove this function and make callers use
current_inferior ()->top_target ()
There is no expected change in behavior, but this one step towards
making those callers use the inferior from their context, rather than
refer to the global current inferior.
gdb/ChangeLog:
* target.h (current_top_target): Remove, make callers use the
current inferior instead.
* target.c (current_top_target): Remove.
Change-Id: Iccd457036f84466cdaa3865aa3f9339a24ea001d
Extend the "x" and "print" commands to make use of memory tagging
functionality, if supported by the architecture.
The "print" command will point out any possible tag mismatches it finds
when dealing with pointers, in case such a pointer is tagged. No additional
modifiers are needed.
Suppose we have a pointer "p" with value 0x1234 (logical tag 0x0) and that we
have an allocation tag of 0x1 for that particular area of memory. This is the
expected output:
(gdb) p/x p
Logical tag (0x0) does not match the allocation tag (0x1).
$1 = 0x1234
The "x" command has a new 'm' modifier that will enable displaying of
allocation tags alongside the data dump. It will display one allocation
tag per line.
AArch64 has a tag granule of 16 bytes, which means we can have one tag for
every 16 bytes of memory. In this case, this is what the "x" command will
display with the new 'm' modifier:
(gdb) x/32bxm p
<Allocation Tag 0x1 for range [0x1230,0x1240)>
0x1234: 0x01 0x02 0x00 0x00 0x00 0x00 0x00 0x00
0x123c: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
<Allocation Tag 0x1 for range [0x1240,0x1250)>
0x1244: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x124c: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
(gdb) x/4gxm a
<Allocation Tag 0x1 for range [0x1230,0x1240)>
0x1234: 0x0000000000000201 0x0000000000000000
<Allocation Tag 0x1 for range [0x1240,0x1250)>
0x1244: 0x0000000000000000 0x0000000000000000
gdb/ChangeLog:
2021-03-24 Luis Machado <luis.machado@linaro.org>
* printcmd.c (decode_format): Handle the 'm' modifier.
(do_examine): Display allocation tags when required/supported.
(should_validate_memtags): New function.
(print_command_1): Display memory tag mismatches.
* valprint.c (show_memory_tag_violations): New function.
(value_print_option_defs): Add new option "memory-tag-violations".
(user_print_options) <memory_tag_violations>: Initialize to 1.
* valprint.h (struct format_data) <print_tags>: New field.
(value_print_options) <memory_tag_violations>: New field.
gdb/testsuite/ChangeLog:
2021-03-24 Luis Machado <luis.machado@linaro.org>
* gdb.base/options.exp: Adjust for new print options.
* gdb.base/with.exp: Likewise.
This commits the result of running gdb/copyright.py as per our Start
of New Year procedure...
gdb/ChangeLog
Update copyright year range in copyright header of all GDB files.
