When printing a rust structure that contains a string GDB can
currently fail to read the fields that define the string. This is
because GDB mistakenly treats a value that is the parent structure as
though it is the structure that defines the string, and then fails to
find the fields needed to extract a string.
The solution is to create a new value to represent the string field of
the parent value.
gdb/ChangeLog:
* rust-lang.c (val_print_struct): Handle printing structures
containing strings.
gdb/testsuite/ChangeLog:
* gdb.rust/simple.exp: Add new test case.
* gdb.rust/simple.rs (struct StringAtOffset): New struct.
(main): Initialise an instance of the new struct.
The .code16gcc directive to support 16-bit mode with 32-bit address.
For IRET without a suffix, generate 16-bit IRET with a warning to
return from an interrupt handler in 16-bit mode.
PR gas/24485
* config/tc-i386.c (process_suffix): Issue a warning to IRET
without a suffix for .code16gcc.
* testsuite/gas/i386/jump16.s: Add tests for iretX.
* testsuite/gas/i386/jump16.d: Updated.
* testsuite/gas/i386/jump16.e: New file.
I noticed that _initialize_valarith is empty. This patch removes it.
Because init.c is constructed at build time, there's no reason to keep
empty initialization functions around, because there's no overhead to
reintroducing them when needed.
gdb/ChangeLog
2019-05-02 Tom Tromey <tromey@adacore.com>
* valarith.c (_initialize_valarith): Remove.
This patch enables the new Transactional Memory Extension added recently
as part of Arm's new architecture technologies.
We introduce a new optional extension "tme" to enable this. The following
instructions are part of the extension:
* tstart <Xt>
* ttest <Xt>
* tcommit
* tcancel #<imm>
The ISA for the above can be found here:
https://developer.arm.com/docs/ddi0602/latest/base-instructions-alphabetic-order
*** gas/ChangeLog ***
2019-05-01 Sudakshina Das <sudi.das@arm.com>
* config/tc-aarch64.c (parse_operands): Add case for
AARCH64_OPND_TME_UIMM16.
(aarch64_features): Add "tme".
* doc/c-aarch64.texi: Document the same.
* testsuite/gas/aarch64/tme-invalid.d: New test.
* testsuite/gas/aarch64/tme-invalid.l: New test.
* testsuite/gas/aarch64/tme-invalid.s: New test.
* testsuite/gas/aarch64/tme.d: New test.
* testsuite/gas/aarch64/tme.s: New test.
*** include/ChangeLog ***
2019-05-01 Sudakshina Das <sudi.das@arm.com>
* opcode/aarch64.h (AARCH64_FEATURE_TME): New.
(enum aarch64_opnd): Add AARCH64_OPND_TME_UIMM16.
*** opcodes/ChangeLog ***
2019-05-01 Sudakshina Das <sudi.das@arm.com>
* aarch64-asm-2.c: Regenerated.
* aarch64-dis-2.c: Regenerated.
* aarch64-opc-2.c: Regenerated.
* aarch64-opc.c (operand_general_constraint_met_p): Add case for
AARCH64_OPND_TME_UIMM16.
(aarch64_print_operand): Likewise.
* aarch64-tbl.h (QL_IMM_NIL): New.
(TME): New.
(_TME_INSN): New.
(struct aarch64_opcode): Add tstart, tcommit, ttest and tcancel.
A user at AdaCore found a case where assignment to a nested packed
structure would fail. The bug is that ada_value_primitive_field
doesn't account for the situation where a field is not packed relative
to its containing structure, but where the structure itself is packed
in its parent.
gdb/ChangeLog
2019-05-01 Tom Tromey <tromey@adacore.com>
* ada-lang.c (ada_value_primitive_field): Treat more fields as
bitfields.
gdb/testsuite/ChangeLog
2019-05-01 Tom Tromey <tromey@adacore.com>
* gdb.ada/packed_array_assign/aggregates.ads (Nested_Packed): New
record.
(NPR): New variable.
* gdb.ada/packed_array_assign.exp: Add nested packed assignment
test.
A bug internal to AdaCore notes that assigning a non-scalar value to
an element of a packed array will sometimes fail.
The bug turns out to be that ada_value_assign incorrectly computes the
starting point for the assignment. This patch fixes the problem.
gdb/ChangeLog
2019-05-01 Tom Tromey <tromey@adacore.com>
* ada-lang.c (ada_value_assign): Correctly compute starting offset
for big-endian copies.
gdb/testsuite/ChangeLog
2019-05-01 Tom Tromey <tromey@adacore.com>
* gdb.ada/packed_array_assign.exp: Add packed assignment
regression test.
PR 24507
* nm.c: (print_format): New variable.
(value_format_32bit, value_format_64bit): Delete.
(set_print_radix): Remove code to alter value_format strings.
(set_output_format): Record chosen format in print_format.
(get_print_format): New function - constructs a printf formatting
string according to the requirements of size, radix, and output
format.
(print_value): Use get_print_format.
* testsuite/binutils-all/nm.exp: Add tests of "nm --format=posix"
and "nm -t d".
When running fullpath-expand.exp with target_board=dwarf4-gdb-index, we run
into:
...
$ make check-gdb RUNTESTFLAGS="--target_board=dwarf4-gdb-index fullpath-expand.exp"
Running src/gdb/testsuite/gdb.base/fullpath-expand.exp ...
gdb compile failed, cc-with-tweaks.sh: unable to find usable gdb
=== gdb Summary ===
nr of untested testcases 1
...
The same happens with fullname.exp.
The dwarf4-gdb-index.exp board file includes cc-with-tweaks.exp, which uses
cc-with-tweaks.sh, which calls gdb-add-index.sh.
The gdb-add-index.sh script uses a gdb executable, defaulting to gdb:
...
GDB=${GDB:=gdb}
...
The cc-with-tweaks.sh script tries to ensure that the build gdb executable is
used by gdb-add-index.sh:
...
if [ -z "$GDB" ]
then
if [ -f ./gdb ]
then
GDB="./gdb -data-directory data-directory"
elif [ -f ../gdb ]
then
GDB="../gdb -data-directory ../data-directory"
elif [ -f ../../gdb ]
then
GDB="../../gdb -data-directory ../../data-directory"
else
echo "$myname: unable to find usable gdb" >&2
exit 1
fi
fi
...
So, if the current directory is build/gdb/testsuite, then a gdb executable
build/gdb/testsuite/../gdb will be used.
However, in the case of fullpath-expand.exp the test cd's into the sources:
...
set saved_pwd [pwd]
cd $srcdir
set err [gdb_compile "${subdir}/${srcfile} ${subdir}/${srcfile2}" $binfile \
executable {debug}]
cd $saved_pwd
...
and cc-with-tweaks.sh generates the "unable to find usable gdb" error.
The same error occurs if we use --target_board=cc-with-dwz instead (only in
this case we actually don't need gdb, we just need the GDB variable to be set
in cc-with-tweaks.sh, which arguably is a bug in cc-with-tweaks.sh).
Fix both errors in cc-with-tweaks.exp by generating a gdb script gdb.sh using
$GDB, $GDBFLAGS and $INTERNAL_GDBFLAGS and passing this script to
cc-with-tweaks.sh by setting env(GDB).
Tested on x86_64-linux for gdb.base.
gdb/testsuite/ChangeLog:
2019-05-01 Tom de Vries <tdevries@suse.de>
* boards/cc-with-tweaks.exp: Generate gdb.sh, and pass it in env(GDB).
Board file dwarf4-gdb-index.exp contains all the commands from
cc-with-tweaks.exp (with CC_WITH_TWEAKS_FLAGS set to "-i").
Make dwarf4-gdb-index.exp smaller by including cc-with-tweaks.exp.
Tested on x86_64-linux for gdb.base.
gdb/testsuite/ChangeLog:
2019-05-01 Tom de Vries <tdevries@suse.de>
* boards/dwarf4-gdb-index.exp: Use cc-with-tweaks.exp.
Dwarf5 defines DW_FORM_strx1 and others, which are similar
to DW_FORM_strx but uses 1-4 bytes unsigned integers. This is
a small step towards supporting dwarf5 in gdb.
This global is meant to point to the "main" thread of execution of
the program we are debugging. It is set when attaching to a process
or when receiving a CREATE_PROCESS_DEBUG_EVENT event. The theory at
the time was that this was also going to be the thread receiving
the EXIT_PROCESS_DEBUG_EVENT event.
Unfortunately, we have discovered since then that this is actually
not guaranteed. What this means in practice is that there is moderate
risk that main_thread_id refers to a thread which no longer exists.
This global is used in 3 situations:
- OUTPUT_DEBUG_STRING_EVENT
- LOAD_DLL_DEBUG_EVENT
- UNLOAD_DLL_DEBUG_EVENT
It's not clear why we would need to use the main_thread_id in those cases
instead of using the thread ID provided by the kernel events itself.
So this patch implements this approach, which then allows us to delete
the main_thread_id global.
gdb/testsuite:
* windows-nat.c (main_thread_id): Delete.
(handle_output_debug_string): Replace main_thread_id by
current_event.dwThreadId.
(fake_create_process): Likewise.
(get_windows_debug_event) <CREATE_PROCESS_DEBUG_EVENT>:
Do not set main_thread_id.
<LOAD_DLL_DEBUG_EVENT>: Replace main_thread_id by
current_event.dwThreadId.
<UNLOAD_DLL_DEBUG_EVENT>: Likewise.
We have observed that GDB would randomly trip the following
assertion failure when debugging on Windows. When allowing
the program to run until the inferior exits, we occasionally see:
(gdb) cont
Continuing.
[Thread 48192.0xd100 exited with code 1]
[Thread 48192.0x10ad8 exited with code 1]
[Thread 48192.0x36e28 exited with code 0]
[Thread 48192.0x52be4 exited with code 0]
[Thread 48192.0x5aa40 exited with code 0]
../../src/gdb/thread.c:453: internal-error: void delete_thread_1(thread_inf
o*, bool): Assertion `thr != nullptr' failed.
Running the same scenario with some additional traces enabled...
(gdb) set verbose
(gdb) set debugevents
... allows us to understand what the issue is. To understand, we need
to first look at the events received when starting the program, and
in particular which threads got created how. First, we get a
CREATE_PROCESS_DEBUG_EVENT for tid=0x442a8:
gdb: kernel event for pid=317536 tid=0x442a8 code=CREATE_PROCESS_DEBUG_EVENT)
Shortly after, we get some CREATE_THREAD_DEBUG_EVENT events,
one of them being for tid=0x4010c:
gdb: kernel event for pid=317536 tid=0x4010c code=CREATE_THREAD_DEBUG_EVENT)
Fast forward a bit of debugging, and we do a "cont" as above,
at which point the programs reaches the end, and the system reports
"exit" events. The first interesting one is the following:
gdb: kernel event for pid=317536 tid=0x442a8 code=EXIT_THREAD_DEBUG_EVENT)
This is reporting a thread-exit event for a thread whose tid
is the TID of what we call the "main thread". That's the thread
that was created when we received the CREATE_PROCESS_DEBUG_EVENT
notification, and whose TID is actually stored in a global variable
named main_thread_id. This is not something we expected, as
the assumption we made was that the main thread would exit last,
and we would be notified of it via an EXIT_PROCESS_DEBUG_EVENT.
But apparently, this is not always true, at least on Windows Server
2012 and 2016 where this issue has been observed happening randomly.
The consequence of the above notification is that we call
windows_delete_thread for that thread, which removes it from
our list of known threads.
And a little bit later, then we then get the EXIT_PROCESS_DEBUG_EVENT,
and we can see that the associated tid is not the main_thread_id,
but rather the tid of one of the threads that was created during
the lifetime of the program, in this case tid=0x4010c:
gdb: kernel event for pid=317536 tid=0x4010c code=EXIT_PROCESS_DEBUG_EVENT)
And the debug trace printed right after shows why we're crashing:
[Deleting Thread 317536.0x442a8]
We are trying to delete the thread whose tid=0x442a8, which is
the main_thread_id! As we have already deleted that thread before,
the search for it returns a nullptr, which then trips the assertion
check in delete_thread_1.
This commit fixes this issue. It ignores the open question of
what to do with the main_thread_id global, particularly after
that thread has been removed from our list of threads. This will
be dealt with as a separate patch, to allow cherry-picking
this patch into a release branch.
For now, we fix the code so as to avoid this crash.
gdb/ChangeLog:
* windows-nat.c (get_windows_debug_event) <EXIT_PROCESS_DEBUG_EVENT>:
Use current_event.dwThreadId instead of main_thread_id.
When an Ada program is dynamically linked against libgnat, and when
one of the standard exceptions is used, the exception object may be
referenced by the main executable using a copy relocation.
In this situation, a "catch exception" for those exceptions will not
manage to stop. This happens because, under the hood, "catch
exception" creates an expression object that examines the object
addresses -- but in this case, the address will be incorrect.
This patch fixes the problem by arranging for these filter expressions
to examine all the relevant minimal symbols. This way, the object
from libgnat will be found as well.
Tested on x86-64 Fedora 29.
gdb/ChangeLog
2019-04-30 Tom Tromey <tromey@adacore.com>
* ada-lang.c (ada_lookup_simple_minsyms): New function.
(create_excep_cond_exprs): Iterate over program spaces.
(ada_exception_catchpoint_cond_string): Examine all minimal
symbols for exception types.
gdb/testsuite/ChangeLog
2019-04-30 Tom Tromey <tromey@adacore.com>
* lib/ada.exp (find_ada_tool): New proc.
* lib/gdb.exp (gdb_compile_shlib): Allow .o files as inputs.
* gdb.ada/catch_ex_std.exp: New file.
* gdb.ada/catch_ex_std/foo.adb: New file.
* gdb.ada/catch_ex_std/some_package.adb: New file.
* gdb.ada/catch_ex_std/some_package.ads: New file.
PR c++/24470 concerns a crash in dwarf2read.c that occurs with a
particular test case.
The issue turns out to be that process_structure_scope will pass NULL
to symbol_symtab. This happens because new_symbol decided not to
create a symbol for the particular DIE.
This patch fixes the problem by finding another reasonably-appropriate
symtab to use instead; issuing a complaint if one cannot be found for
some reason.
As mentioned in the bug, I think there are other bugs here. For
example, when using "ptype" on the "l" object in the test case, I
think I would expect to see the template parameter. I didn't research
this too closely, since it seemed more important to fix the crash.
Tested on x86-64 Fedora 29.
I'd like to check this in to the 8.3 branch as well.
2019-04-30 Tom Tromey <tromey@adacore.com>
PR c++/24470:
* dwarf2read.c (process_structure_scope): Handle case where type
has template parameters but no symbol was created.
gdb/testsuite/ChangeLog
2019-04-30 Tom Tromey <tromey@adacore.com>
PR c++/24470:
* gdb.cp/temargs.cc: Add test code from PR.
Fixes the following error:
ld.pod around line 568: Expected '=item *'
POD document had syntax errors at /usr/bin/pod2man line 71.
* ld.texi (How GNU properties are merged): Avoid pod2man error.
Correct example.
Types in Fortran can have the 'allocatable' qualifier attached to
indicate that memory needs to be explicitly allocated by the user.
This patch extends GDB to show this qualifier when printing types.
Lots of tests results are then updated to include this new qualifier
in the expected results.
gdb/ChangeLog:
* f-typeprint.c (f_type_print_base): Print 'allocatable' type
qualifier.
* gdbtypes.h (TYPE_IS_ALLOCATABLE): Define.
gdb/testsuite/ChangeLog:
* gdb.fortran/vla-datatypes.exp: Update expected results.
* gdb.fortran/vla-ptype.exp: Likewise.
* gdb.fortran/vla-type.exp: Likewise.
* gdb.fortran/vla-value.exp: Likewise.
The whitespace produced as types are printed seems inconsistent. This
commit updates the rules in an attempt to make whitespace more
balanced and consistent. Expected results are updated.
gdb/ChangeLog:
* f-typeprint.c (f_print_type): Update rules for printing
whitespace.
(f_type_print_varspec_suffix): Likewise.
gdb/testsuite/ChangeLog:
* gdb.fortran/ptr-indentation.exp: Update expected results.
* gdb.fortran/ptype-on-functions.exp: Likewise.
* gdb.fortran/vla-ptr-info.exp: Likewise.
* gdb.fortran/vla-value.exp: Likewise.
Before this commit using ptype on a Fortran function will include
information about the functions return type, but not the expected
arguments as it would for C or C++. After this commit argument types
are included in the ptype output.
For example, before GDB prints:
(gdb) ptype fun1
type = integer(kind=4) ()
(gdb) ptype is_bigger
type = logical(kind=4) ()
and after GDB prints:
(gdb) ptype fun1
type = integer(kind=4) (integer(kind=4))
(gdb) ptype is_bigger
type = logical(kind=4) (integer(kind=4), integer(kind=4))
gdb/ChangeLog:
* f-typeprint.c (f_type_print_varspec_suffix): Handle printing
function arguments.
gdb/testsuite/ChangeLog:
* gdb.fortran/ptype-on-functions.exp: New file.
* gdb.fortran/ptype-on-functions.f90: New file.
For a program compiled with gfortran the base type names are written
as lower cases in the DWARF, and so GDB will display them as lower
case. Additionally, in most places where GDB supplies its own type
names (for example all of the types defined in f-lang.c in
`build_fortran_types`), the type names are all lower case.
An exception to this is where GDB prints the void type for Fortran.
In this case GDB uses upper case.
I'm not aware of any reason why this type should merit special
attention, and it looks our of place when printing types, so this
commit changes from 'VOID' to 'void' to match all the other types.
gdb/ChangeLog:
* f-lang.c (build_fortran_types): Change name of void type to
lower case.
* f-typeprint.c (f_type_print_base): Print the name of the void
type, rather than a fixed string.
* f-valprint.c (f_decorations): Use lower case void string.
gdb/testsuite/ChangeLog:
* gdb.fortran/exprs.exp (test_convenience_variables): Expect lower
case void string.
Currently when using $_creal and $_cimag to access the components of a
complex number the types of these components will have C type names
'float', 'double', etc. This is because the components of a complex
number are not given type names in DWARF, so GDB has to pick some
suitable names, and currently we always use the C names.
This commit changes the type names used based on the language, so for
Fortran we will now use the Fortran float types, and so will get the
Fortran float type names 'real', 'real*8', etc.
gdb/ChangeLog:
* dwarf2read.c (dwarf2_init_complex_target_type): Use different
types for Fortran.
gdb/testsuite/ChangeLog:
* gdb.fortran/complex.exp: Expand.
* gdb.fortran/complex.f: Renamed to...
* gdb.fortran/complex.f90: ...this, and extended to add more
complex values.
Future commits will add more Fortran specific expression operators.
In preparation for these new operators, this commit adds a new
fortran-operator.def file similar to how GDB already has
ada-operator.def.
I've moved UNOP_KIND the Fortran specific operator I introduced in
commit 4d00f5d8f6 into this file, and renamed it to make it clearer
that the operator is Fortran specific. I've then updated the Fortran
exp_descriptor table (exp_descriptor_f) to use entirely Fortran
specific functions that now handle UNOP_FORTRAN_KIND (the new name for
UNOP_KIND).
There should be no visible changes for standard users after this
commit, though for developers, the output when 'set debug expression
1' is now better, before:
(gdb) p kind (l1)
Dump of expression @ 0x2ccc7a0, before conversion to prefix form:
Language fortran, 5 elements, 16 bytes each.
Index Opcode Hex Value String Value
0 OP_VAR_VALUE 42 *...............
1 OP_NULL 47730176 .N..............
2 BINOP_INTDIV 47729184 J..............
3 OP_VAR_VALUE 42 *...............
4 UNOP_KIND 78 N...............
Dump of expression @ 0x2ccc7a0, after conversion to prefix form:
Expression: `Invalid expression
(gdb)
and after:
(gdb) p kind (l1)
Dump of expression @ 0x294d0b0, before conversion to prefix form:
Language fortran, 5 elements, 16 bytes each.
Index Opcode Hex Value String Value
0 OP_VAR_VALUE 40 (...............
1 unknown opcode: 224 44088544 ................
2 unknown opcode: 208 44087504 ................
3 OP_VAR_VALUE 40 (...............
4 UNOP_FORTRAN_KIND 119 w...............
Dump of expression @ 0x294d0b0, after conversion to prefix form:
Expression: `KIND(test::l1)'
Language fortran, 5 elements, 16 bytes each.
0 UNOP_FORTRAN_KIND
1 OP_VAR_VALUE Block @0x2a0bce0, symbol @0x2a0b8d0 (l1)
$1 = 1
(gdb)
gdb/ChangeLog:
* gdb/expprint.c (dump_subexp_body_standard): Remove use of
UNOP_KIND.
* gdb/expression.h (exp_opcode): Include 'fortran-operator.def'.
* gdb/f-exp.y (exp): Rename UNOP_KIND to UNOP_FORTRAN_KIND.
* gdb/f-lang.c (evaluate_subexp_f): Likewise.
(operator_length_f): New fuction.
(print_subexp_f): New function.
(op_name_f): New function.
(dump_subexp_body_f): New function.
(operator_check_f): New function.
(exp_descriptor_f): Replace standard expression handling functions
with new functions.
* gdb/fortran-operator.def: New file.
* gdb/parse.c (operator_length_standard): Remove use of UNOP_KIND.
* gdb/std-operator.def: Remove UNOP_KIND.
What appears to be a stray double quote character in std-operator.def
causes incorrect highlighting in my editor.
The quote was introduced in this commit:
commit 858be34c5a
Date: Mon Sep 4 20:21:15 2017 +0100
Handle "p S::method()::static_var" in the C++ parser
I can't see any reason why the quote should be there, so this commit
removes it.
gdb/ChangeLog:
* std-operator.def: Remove unbalanced, stray double quote
character.
Introduce a new print setting max-depth which can be set with 'set
print max-depth DEPTH'. The default value of DEPTH is 20, but this
can also be set to unlimited.
When GDB is printing a value containing nested structures GDB will
stop descending at depth DEPTH. Here is a small example:
typedef struct s1 { int a; } s1;
typedef struct s2 { s1 b; } s2;
typedef struct s3 { s2 c; } s3;
typedef struct s4 { s3 d; } s4;
s4 var = { { { { 3 } } } };
The following table shows how various depth settings affect printing
of 'var':
| Depth Setting | Result of 'p var' |
|---------------+--------------------------------|
| Unlimited | $1 = {d = {c = {b = {a = 3}}}} |
| 4 | $1 = {d = {c = {b = {a = 3}}}} |
| 3 | $1 = {d = {c = {b = {...}}}} |
| 2 | $1 = {d = {c = {...}}} |
| 1 | $1 = {d = {...}} |
| 0 | $1 = {...} |
Only structures, unions, and arrays are replaced in this way, scalars
and strings are not replaced.
The replacement is counted from the level at which you print, not from
the top level of the structure. So, consider the above example and
this GDB session:
(gdb) set print max-depth 2
(gdb) p var
$1 = {d = {c = {...}}}
(gdb) p var.d
$2 = {c = {b = {...}}}
(gdb) p var.d.c
$3 = {b = {a = 3}}
Setting the max-depth to 2 doesn't prevent the user from exploring
deeper into 'var' by asking for specific sub-fields to be printed.
The motivation behind this feature is to try and give the user more
control over how much is printed when examining large, complex data
structures.
The default max-depth of 20 means that there is a change in GDB's
default behaviour. Someone printing a data structure with 20 levels
of nesting will now see '{...}' instead of their data, they would need
to adjust the max depth, or call print again naming a specific field
in order to dig deeper into their data structure. If this is
considered a problem then we could increase the default, or even make
the default unlimited.
This commit relies on the previous commit, which added a new field to
the language structure, this new field was a string that contained the
pattern that should be used when a structure/union/array is replaced
in the output, this allows languages to use a syntax that is more
appropriate, mostly this will be selecting the correct types of
bracket '(...)' or '{...}', both of which are currently in use.
This commit should have no impact on MI output, expressions are
printed through the MI using -var-create and then -var-list-children.
As each use of -var-list-children only ever displays a single level of
an expression then the max-depth setting will have no impact.
This commit also adds the max-depth mechanism to the scripting
language pretty printers following basically the same rules as for the
built in value printing.
One quirk is that when printing a value using the display hint 'map',
if the keys of the map are structs then GDB will hide the keys one
depth level after it hides the values, this ensures that GDB produces
output like this:
$1 = map_object = {[{key1}] = {...}, [{key2}] = {...}}
Instead of this less helpful output:
$1 = map_object = {[{...}] = {...}, [{...}] = {...}}
This is covered by the new tests in gdb.python/py-nested-maps.exp.
gdb/ChangeLog:
* cp-valprint.c (cp_print_value_fields): Allow an additional level
of depth when printing anonymous structs or unions.
* guile/scm-pretty-print.c (gdbscm_apply_val_pretty_printer):
Don't print either the top-level value, or the children if the
max-depth is exceeded.
(ppscm_print_children): When printing the key of a map, allow one
extra level of depth.
* python/py-prettyprint.c (gdbpy_apply_val_pretty_printer): Don't
print either the top-level value, or the children if the max-depth
is exceeded.
(print_children): When printing the key of a map, allow one extra
level of depth.
* python/py-value.c (valpy_format_string): Add max_depth keyword.
* valprint.c: (PRINT_MAX_DEPTH_DEFAULT): Define.
(user_print_options): Initialise max_depth field.
(val_print_scalar_or_string_type_p): New function.
(val_print): Check to see if the max depth has been reached.
(val_print_check_max_depth): Define new function.
(show_print_max_depth): New function.
(_initialize_valprint): Add 'print max-depth' option.
* valprint.h (struct value_print_options) <max_depth>: New field.
(val_print_check_max_depth): Declare new function.
* NEWS: Document new feature.
gdb/doc/ChangeLog:
* gdb.texinfo (Print Settings): Document 'print max-depth'.
* guile.texi (Guile Pretty Printing API): Document that 'print
max-depth' can effect the display of a values children.
* python.texi (Pretty Printing API): Likewise.
(Values From Inferior): Document max_depth keyword.
gdb/testsuite/ChangeLog:
* gdb.base/max-depth.c: New file.
* gdb.base/max-depth.exp: New file.
* gdb.python/py-nested-maps.c: New file.
* gdb.python/py-nested-maps.exp: New file.
* gdb.python/py-nested-maps.py: New file.
* gdb.python/py-format-string.exp (test_max_depth): New proc.
(test_all_common): Call test_max_depth.
* gdb.fortran/max-depth.exp: New file.
* gdb.fortran/max-depth.f90: New file.
* gdb.go/max-depth.exp: New file.
* gdb.go/max-depth.go: New file.
* gdb.modula2/max-depth.exp: New file.
* gdb.modula2/max-depth.c: New file.
* lib/gdb.exp (get_print_expr_at_depths): New proc.
This commit is preparation work for the next commit, and by itself
makes no user visible change to GDB. I've split this work into a
separate commit in order to make code review easier.
This commit adds a new field 'la_is_string_type_p' to the language
struct, this predicate will return true if a type is a string type for
the given language.
Some languages already have a "is this a string" predicate that I was
able to reuse, while for other languages I've had to add a new
predicate. In this case I took inspiration from the value printing
code for that language - what different conditions would result in
printing something as a string.
A default "is this a string" method has also been added that looks for
TYPE_CODE_STRING, this is the fallback I've used for a couple of
languages.
In this commit I add the new field and initialise it for each
language, however at this stage the new field is never used.
gdb/ChangeLog:
* ada-lang.c (ada_language_defn): Initialise new field.
* c-lang.c (c_is_string_type_p): New function.
(c_language_defn): Initialise new field.
(cplus_language_defn): Initialise new field.
(asm_language_defn): Initialise new field.
(minimal_language_defn): Initialise new field.
* c-lang.h (c_is_string_type_p): Declare new function.
* d-lang.c (d_language_defn): Initialise new field.
* f-lang.c (f_is_string_type_p): New function.
(f_language_defn): Initialise new field.
* go-lang.c (go_is_string_type_p): New function.
(go_language_defn): Initialise new field.
* language.c (default_is_string_type_p): New function.
(unknown_language_defn): Initialise new field.
(auto_language_defn): Initialise new field.
* language.h (struct language_defn) <la_is_string_type_p>: New
member variable.
(default_is_string_type_p): Declare new function.
* m2-lang.c (m2_language_defn): Initialise new field.
* objc-lang.c (objc_language_defn): Initialise new field.
* opencl-lang.c (opencl_language_defn): Initialise new field.
* p-lang.c (pascal_is_string_type_p): New function.
(pascal_language_defn): Initialise new field.
* rust-lang.c (rust_is_string_type_p): New function.
(rust_language_defn): Initialise new field.
This commit is preparation work for a later commit, and by itself
makes no user visible change to GDB. I've split this work into a
separate commit in order to make code review easier.
This commit adds a new field 'la_struct_too_deep_ellipsis' to the
language struct, this string will be used in the next commit to print
a language specific string from within the generic value printing
code.
In this commit I add the new field and initialise it for each
language, however at this stage the new field is never used.
gdb/ChangeLog:
* language.h (struct language_defn) <la_struct_too_deep_ellipsis>:
New field.
* ada-lang.c (ada_language_defn): Initialise new field.
* c-lang.c (c_language_defn): Likewise.
(cplus_language_defn): Likewise.
(asm_language_defn): Likewise.
(minimal_language_defn): Likewise.
* d-lang.c (d_language_defn): Likewise.
* f-lang.c (f_language_defn): Likewise.
* go-lang.c (go_language_defn): Likewise.
* language.c (unknown_language_defn): Likewise.
(auto_language_defn): Likewise.
* m2-lang.c (m2_language_defn): Likewise.
* objc-lang.c (objc_language_defn): Likewise.
* opencl-lang.c (opencl_language_defn): Likewise.
* p-lang.c (pascal_language_defn): Likewise.
* rust-lang.c (rust_language_defn): Likewise.
A later commit would like to make use of a pointer to the function
ada_is_string_type, however, this will require the function to return
a bool (so the signature matches).
As the ada_is_string_type is a predicate function, and its return
value is only ever used as either true or false, then this commit
updates the function to return a bool.
As a consequence ada_is_character_type needs to change too.
There should be no user visible changes after this commit.
gdb/ChangeLog:
* ada-lang.c (ada_is_character_type): Change return type to bool.
(ada_is_string_type): Likewise.
* ada-lang.h (ada_is_character_type): Update declaration
(ada_is_string_type): Likewise.
When running gdb-caching-proc.exp, if skip_opencl_tests fails like this:
...
(gdb) run
Starting program: \
build/gdb/testsuite/outputs/gdb.base/gdb-caching-proc/opencltest13530.x
CHK_ERR (clGetPlatformIDs (1, &platform, NULL), -1001)
src/gdb/testsuite/lib/opencl_hostapp.c:73 error: Unknown
[Inferior 1 (process 13600) exited with code 01]
(gdb)
skip_opencl_tests: OpenCL support not detected
...
then this regexp in skip_opencl_tests fails to match:
...
-re ".*$inferior_exited_re code.*${gdb_prompt} $" {
...
so instead we hit the default clause after a 30 seconds timeout. With the
iteration count set at 10, we end up taking 6 minutes to run this test-case.
Fix this by adding the missing "with" in the regexp, bring back the runtime to
half a minute.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-04-29 Tom de Vries <tdevries@suse.de>
* lib/opencl.exp (skip_opencl_tests): Add missing "with" in regexp.
'thread|frame apply CMD' launches CMD so that CMD output goes to a string_file.
This patch ensures that string_file for such CMD output contains
style escape sequences that 'thread|frame apply' will later on
output on the real terminal, so as to have CMD output properly styled.
The idea is to have the class ui_file having overridable methods
to indicate that the output to this ui_file should be done using
'terminal' behaviour such as styling.
Then these methods are overriden in string_file so that a specially
constructed string_file will get output with style escape sequences.
After this patch, the output of CMD by thread|frame apply CMD is styled
similarly as when CMD is launched directly.
Note that string_file (term_out true) could also support wrapping,
but this is not done (yet?).
Tested on debian/amd64.
gdb/ChangeLog
2019-04-27 Philippe Waroquiers <philippe.waroquiers@skynet.be>
Support style in 'frame|thread apply'
* gdbcmd.h (execute_command_to_string): New term_out parameter.
* record.c (record_start, record_stop): Update callers of
execute_command_to_string with false.
* ui-file.h (class ui_file): New term_out and can_emit_style_escape
methods.
(class string_file): New constructor with term_out parameter.
Override methods term_out and can_emit_style_escape. New member
term_out.
(class stdio_file): Override can_emit_style_escape.
(class tee_file): Override term_out and can_emit_style_escape.
* utils.h (can_emit_style_escape): Remove.
* utils.c (can_emit_style_escape): Likewise.
Update all callers of can_emit_style_escape (SOMESTREAM) to
SOMESTREAM->can_emit_style_escape.
* source-cache.c (source_cache::get_source_lines): Likewise.
* stack.c (frame_apply_command_count): Call execute_command_to_string
passing the term_out characteristic of the current gdb_stdout.
* thread.c (thr_try_catch_cmd): Likewise.
* top.c (execute_command_to_string): pass term_out parameter
to construct the string_file for the command output.
* ui-file.c (term_cli_styling): New function (most code moved
from utils.c can_emit_style_escape).
(string_file::string_file, string_file::can_emit_style_escape,
stdio_file::can_emit_style_escape, tee_file::term_out,
tee_file::can_emit_style_escape): New functions.
Inferior function calls are powerful but might lead to undesired
results such as crashes when calling nested functions (frequently
used in particular in Ada).
This implements a GDB setting to disable calling inferior functions.
Note: the idea is that if/when the 'slash command' patch is pushed,
that this setting can be changed e.g. by using the shortcut /c.
This is version 2 of the patch. It handles all the received comments,
mostly replace 'can-call' by 'may-call', and avoid using
'inferior function call' in factor of 'calling function in the program'.
2019-04-26 Philippe Waroquiers <philippe.waroquiers@skynet.be>
gdb/ChangeLog
* NEWS: Mention the new set|show may-call-functions.
* infcall.c (may_call_functions_p): New variable.
(show_may_call_functions_p): New function.
(call_function_by_hand_dummy): Throws an error if not
may-call-functions.
(_initialize_infcall): Call add_setshow_boolean_cmd for
may-call-functions.
gdb/testsuite/ChangeLog
* gdb.base/callexit.exp: Test may-call-functions off.
gdb/doc/ChangeLog
* gdb.texinfo (Calling): Document the new
set|show may-call-functions.
Add several baseline MIPS32R6[1] and MIPS64R6[2] instructions
that were omitted from the initial spec. These instructions
are optional in implementations but not associated with any
ASE or pseudo-ASE. Their presence is indicated by the XNP bit
in the Config5 register.
[1] "MIPS Architecture for Programmers Volume II-A: The MIPS32
Instruction Set Manual", Imagination Technologies Ltd., Document
Number: MD00086, Revision 6.06, December 15, 2016, Section 3.2
"Alphabetical List of Instructions", pp. 228-229, pp. 354-357.
[2] "MIPS Architecture for Programmers Volume II-A: The MIPS64
Instruction Set Manual", Imagination Technologies Ltd., Document
Number: MD00087, Revision 6.06, December 15, 2016, Section 3.2
"Alphabetical List of Instructions", pp. 289-290 and pp. 458-460.
gas/
* config/tc-mips.c (macro) <M_LLWP_AB, M_LLDP_AB, M_SCWP_AB,
M_SCDP_AB>: New cases and expansions for paired instructions.
* testsuite/gas/mips/llpscp-32.s: New test source.
* testsuite/gas/mips/llpscp-64.s: Likewise.
* testsuite/gas/mips/llpscp-32.d: New test.
* testsuite/gas/mips/llpscp-64.d: Likewise.
* testsuite/gas/mips/mips.exp: Run the new tests.
* testsuite/gas/mips/r6.s: Add new instructions to test source.
* testsuite/gas/mips/r6-64.s: Likewise.
* testsuite/gas/mips/r6-64-n32.d: Check new instructions.
* testsuite/gas/mips/r6-64-n64.d: Likewise.
* testsuite/gas/mips/r6-n32.d: Likewise.
* testsuite/gas/mips/r6-n64.d: Likwwise.
* testsuite/gas/mips/r6.d: Likewise.
include/
* opcode/mips.h (M_LLWP_AB, M_LLDP_AB): New enum values.
(M_SCWP_AB, M_SCDP_AB): Likewise.
opcodes/
* mips-opc.c (mips_builtin_opcodes): Add llwp, lldp, scwp, scdp.
The .code16gcc directive supports 16bit mode with 32-bit address. Since
IRET (opcode 0xcf) in 16bit mode returns from an interrupt in 16bit mode,
we shouldn't add 0x66 prefix for IRET.
PR gas/24485
* config/tc-i386.c (process_suffix): Don't add DATA_PREFIX_OPCODE
to IRET for .code16gcc.
* testsuite/gas/i386/jump16.s: Add IRET tests.
* testsuite/gas/i386/jump16.d: Updated.
When undefined non-weak references in IR objects are optimized out
by LTO, we can have weak dynamic referencs to symbols marked with
bfd_link_hash_undefined. We shouldn't complain such undefined weak
dynamic references.
bfd/
PR ld/24486
* elflink.c (elf_link_output_extsym): Don't complain undefined
weak dynamic reference.
ld/
PR ld/24486
* testsuite/ld-plugin/lto.exp: Run PR ld/24486 tests.
* testsuite/ld-plugin/pr24486a.c: New file.
* testsuite/ld-plugin/pr24486b.c: Likewise.
* testsuite/ld-plugin/pr24486c.c: Likewise.
This bug finds another usage where we end up segfaulting while
normalizing user input. inspect_type and replace_type recurse,
attempting to substitute the "real" symbol name for the typedef name.
However, since the both these names are the same, they keep calling
each other until the stack overflows.
A simple reproducer for it is given by
typedef struct foo foo;
int qux (foo *f) { return 0; }
(gdb) b qux(foo*)
Segmentation fault
inspect_type already contains some special handling to prevent a
similar situation from occurring with namespaces. I wonder, however,
whether we need be so pedantic about the exact nature of the substitution.
This patch implements this rather more aggressive assumption that these
substitutions should be avoided whenever the replacement symbol's name is
exactly the same as the one we're trying to substitute. [In the above
example, we're trying to substitute the tyepdef named "foo" with the symbol
named "foo" (a struct).]
gdb/ChangeLog:
PR c++/24367
* cp-support.c (inspect_type): Don't attempt substitutions
of symbol with the same name.
gdb/testsuite/ChangeLog:
PR c++/24367
* gdb.cp/meth-typedefs.cc (incomplete_struct)
(another_incomplete_struct, test_incomplete): New definitions.
(main): Use new definitions.
* gdb.cp/meth-typedefs.exp: Add new tests for `test_incomplete'
functions.
