Currently, in order to rewrite:
...
gdb_test <command> <pattern> <message>
...
using gdb_test_multiple, we get:
...
gdb_test_multiple <command> <message> {
-re "\[\r\n\]*(?:<pattern>)\[\r\n\]+$gdb_prompt $" {
pass $gdb_test_name
}
}
...
Add a '-wrap pattern flag to gdb_test_multiple, that wraps the regexp
pattern as gdb_test wraps its message argument.
This allows us to rewrite into the more compact:
...
gdb_test_multiple <command> <message> {
-re -wrap <pattern> {
pass $gdb_test_name
}
}
...
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-10-24 Tom de Vries <tdevries@suse.de>
* lib/gdb.exp (gdb_test_multiple): Add -wrap pattern flag.
* gdb.reverse/step-precsave.exp: Rewrite gdb_test_multiple containing
kfail using -wrap pattern flag and convenience variable
gdb_test_name.
Change-Id: Ie42c97d5ab7acf6db351299ccd23a83540fe6e1a
The documentation for Progspace.block_for_pc says:
Return the innermost gdb.Block containing the given pc value. If the
block cannot be found for the pc value specified, the function will
return None.
However, the implementation actually throws an error for invalid
addresses, like this:
(gdb) python print gdb.current_progspace ().block_for_pc (1)
Traceback (most recent call last):
File "<string>", line 1, in <module>
RuntimeError: Cannot locate object file for block.
Error while executing Python code.
(gdb)
This has been the behaviour since the command was first added (when
the documentation was still as above) in this commit:
commit f3e9a8177c
Date: Wed Feb 24 21:18:28 2010 +0000
Since that commit the code in question has moved around, but the
important parts are largely unchanged. The function in question is
now in py-progspace.c:pspy_block_for_pc.
Examining the code shows that the real state is more complex than just
the function throws an error instead of returning None, instead the
real situation is:
1. If we can't find a compilation unit for the $pc value then we
throw an error, but
2. If we can find a compilation unit, but can't find a block within
the compilation unit for the $pc then return None.
I suspect for most users of the Python API this distinction is
irrelevant, and I propose that we standardise on one single failure
mechanism.
Given the function can currently return None in some cases, and is
documented to return None on error, I propose we make that the case
for all error paths, which is what this patch does.
As the Progspace.block_for_pc method is currently untested, I've added
some basic tests including for a call with an invalid $pc.
This is potentially an API breaking change, though an undocumented
part of the API. Also, users should have been checking and handling a
None return value anyway, so my hope is that this shouldn't be too
disruptive.
gdb/ChangeLog:
* python/py-progspace.c (pspy_block_for_pc): Return None for all
error paths.
gdb/testsuite/ChangeLog:
* gdb.python/py-progspace.exp: Add tests for the
Progspace.block_for_pc method.
Change-Id: I9cea8d2132902bcad0013d1fd39080dd5423cc57
Pedro pointed out that sinclude does not error if a file is missing.
This patch changes gdb to only use m4_include, which seems more
correct.
gdb/ChangeLog
2019-10-23 Tom Tromey <tom@tromey.com>
* configure: Rebuild.
* acinclude.m4: Use m4_include, not sinclude.
gdb/gdbserver/ChangeLog
2019-10-23 Tom Tromey <tom@tromey.com>
* configure: Rebuild.
* acinclude.m4: Use m4_include, not sinclude.
gdb/testsuite/ChangeLog
2019-10-23 Tom Tromey <tom@tromey.com>
* configure: Rebuild.
* aclocal.m4: Use m4_include, not sinclude.
Change-Id: I970362e0af7875f9f72796401126acf0ff6dba11
As mentioned in commit 745ff14e6e "[gdb/tdep] Fix 'Unexpected register class'
assert in amd64_push_arguments", of the 12 KFAILs added there, 3 are KPASSing
with g++ 4.8.5.
The KPASSes are due to:
- gdb incorrectly expecting the second half of the result of function
rtn_str_struct_02_01 in register %rdx.
- rtn_str_struct_02_01 using %rdx as a temporary, thereby accidentally setting
it to the expected value.
Reduce the chance of hiding errors due accidental register settings by
compiling the test-case with -O2.
This fixes the KPASSes when applied on top of commit 745ff14e6e.
Tested on x86_64-linux.
Tested with g++ 4.8.5, 7.4.1, 8.3.1, 9.2.1.
gdb/testsuite/ChangeLog:
2019-10-21 Tom de Vries <tdevries@suse.de>
* gdb.base/infcall-nested-structs.c: Add
__attribute__((noinline,noclone)) to all functions.
(call_all): Add missing variable initialization. Simplify return value.
(breakpt): Increment volatile variable, to prevent call from being
optimized out.
* gdb.base/infcall-nested-structs.exp: Compile with -O2.
Change-Id: Ic027e1c957fecd6686345639db99f5eaee3cdf05
On openSUSE Leap 15.1, I get:
...
FAIL: gdb.fortran/module.exp: info variables -n
...
because the info variables command prints info also for init.c:
...
File init.c:^M
24: const int _IO_stdin_used;^M
...
while the regexps in the test-case only expect info for module.f90.
Fix this by extending the regexps.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-10-17 Tom de Vries <tdevries@suse.de>
* gdb.fortran/module.exp: Allow info variables to print info for files
other than module.f90.
Change-Id: I401d8018b121fc7343f6bc8b671900349462457f
Recent work from Tom Tromey to better handle variables with associated
copy relocations has fixed a Fortran issue where module variables
wouldn't show up in the output of 'info variables'.
This commit adds a test for this functionality to ensure it doesn't
get broken in the future.
gdb/testsuite/ChangeLog:
* gdb.fortran/module.exp: Extend with 'info variables' test.
Change-Id: I7306b1d0a9a72947fd48ad7a03f49df774d6573b
The board file cc-with-tweaks is used as the core for lots of other
board files, for example cc-with-gdb-index and cc-with-debug-names.
This commit extends cc-with-tweaks so that it will wrap the Fortran
compiler, allowing for more test coverage.
I tested all of the board files that make use of cc-with-tweaks
running the gdb.fortran/*.exp test set, and in some cases I did see
extra failures. The "standard" results are:
=== gdb Summary ===
# of expected passes 953
# of known failures 2
With board file 'cc-with-dwz-m':
=== gdb Summary ===
# of expected passes 903
# of unexpected failures 1
# of known failures 2
# of untested testcases 4
With board file 'dwarf4-gdb-index':
=== gdb Summary ===
# of expected passes 950
# of unexpected failures 3
# of known failures 2
With board file 'fission-dwp':
=== gdb Summary ===
# of expected passes 949
# of unexpected failures 4
# of known failures 2
Despite these extra failure I don't think this should prevent this
change going in as these failures presumably already exist in GDB.
gdb/testsuite/ChangeLog:
* boards/cc-with-tweaks.exp: Setup F90_FOR_TARGET and
F77_FOR_TARGET.
Change-Id: I06d412f94d0e119ad652dd6c20829f6705a54622
We currently have 12 KFAILS in gdb.base/infcall-nested-structs.exp for
PR tdep/25096.
A minimal version of the failure looks like this. Consider test.c:
...
struct s { int c; struct { int a; float b; } s1; };
struct s ref = { 0, { 'a', 'b' } };
int __attribute__((noinline,noclone)) check (struct s arg)
{ return arg.s1.a == 'a' && arg.s1.b == 'b' && arg.c == 0; }
int main (void)
{ return check (ref); }
...
When calling 'check (ref)' from main, we have '1' as expected:
...
$ g++ test.c -g ; ./a.out ; echo $?
1
...
But when calling 'check (ref)' from the gdb prompt, we get '0':
...
$ gdb a.out -batch -ex start -ex "p check (ref)"
Temporary breakpoint 1 at 0x400518: file test.c, line 8.
Temporary breakpoint 1, main () at test.c:8
8 { return check (ref); }
$1 = 0
...
The layout of struct s is this:
- the field c occupies 4 bytes at offset 0,
- the s1.a field occupies 4 bytes at offset 4, and
- the s1.b field occupies 4 bytes at offset 8.
When compiling at -O2, we can see from the disassembly of main:
...
4003f0: 48 8b 3d 31 0c 20 00 mov 0x200c31(%rip),%rdi \
# 601028 <ref>
4003f7: f3 0f 10 05 31 0c 20 movss 0x200c31(%rip),%xmm0 \
# 601030 <ref+0x8>
4003fe: 00
4003ff: e9 ec 00 00 00 jmpq 4004f0 <_Z5check1s>
...
that check is called with fields c and s1.a passed in %rdi, and s1.b passed
in %xmm0.
However, the classification in theclass (a variable representing the first and
second eightbytes, to put it in SYSV X86_64 psABI terms) in
amd64_push_arguments is incorrect:
...
(gdb) p theclass
$1 = {AMD64_INTEGER, AMD64_INTEGER}
...
and therefore the struct is passed using %rdi and %rsi instead of using %rdi
and %xmm0, which explains the failure.
The reason that we're misclassifying the argument in amd64_classify_aggregate
has to do with how nested struct are handled.
Rather than using fields c and s1.a for the first eightbyte, and using field
s1.b for the second eightbyte, instead field c is used for the first
eightbyte, and fields s1.a and s1.b are classified together in an intermediate
eightbyte, which is then used to merge with both the first and second
eightbyte.
Fix this by factoring out a new function amd64_classify_aggregate_field, and
letting it recursively handle fields of nested structs.
Tested on x86_64-linux.
Tested with g++ 4.8.5, 7.4.1, 8.3.1, 9.2.1.
Tested with clang++ 5.0.2 (which requires removing additional_flags=-Wno-psabi
and adding additional_flags=-Wno-deprecated).
gdb/ChangeLog:
2019-10-16 Tom de Vries <tdevries@suse.de>
PR tdep/25096
* amd64-tdep.c (amd64_classify_aggregate_field): Factor out of ...
(amd64_classify_aggregate): ... here.
(amd64_classify_aggregate_field): Handled fiels of nested structs
recursively.
gdb/testsuite/ChangeLog:
2019-10-16 Tom de Vries <tdevries@suse.de>
PR tdep/25096
* gdb.base/infcall-nested-structs.exp: Remove PR25096 KFAILs.
Change-Id: Id55c74755f0a431ce31223acc86865718ae0c123
Atm, when executing gdb.base/infcall-nested-structs.exp on x86_64-linux, we get:
...
FAIL: gdb.base/infcall-nested-structs.exp: l=c++: types-tc-tf: \
p/d check_arg_struct_02_01 (ref_val_struct_02_01)
FAIL: gdb.base/infcall-nested-structs.exp: l=c++: types-ts-tf: \
p/d check_arg_struct_02_01 (ref_val_struct_02_01)
FAIL: gdb.base/infcall-nested-structs.exp: l=c++: types-ti-tf: \
p/d check_arg_struct_02_01 (ref_val_struct_02_01)
=== gdb Summary ===
nr of expected passes 9255
nr of unexpected failures 3
nr of expected failures 142
...
The 3 FAILs are reported as PR tdep/25096.
The 142 XFAILs are for a gdb assertion failure, reported in PR tdep/24104,
which should have been KFAILs since there's a problem in gdb rather than in
the environment.
A minimal version of the assertion failure looks like this. Consider test.c:
...
struct s { struct { } es1; long f; };
struct s ref = { {}, 'f' };
int __attribute__((noinline,noclone)) check (struct s arg)
{ return arg.f == 'f'; }
int main (void)
{ return check (ref); }
...
When calling 'check (ref)' from main, we have '1' as expected:
...
$ g++ test3.c -g && ( ./a.out; echo $? )
1
...
But when calling 'check (ref)' from the gdb prompt, we get:
...
$ gdb a.out -batch -ex start -ex "p check (ref)"
Temporary breakpoint 1 at 0x4004f7: file test.c, line 8.
Temporary breakpoint 1, main () at test.c:8
8 { return check (ref); }
src/gdb/amd64-tdep.c:982: internal-error: \
CORE_ADDR amd64_push_arguments(regcache*, int, value**, CORE_ADDR, \
function_call_return_method): \
Assertion `!"Unexpected register class."' failed.
...
The assert happens in this loop in amd64_push_arguments:
...
for (j = 0; len > 0; j++, len -= 8)
{
int regnum = -1;
int offset = 0;
switch (theclass[j])
{
case AMD64_INTEGER:
regnum = integer_regnum[integer_reg++];
break;
case AMD64_SSE:
regnum = sse_regnum[sse_reg++];
break;
case AMD64_SSEUP:
gdb_assert (sse_reg > 0);
regnum = sse_regnum[sse_reg - 1];
offset = 8;
break;
default:
gdb_assert (!"Unexpected register class.");
}
...
}
...
when processing theclass[0], which is AMD64_NO_CLASS:
...
(gdb) p theclass
$1 = {AMD64_NO_CLASS, AMD64_INTEGER}
...
The layout of struct s is that the empty field es1 occupies one byte (due to
c++) at offset 0, and the long field f occupies 8 bytes at offset 8.
When compiling at -O2, we can see from the disassembly of main:
...
4003f0: 48 8b 3d 41 0c 20 00 mov 0x200c41(%rip),%rdi \
# 601038 <ref+0x8>
4003f7: e9 e4 00 00 00 jmpq 4004e0 <_Z5check1s>
4003fc: 0f 1f 40 00 nopl 0x0(%rax)
...
that check is called with field f passed in %rdi, meaning that the
classification in theclass is correct, it's just not supported in the loop in
amd64_push_arguments mentioned above.
Fix the assert by implementing support for 'AMD64_NO_CLASS' in that loop.
This exposes 9 more FAILs of the PR tdep/25096 type, so mark all 12 of them as
KFAIL.
Tested on x86_64-linux.
Tested with g++ 4.8.5, 7.4.1, 8.3.1, 9.2.1. With 4.8.5, 3 of the 12 KFAILs
are KPASSing.
Tested with clang++ 5.0.2 (which requires removing additional_flags=-Wno-psabi
and adding additional_flags=-Wno-deprecated).
gdb/ChangeLog:
2019-10-16 Tom de Vries <tdevries@suse.de>
PR tdep/24104
* amd64-tdep.c (amd64_push_arguments): Handle AMD64_NO_CLASS in loop
that handles 'theclass'.
gdb/testsuite/ChangeLog:
2019-10-16 Tom de Vries <tdevries@suse.de>
PR tdep/24104
* gdb.base/infcall-nested-structs.exp: Remove XFAIL for PR tdep/24104.
Add KFAIL for PR tdep/25096.
Change-Id: I8b66345bbf5c00209ca75b1209fd4d60b36e9ede
With g++-4.8, I see:
...
(gdb) PASS: gdb.cp/local-static.exp: c++: print free_inline_func(void)
print 'S::method()'::S_M_s_var_int^M
No symbol "S_M_s_var_int" in specified context.^M
(gdb) FAIL: gdb.cp/local-static.exp: c++: print 'S::method()'::S_M_s_var_int
...
The variable is declared like this (showing pruned .ii):
...
void S::method ()
{
static int S_M_s_var_int = 4;
}
...
But the DWARF generated for the variable is encapsulated in an unnamed lexical
block:
...
<1><121>: Abbrev Number: 5 (DW_TAG_structure_type)
<122> DW_AT_name : S
...
<2><14f>: Abbrev Number: 6 (DW_TAG_subprogram)
...
<150> DW_AT_name : (indirect string, offset: 0x599): method
<156> DW_AT_linkage_name: (indirect string, offset: 0x517): \
_ZN1S6methodEv /* demangled: dS::method() */
...
<1><3f8>: Abbrev Number: 21 (DW_TAG_subprogram)
<3f9> DW_AT_specification: <0x14f>
...
<3fe> DW_AT_low_pc : 0x4004fc
<406> DW_AT_high_pc : 0x2c /* 0x400528 */
...
<2><418>: Abbrev Number: 17 (DW_TAG_formal_parameter)
<419> DW_AT_name : (indirect string, offset: 0x68a): this
...
<2><424>: Abbrev Number: 18 (DW_TAG_lexical_block)
<425> DW_AT_low_pc : 0x400508
<42d> DW_AT_high_pc : 0x1e /* 0x400526 */
<3><435>: Abbrev Number: 22 (DW_TAG_variable)
<436> DW_AT_name : (indirect string, offset: 0x29d): S_M_s_var_int
...
which has the effect that the variable is not addressable unless the program
counter is in the range of the lexical block.
This is caused by gcc PR debug/55541, which was fixed in gcc 5.
Mark in total 225 FAILs as XFAIL.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-10-16 Tom de Vries <tdevries@suse.de>
PR testsuite/25059
* gdb.cp/local-static.exp (do_test): Add xfails for gcc PR debug/55541.
Change-Id: Ibe86707eecffc79f1bb474d7928ea7d0c39a00a2
On openSUSE Leap 15.1 (as well as on Fedora-x86_64-m64 buildbot) I see:
...
FAIL: gdb.base/jit-reader.exp: with jit-reader: after mangling: current frame: info registers
...
The problem is that r10 is printed signed:
...
r10 0xffffffffffffffb0 -80^M
...
but the regexp expects a signed value:
...
"r10 $hex +$decimal" \
...
Fix this by allowing signed values.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-10-16 Tom de Vries <tdevries@suse.de>
* gdb.base/jit-reader.exp: Allow non-pointer registers to be printed
as signed.
Change-Id: Ie494d24fad7a9af7ac6bfaf731c4aa04f1333830
On openSUSE Leap 15.1, we have:
...
FAIL: gdb.ada/mi_task_arg.exp: -stack-list-arguments 1 (unexpected output)
...
The problem is that the stack-list-arguments command prints a frame argument
'self_id' for function system.tasking.stages.task_wrapper:
...
frame={level="2",args=[{name="self_id",value="0x12345678"}]
...
where none (args=[]) is expected.
The frame argument is in fact correct. The FAIL does not show for say, fedora
30, because there the executable uses the system.tasking.stages.task_wrapper
from /lib64/libgnarl-9.so. Adding "additional_flags=-bargs
additional_flags=-shared additional_flags=-largs" to the flags argument of
gdb_compile_ada gives us the same PASS, but installing libada7-debuginfo gets
us the same FAIL again.
Fix the FAIL by allowing the 'self_id' argument.
Tested on x86_64-linux.
Change-Id: I5aee5856fa6aeb0cc78aa4fe69deecba5b00b77a
Commit 580f1034 ("Increase timeout in
gdb.mi/list-thread-groups-available.exp") changed
gdb.mi/list-thread-groups-available.exp to significantly increase the
timeout, which was necessary for when running with make check-read1.
Pedro suggested a better alternative, which is to use gdb_test_multiple
and consume one entry at a time. This patch does that.
gdb/testsuite/ChangeLog:
* gdb.mi/list-thread-groups-available.exp: Read entries one by
one instead of increasing timeout.
Change-Id: I51b689458503240f24e401f054e6583d9172ebdf
Normally the gdb.reverse/*.exp test-cases pass on my system (apart from the
record/23188 KFAIL for gdb.reverse/step-precsave.exp). But when specifying
GLIBC_TUNABLES=glibc.tune.hwcaps=-XSAVEC_Usable to force glibc to use
_dl_runtime_resolve_xsave instead of _dl_runtime_resolve_xsavec, we run into
1054 FAILs like this:
...
(gdb) PASS: gdb.reverse/sigall-reverse.exp: b gen_HUP
continue^M
Continuing.^M
Process record does not support instruction 0xfae64 at address \
0x7ffff7ded958.^M
Process record: failed to record execution log.^M
^M
Program stopped.^M
0x00007ffff7ded958 in _dl_runtime_resolve_xsave () from \
/lib64/ld-linux-x86-64.so.2^M
(gdb) FAIL: gdb.reverse/sigall-reverse.exp: get signal ABRT
...
The problem is that the xsave instruction is not supported in
reverse-debugging (PR record/25038).
Add KFAILs for this PR.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-10-13 Tom de Vries <tdevries@suse.de>
PR record/25038
* gdb.reverse/sigall-precsave.exp: Add PR record/25038 KFAIL.
* gdb.reverse/sigall-reverse.exp: Same.
* gdb.reverse/solib-precsave.exp: Same.
* gdb.reverse/solib-reverse.exp: Same.
* gdb.reverse/step-precsave.exp: Same.
* gdb.reverse/until-precsave.exp: Same.
* gdb.reverse/until-reverse.exp: Same.
* lib/gdb.exp (gdb_continue_to_breakpoint): Same.
Some of the comparison functions in infcall-nested-structs.c contain
redundant comparisons like a.<some_field> == a.<some_field> instead of
a.<some_field> == b.<some_field>. They were introduced with this commit:
36eb4c5f9b - "infcall-nested-structs: Test up to five fields"
Fix the redundant comparisons.
gdb/testsuite/ChangeLog:
* gdb.base/infcall-nested-structs.c (cmp_struct_02_01)
(cmp_struct_02_02, cmp_struct_04_01, cmp_struct_04_02)
(cmp_struct_05_01, cmp_struct_static_02_01)
(cmp_struct_static_04_01, cmp_struct_static_06_01): Fix redundant
comparisons.
When running the gdb testsuite with target board unix/-fPIE/-pie, the
resulting ada executables are not PIE executables, because gnatmake doesn't
recognize -pie, and consequently doesn't pass it to gnatlink.
Fix this by replacing "-pie" with "-largs -pie -margs" in
target_compile_ada_from_dir, and doing the same for -no-pie.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-10-10 Tom de Vries <tdevries@suse.de>
PR testsuite/24888
* lib/ada.exp (target_compile_ada_from_dir): Route -pie/-no-pie to
gnatlink.
On openSUSE Leap 15.1 using rustc version 1.36.0 (using llvm 7), I get:
...
(gdb) PASS: gdb.rust/simple.exp: print e2.0
print k^M
$54 = simple::SpaceSaver::Thebox(40, 0x0)^M
(gdb) FAIL: gdb.rust/simple.exp: print k
...
while we're expecting:
...
gdb_test "print k" " = simple::SpaceSaver::Nothing"
...
When using a relatively recent version of Rust with a somewhat older version
of LLVM, the Rust compiler will emit a legacy encoding of enums (see also
quirk_rust_enum in dwarf2read.c).
So, the variable k:
...
<17><3d58>: Abbrev Number: 15 (DW_TAG_variable)
<3d59> DW_AT_location : 3 byte block: 91 b8 4 (DW_OP_fbreg: 568)
<3d5d> DW_AT_name : (indirect string, offset: 0xf9a): k
<3d61> DW_AT_alignment : 1
<3d62> DW_AT_decl_file : 1
<3d63> DW_AT_decl_line : 129
<3d64> DW_AT_type : <0x4232>
...
has type:
...
<2><4232>: Abbrev Number: 11 (DW_TAG_union_type)
<4233> DW_AT_name : (indirect string, offset: 0x3037): SpaceSaver
<4237> DW_AT_byte_size : 16
<4238> DW_AT_alignment : 8
<3><4239>: Abbrev Number: 9 (DW_TAG_member)
<423a> DW_AT_name : (indirect string, offset: 0x29f5): RUST$ENCODED$ENUM$0$Nothing
<423e> DW_AT_type : <0x4245>
<4242> DW_AT_alignment : 8
<4243> DW_AT_data_member_location: 0
...
The "RUST$ENCODED$ENUM$0$Nothing" means that field 0 is both a pointer and a
discriminant, and if the value is 0, then the enum is just a data-less variant
named "Nothing".
However, the corresponding type has two fields, where not field 0 but field 1
is a pointer, and field 0 is a byte:
...
<2><4245>: Abbrev Number: 8 (DW_TAG_structure_type)
<4246> DW_AT_name : (indirect string, offset: 0x2a11): Thebox
<424a> DW_AT_byte_size : 16
<424b> DW_AT_alignment : 8
<3><424c>: Abbrev Number: 9 (DW_TAG_member)
<424d> DW_AT_name : (indirect string, offset: 0x670): __0
<4251> DW_AT_type : <0x436b>
<4255> DW_AT_alignment : 1
<4256> DW_AT_data_member_location: 8
<3><4257>: Abbrev Number: 9 (DW_TAG_member)
<4258> DW_AT_name : (indirect string, offset: 0x1662): __1
<425c> DW_AT_type : <0x45da>
<4260> DW_AT_alignment : 8
<4261> DW_AT_data_member_location: 0
...
Mark this as xfail.
gdb/testsuite/ChangeLog:
2019-10-09 Tom de Vries <tdevries@suse.de>
PR testsuite/25048
* gdb.rust/simple.exp: Add xfails for incorrect DWARF.
Update a test script to handle the case where missing Ada debug
information means we can't catch exceptions. This was discussed on
the list here:
https://sourceware.org/ml/gdb-patches/2019-08/msg00607.html
And is similar to code that already exists in the test scripts
gdb.ada/catch_ex.exp and gdb.ada/mi_catch_ex.exp.
gdb/testsuite/ChangeLog:
* gdb.ada/catch_ex_std.exp: Handle being unabled to catch Ada
exceptions due to missing debug information.
Now that commit "225f296a023 Change gdb/version.in to 9.0.50.DATE-git (new
version numbering scheme)" has changed the gdb version number, we see:
...
FAIL: gdb.base/default.exp: show convenience ($_gdb_major = 8 not found)
...
Fix this by updating the expected _gdb_major/_gdb_minor to 9.1.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-10-07 Tom de Vries <tdevries@suse.de>
* gdb.base/default.exp: Expect _gdb_major/_gdb_minor to be 9.1.
This commit adds a new feature to gdb_test_multiple, an automatically
created variable gdb_test_name. The idea is to make it easier to
write tests using gdb_test_multiple, and avoid places where the string
passed to pass/fail within an action element is different to the
message passed to the top level gdb_test_multiple.
As an example, previously you might write this:
gdb_test_multiple "print foo" "test foo" {
-re "expected output 1" {
pass "test foo"
}
-re "expected output 2" {
fail "test foo"
}
}
This is OK, but it's easy for the pass/fail strings to come out of
sync, or contain a typo. A better version would look like this:
set testname "test foo"
gdb_test_multiple "print foo" $testname {
-re "expected output 1" {
pass $testname
}
-re "expected output 2" {
fail $testname
}
}
This is better, but its a bit of a drag having to create a new
variable each time.
After this patch you can now write this:
gdb_test_multiple "print foo" "test foo" {
-re "expected output 1" {
pass $gdb_test_name
}
-re "expected output 2" {
fail $gdb_test_name
}
}
The $gdb_test_name is setup by gdb_test_multiple, and cleaned up once
the test has completed. Nested calls to gdb_test_multiple are
supported, though $gdb_test_name will only ever contain the inner most
test message (which is probably what you want).
My only regret is that '$gdb_test_name' is so long, but I wanted
something that was unlikely to clash with any existing variable name,
or anything that a user is likely to want to use.
I've tested this on x86-64/GNU Linux and see no test regressions, and
I've converted one test script over to make use of this new technique
both as an example, and to ensure that the new facility doesn't get
broken. I have no plans to convert all tests over to this technique,
but I hope others will find this useful for writing tests in the
future.
gdb/testsuite/ChangeLog:
* lib/gdb.exp (gdb_test_multiple): Add gdb_test_name mechanism.
* gdb.base/annota1.exp: Update to use gdb_test_name.
This patch adds the CTF (Compact Ansi-C Type Format) support in gdb.
Two submissions on which this gdb work depends were posted earlier
in May:
* On the binutils mailing list - adding libctf which creates, updates,
reads, and manipulates the CTF data.
* On the gcc mailing list - expanding gcc to directly emit the CFT data
with a new command line option -gt.
CTF is a reduced form of debugging information whose main purpose is to
describe the type of C entities such as structures, unions, typedefs and
function arguments at the global scope only. It does not contain debug
information about source lines, location expressions, or local variables.
For more information on CTF, see the documentation in the libdtrace-ctf
source tree, available here:
<https://raw.githubusercontent.com/oracle/libdtrace-ctf/master/doc/ctf-format>.
This patch expands struct elfinfo by adding the .ctf section, which
contains CTF debugging info, and modifies elf_symfile_read() to read it.
If both DWARF and CTF exist in a program, only DWARF will be read. CTF data
will be read only when there is no DWARF. The two-stage symbolic reading
and setting strategy, partial and full, was used.
File ctfread.c contains functions to transform CTF data into gdb's internal
symbol table structures by iterately reading entries from CTF sections
of "data objects", "function info", "variable info", and "data types"
when setting up either partial or full symbol table. If the ELF symbol table
is available, e.g. not stripped, the CTF reader will associate the found
type information with these symbol entries. Due to the proximity between DWARF
and CTF (CTF being a much simplified subset of DWARF), some DWARF implementation
was reused to support CTF.
Test cases ctf-constvars.exp, ctf-cvexpr.exp, ctf-ptype.exp, and ctf-whatis.exp
have been added to verify the correctness of this support.
This patch has missing features and limitations which we will add and
address in the future patches.
gdb/ChangeLog
+2019-10-07 Weimin Pan <weimin.pan@oracle.com>
+
+ * gdb/ctfread.c: New file.
+ * gdb/ctfread.h: New file.
+ * gdb/elfread.c: Include ctfread.h.
+ (struct elfinfo text_p): New member ctfsect.
+ (elf_locate_sections): Mark CTF section.
+ (elf_symfile_read): Call elfctf_build_psymtabs.
+ * gdb/Makefile.in (LIBCTF): Add.
+ (CLIBS): Use it.
+ (CDEPS): Likewise.
+ (DIST): Add ctfread.c.
+ * Makefile.def (dependencies): Add all-libctf to all-gdb
+ * Makefile.in: Add "all-gdb: maybe-all-libctf"
+
gdb/testsuite/ChangeLog
+2019-10-07 Weimin Pan <weimin.pan@oracle.com>
+
+ * gdb.base/ctf-whatis.exp: New file.
+ * gdb.base/ctf-whatis.c: New file.
+ * gdb.base/ctf-ptype.exp: New file.
+ * gdb.base/ctf-ptype.c: New file.
+ * gdb.base/ctf-constvars.exp: New file.
+ * gdb.base/ctf-constvars.c: New file.
+ * gdb.base/ctf-cvexpr.exp: New file.
+
With gdb.cp/local-static.exp and gcc 4.8, I see:
...
gdb compile failed, src/gdb/testsuite/gdb.cp/local-static.c: In function 'main':
src/gdb/testsuite/gdb.cp/local-static.c:148:3: error: 'for' loop initial \
declarations are only allowed in C99 mode
for (int i = 0; i < 1000; i++)
^
src/gdb/testsuite/gdb.cp/local-static.c:148:3: note: use option -std=c99 or \
-std=gnu99 to compile your code
UNTESTED: gdb.cp/local-static.exp: c: failed to prepare
...
Fix this by moving the declaration of int i out of the for loop.
gdb/testsuite/ChangeLog:
2019-10-04 Tom de Vries <tdevries@suse.de>
* gdb.cp/local-static.c (main): Move declaration of int i out of the
for loop.
PR rust/24976 points out a crash in gdb when a single-field union is
used in Rust.
The immediate problem was a NULL pointer dereference in
quirk_rust_enum. However, that code is also erroneously treating a
single-field union as if it were a univariant enum. Looking at the
output of an older Rust compiler, it turns out that univariant enums
are distinguished by having a single *anonymous* field. This patch
changes quirk_rust_enum to limit its fixup to this case.
Tested with a new-enough version of the Rust compiler to cause the
crash; plus by using an older executable that uses the old univariant
encoding.
gdb/ChangeLog
2019-10-03 Tom Tromey <tom@tromey.com>
PR rust/24976:
* dwarf2read.c (quirk_rust_enum): Handle single-element unions.
gdb/testsuite/ChangeLog
2019-10-03 Tom Tromey <tom@tromey.com>
PR rust/24976:
* gdb.rust/simple.rs (Union2): New type.
(main): Use Union2.
* gdb.rust/simple.exp: Add test.
This commit allows symbol matching within Fortran code without having
to specify all of the symbol's scope. For example, given this Fortran
code:
module aaa
contains
subroutine foo
print *, "hello."
end subroutine foo
end module aaa
subroutine foo
print *, "hello."
end subroutine foo
program test
call foo
contains
subroutine foo
print *, "hello."
end subroutine foo
subroutine bar
use aaa
call foo
end subroutine bar
end program test
The user can now do this:
(gdb) b foo
Breakpoint 1 at 0x4006c2: foo. (3 locations)
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y <MULTIPLE>
1.1 y 0x00000000004006c2 in aaa::foo at nest.f90:4
1.2 y 0x0000000000400730 in foo at nest.f90:9
1.3 y 0x00000000004007c3 in test::foo at nest.f90:16
The user asks for a breakpoint on 'foo' and is given a breakpoint on
all three possible 'foo' locations. The user is, of course, still
able to specify the scope in order to place a single breakpoint on
just one of the foo functions (or use 'break -qualified foo' to break
on just the global foo).
gdb/ChangeLog:
* f-lang.c (f_language_defn): Use cp_get_symbol_name_matcher and
cp_search_name_hash.
* NEWS: Add entry about nested function support.
gdb/testsuite/ChangeLog:
* gdb.fortran/nested-funcs-2.exp: Run tests with and without the
nested function prefix.
This patch is a rebase and update of the following three patches:
https://sourceware.org/ml/gdb-patches/2018-11/msg00298.htmlhttps://sourceware.org/ml/gdb-patches/2018-11/msg00302.htmlhttps://sourceware.org/ml/gdb-patches/2018-11/msg00301.html
I have merged these together into a single commit as the second patch,
adding scope support to nested subroutines, means that some of the
changes in the first patch are now no longer useful and would have to
be backed out. The third patch is tightly coupled to the changes in
the second of these patches and I think deserves to live together with
it.
There is an extra change in cp-namespace.c that is new, this resolves
an issue with symbol lookup when placing breakpoints from within
nested subroutines.
There is also an extra test added to this commit 'nested-funcs-2.exp'
that was written by Richard Bunt from ARM, this offers some additional
testing of breakpoints on nested functions.
After this commit it is possible to place breakpoints on nested
Fortran subroutines and functions by using a fully scoped name, for
example, given this simple Fortran program:
program greeting
call message
contains
subroutine message
print *, "Hello World"
end subroutine message
end program greeting
It is possible to place a breakpoint in 'message' with:
(gdb) break greeting::message
Breakpoint 1 at 0x4006c9: file basic.f90, line 5.
What doesn't work with this commit is placing a breakpoint like this:
(gdb) break message
Function "message" not defined.
Making this work will come in a later commit.
gdb/ChangeLog:
* cp-namespace.c (cp_search_static_and_baseclasses): Only search
for nested static variables when searchin VAR_DOMAIN.
* dwarf2read.c (add_partial_symbol): Add nested subroutines to the
global scope, update comment.
(add_partial_subprogram): Call add_partial_subprogram recursively
for nested subroutines when processinng Fortran.
(load_partial_dies): Process the child entities of a subprogram
when processing Fortran.
(partial_die_parent_scope): Handle building scope
for Fortran nested functions.
(process_die): Record that nested functions have a scope.
(new_symbol): Always record Fortran subprograms on the global
symbol list.
(determine_prefix): How to build the prefix for Fortran
subprograms.
gdb/testsuite/ChangeLog:
* gdb.fortran/nested-funcs.exp: Tests for placing breakpoints on
nested functions.
* gdb.fortran/nested-funcs.f90: Update expected results.
* gdb.fortran/nested-funcs-2.exp: New file.
* gdb.fortran/nested-funcs-2.f90: New file.
gdb/doc/ChangeLog:
* doc/gdb.texinfo (Fortran Operators): Describe scope operator.
This commit removes some, but not all, of the test name duplication
within the gdb.python tests. On my local machine this takes the
number of duplicate test names in this set of tests from 174 to 85.
It is possible that different setups might encounter more duplicate
tests.
gdb/testsuite/ChangeLog:
* gdb.python/py-parameter.exp: Make test names unique.
* gdb.python/py-template.exp: Likewise.
* gdb.python/py-value.exp: Likewise.
This commit removes some, but not all, of the test name duplication
within the gdb.base tests. On my local machine this takes the number
of duplicate test names in this set of tests from 454 to 145. It is
possible that different setups might encounter more duplicate tests.
gdb/testsuite/ChangeLog:
* gdb.base/break-interp.exp: Reduce test name duplication.
* gdb.base/call-sc.exp: Likewise.
* gdb.base/callfuncs.exp: Likewise.
* gdb.base/charset.exp: Likewise.
* gdb.base/dump.exp: Likewise.
* gdb.base/ena-dis-br.exp: Likewise.
* gdb.base/relational.exp: Likewise.
* gdb.base/step-over-syscall.exp: Likewise.
* gdb.base/structs.exp: Likewise.
Make test names unique in the gdb.linespec tests. On my local machine
this removed 43 duplicate test names. It is possible that different
setups might still encounter some duplicates.
gdb/testsuite/ChangeLog:
* gdb.linespec/explicit.exp: Make test names unique.
* gdb.linespec/ls-errs.exp: Likewise.
Make test names unique in the gdb.reverse tests. On my local machine
this removed 825 duplicate test names. It is possible that different
setups might still encounter some duplicates.
gdb/testsuite/ChangeLog:
* gdb.reverse/break-precsave.exp: Make test names unique.
* gdb.reverse/break-reverse.exp: Likewise.
* gdb.reverse/finish-precsave.exp: Likewise.
* gdb.reverse/finish-reverse.exp: Likewise.
* gdb.reverse/machinestate-precsave.exp: Likewise.
* gdb.reverse/machinestate.exp: Likewise.
* gdb.reverse/readv-reverse.exp: Likewise.
* gdb.reverse/recvmsg-reverse.exp: Likewise.
* gdb.reverse/sigall-precsave.exp: Likewise.
* gdb.reverse/sigall-reverse.exp: Likewise.
* gdb.reverse/step-indirect-call-thunk.exp: Likewise.
* gdb.reverse/watch-precsave.exp: Likewise.
* gdb.reverse/watch-reverse.exp: Likewise.
It was observed that in a multi-threaded application on GNU/Linux,
that if the user has set the SIGSTOP to be pass (using GDB's handle
command) then the inferior would hang upon hitting a breakpoint.
What happens is that when a thread hits the breakpoint GDB tries to
stop all of the other threads by sending them a SIGSTOP and setting
the stop_requested flag in the target_ops structure - this can be seen
in infrun.c:stop_all_threads.
GDB then waits for all of the other threads to stop.
When the SIGSTOP event arrives we eventually end up in
linux-nat.c:linux_nat_filter_event, which has the job of deciding if
the event we're looking at (the SIGSTOP arriving in this case) is
something that should be reported back to the core of GDB.
One of the final actions of this function is to check if we stopped
due to a signal, and if we did, and the signal has been set to 'pass'
by the user then we ignore the event and resume the thread.
This code already has some conditions in place that mean the event is
reported to GDB even if the signal is in the set of signals to be
passed to the inferior.
In this commit I extend this condition such that:
If the signal is a SIGSTOP, and the thread's stop_requested flag is
set (indicating we're waiting for the thread to stop with a SIGSTOP)
then we should report this SIGSTOP to GDB and not pass it to the
inferior.
With this change in place the test now passes. Regression tested on
x86-64 GNU/Linux with no regressions.
gdb/ChangeLog:
* linux-nat.c (linux_nat_filter_event): Don't ignore SIGSTOP if we
have just sent the thread a SIGSTOP and are waiting for it to
arrive.
gdb/testsuite/ChangeLog:
* gdb.threads/stop-with-handle.c: New file.
* gdb.threads/stop-with-handle.exp: New file.
With gcc 4.8.1, we see this FAIL:
...
(gdb) PASS: gdb.base/list-missing-source.exp: list
info source^M
Current source file is outputs/gdb.base/list-missing-source/main.c^M
Source language is c.^M
Producer is GNU C 4.8.5 -mtune=generic -march=x86-64 -g -fno-stack-protector.^M
Compiled with DWARF 2 debugging format.^M
Does not include preprocessor macro info.^M
(gdb) FAIL: gdb.base/list-missing-source.exp: info source
...
The problem is that a "Compilation directory is <dir>" line is expected, but
this is missing due to the fact the the compilation unit for main.c doesn't
contain a DW_AT_comp_dir in the DW_TAG_compile_unit DIE.
Fix this by allowing the "Compilation directory" line to be missing.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-10-03 Tom de Vries <tdevries@suse.de>
PR testsuite/25059
* gdb.base/list-missing-source.exp: Allowing the "Compilation
directory" line to be missing.
The gdb.base/info-types.exp test-case FAILs with gcc/g++ 4.8 because the DWARF
record for the 'unsigned int' type is missing in the executables, while it is
present for gcc/g++ 7.4.1.
For a minimal example using gcc 7.4.1:
...
$ echo "enum enum_t { AA, BB, CC }; enum enum_t var;" > enum.c
$ gcc enum.c -c -g
...
we find that the enum type has DW_AT_encoding 'unsigned':
<1><1d>: Abbrev Number: 2 (DW_TAG_enumeration_type)
<1e> DW_AT_name : (indirect string, offset: 0x1f): enum_t
<22> DW_AT_encoding : 7 (unsigned)
<23> DW_AT_byte_size : 4
<24> DW_AT_type : <0x3e>
<28> DW_AT_decl_file : 1
<29> DW_AT_decl_line : 1
<2a> DW_AT_sibling : <0x3e>
...
and a DW_AT_type reference to the type 'unsigned int':
...
<1><3e>: Abbrev Number: 4 (DW_TAG_base_type)
<3f> DW_AT_byte_size : 4
<40> DW_AT_encoding : 7 (unsigned)
<41> DW_AT_name : (indirect string, offset: 0x26): unsigned int
...
With gcc 4.8.5 however, we have no 'unsigned' encoding, and no DW_AT_type:
...
<1><1d>: Abbrev Number: 2 (DW_TAG_enumeration_type)
<1e> DW_AT_name : (indirect string, offset: 0x1f): enum_t
<22> DW_AT_byte_size : 4
<23> DW_AT_decl_file : 1
<24> DW_AT_decl_line : 1
<25> DW_AT_sibling : <0x39>
...
as well as no record for 'unsigned int'.
Make the test-case pass with gcc/g++ 4.8 by making the presence of the
'unsigned int' type optional.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-10-03 Tom de Vries <tdevries@suse.de>
PR testsuite/25059
* gdb.base/info-types.exp: Make the presence of the 'unsigned int'
type optional.
GDB's py-format-string test case depends on endianness. In particular it
relies on the first byte of the machine representation of 42 (as an int)
to be 42 as well. While this is indeed the case for little-endian
machines, big-endian machines store a zero in the first byte instead. The
wrong assumption leads to lots of FAILs on such architectures.
Fix this by filling the affected union with bytes of the same value, such
that endianness does not matter. Use the value 42, to keep the character
in the first byte unchanged.
gdb/testsuite/ChangeLog:
* gdb.python/py-format-string.c (string.h): New include.
(main): Fill a_struct_with_union.the_union.an_int with bytes of
the same value, for endianness-independence.
* gdb.python/py-format-string.exp (default_regexp_dict)
(test_pretty_structs, test_format): Adjust expected output to the
changed initialization.
This adds the $_ada_exception convenience variable. It is set by the
Ada exception catchpoints, and holds the address of the exception
currently being thrown. This is useful because it allows more
fine-grained filtering of exceptions than is possible using the
existing "catch" syntax.
This also simplifies Ada catchpoints somewhat; because the catchpoint
must now carry the "kind", it's possible to remove many helper
functions.
gdb/ChangeLog
2019-10-02 Tom Tromey <tromey@adacore.com>
* NEWS: Add $_ada_exception entry.
* ada-lang.c (struct ada_catchpoint): Add constructor.
<m_kind>: New member.
(allocate_location_exception, re_set_exception): Remove
"ex" parameter.
(should_stop_exception): Compute $_ada_exception.
(check_status_exception, print_it_exception)
(print_one_exception, print_mention_exception): Remove
"ex" parameter.
(allocate_location_catch_exception, re_set_catch_exception)
(check_status_exception, print_it_catch_exception)
(print_one_catch_exception, print_mention_catch_exception)
(print_recreate_catch_exception)
(allocate_location_catch_exception_unhandled)
(re_set_catch_exception_unhandled)
(check_status_exception, print_it_catch_exception_unhandled)
(print_one_catch_exception_unhandled)
(print_mention_catch_exception_unhandled)
(print_recreate_catch_exception_unhandled)
(allocate_location_catch_assert, re_set_catch_assert)
(check_status_assert, print_it_catch_assert)
(print_one_catch_assert, print_mention_catch_assert)
(print_recreate_catch_assert)
(allocate_location_catch_handlers, re_set_catch_handlers)
(check_status_handlers, print_it_catch_handlers)
(print_one_catch_handlers, print_mention_catch_handlers)
(print_recreate_catch_handlers): Remove.
(create_ada_exception_catchpoint): Update.
(initialize_ada_catchpoint_ops): Update.
gdb/doc/ChangeLog
2019-10-02 Tom Tromey <tromey@adacore.com>
* gdb.texinfo (Set Catchpoints, Convenience Vars): Document
$_ada_exception.
gdb/testsuite/ChangeLog
2019-10-02 Tom Tromey <tromey@adacore.com>
* gdb.ada/catch_ex_std.exp: Add $_ada_exception test.
Make gdb.base/print-file-var.exp test all combinations of:
- attribute hidden in the this_version_id symbols or not
- dlopen or not
- this_version_id symbol in main file or not
- C++
gdb/testsuite/ChangeLog
2019-10-02 Pedro Alves <palves@redhat.com>
Andrew Burgess <andrew.burgess@embecosm.com>
* gdb.base/print-file-var-lib1.c: Include <stdio.h> and
"print-file-var.h".
(this_version_id) Use ATTRIBUTE_VISIBILITY.
(get_version_1): Print this_version_id and its address.
Add extern "C" wrappers around interface functions.
* gdb.base/print-file-var-lib2.c: Include <stdio.h> and
"print-file-var.h".
(this_version_id) Use ATTRIBUTE_VISIBILITY.
(get_version_2): Print this_version_id and its address.
Add extern "C" wrappers around interface functions.
* gdb.base/print-file-var-main.c: Include <dlfcn.h>, <assert.h>,
<stddef.h> and "print-file-var.h".
Add extern "C" wrappers around interface functions.
[VERSION_ID_MAIN] (this_version_id): Define.
(main): Define v0. Use dlopen if SHLIB_NAME is defined.
* gdb.base/print-file-var.h: Add some #defines to simplify setting
up extern "C" blocks.
* gdb.base/print-file-var.exp (test): New, factored out from top
level.
(top level): Test all combinations of attribute hidden or not,
dlopen or not, and this_version_id symbol in main file or not.
Compile tests as both C++ and C, make test names unique.
This changes "show logging filename" to style its output.
gdb/ChangeLog
2019-10-01 Tom Tromey <tom@tromey.com>
* cli/cli-logging.c (show_logging_filename): Use styled_string.
gdb/testsuite/ChangeLog
2019-10-01 Tom Tromey <tom@tromey.com>
* gdb.base/style.exp: Test "show logging filename".
This introduces a new "metadata" style and changes many places in gdb
to use it. The idea here is to let the user distinguish gdb output
from output that (conceptually at least) comes directly from the
inferior. The newly-styled category includes text that gdb
traditionally surrounds in "<...>", like "<unavailable>".
I only added a single test for this. In many cases this output is
difficult to test. Also, while developing this errors in the
implementation of the new printf formats showed up as regressions.
gdb/ChangeLog
2019-10-01 Tom Tromey <tom@tromey.com>
* p-lang.c (pascal_printstr): Use metadata style.
* value.c (show_convenience): Use metadata style.
* valprint.c (valprint_check_validity, val_print_optimized_out)
(val_print_not_saved, val_print_unavailable)
(val_print_invalid_address, generic_val_print, val_print)
(value_check_printable, val_print_array_elements): Use metadata
style.
* ui-out.h (class ui_out) <field_fmt>: New overload.
<do_field_fmt>: Add style parameter.
* ui-out.c (ui_out::field_fmt): New overload.
* typeprint.c (type_print_unknown_return_type)
(val_print_not_allocated, val_print_not_associated): Use metadata
style.
* tui/tui-out.h (class tui_ui_out) <do_field_fmt>: Add style
parameter.
* tui/tui-out.c (tui_ui_out::do_field_fmt): Update.
* tracepoint.c (tvariables_info_1): Use metadata style.
* stack.c (print_frame_arg, print_frame_info, print_frame)
(info_frame_command_core): Use metadata style.
* skip.c (info_skip_command): Use metadata style.
* rust-lang.c (rust_print_enum): Use metadata style.
* python/py-prettyprint.c (print_stack_unless_memory_error): Use
metadata style.
* python/py-framefilter.c (py_print_single_arg): Use metadata
style.
* printcmd.c (do_one_display, print_variable_and_value): Use
metadata style.
* p-valprint.c (pascal_val_print)
(pascal_object_print_value_fields): Use metadata style.
* p-typeprint.c (pascal_type_print_base): Use metadata style.
* mi/mi-out.h (class mi_ui_out) <do_field_fmt>: Add style
parameter.
* mi/mi-out.c (mi_ui_out::do_field_fmt): Update.
* m2-valprint.c (m2_print_long_set): Use metadata style.
* m2-typeprint.c (m2_print_type): Use metadata style.
* infcmd.c (print_return_value_1): Use metadata style.
* gnu-v3-abi.c (print_one_vtable): Use metadata style.
* f-valprint.c (info_common_command_for_block): Use metadata
style.
* f-typeprint.c (f_type_print_base): Use metadata style.
* expprint.c (print_subexp_standard): Use metadata style.
* cp-valprint.c (cp_print_value_fields): Use metadata style.
* cli/cli-style.h (class cli_style_option): Add constructor.
(metadata_style): Declare.
* cli/cli-style.c (metadata_style): New global.
(_initialize_cli_style): Register metadata style.
* cli-out.h (class cli_ui_out) <do_field_fmt>: Add style
parameter.
* cli-out.c (cli_ui_out::do_field_fmt): Update.
* c-typeprint.c (c_type_print_base_struct_union)
(c_type_print_base_1): Use metadata style.
* breakpoint.c (watchpoint_value_print)
(print_one_breakpoint_location): Use metadata style.
* break-catch-syscall.c (print_one_catch_syscall): Use metadata
style.
* break-catch-sig.c (signal_catchpoint_print_one): Use metadata
style.
* ada-valprint.c (val_print_packed_array_elements, printstr)
(print_field_values, ada_val_print_ref, ada_val_print): Use
metadata style.
* ada-typeprint.c (print_array_type, ada_print_type): Use metadata
style.
* ada-tasks.c (print_ada_task_info, info_task): Use metadata
style.
* ada-lang.c (user_select_syms): Use metadata style.
gdb/testsuite/ChangeLog
2019-10-01 Tom Tromey <tom@tromey.com>
* lib/gdb-utils.exp (style): Handle "metadata" argument.
* gdb.base/style.exp: Add metadata style test.
This changes the "pwd" command to style its output.
gdb/ChangeLog
2019-10-01 Tom Tromey <tom@tromey.com>
* cli/cli-cmds.c (pwd_command): Style output.
gdb/testsuite/ChangeLog
2019-10-01 Tom Tromey <tom@tromey.com>
* gdb.base/style.exp: Test "pwd".
This introduces a few gdb-specific %p format suffixes. This is useful
for emitting gdb-specific output in an ergonomic way. It also yields
code that is more i18n-friendly.
The comment before ui_out::message explains the details.
Note that the tests had to change a little. When using one of the gdb
printf functions with styling, there can be spurious style changes
emitted to the output. This did not seem worthwhile to fix, as the
low-level output functions are rather spaghetti-ish already, and I
didn't want to make them even worse.
This change also necessitated adding support for "*" as precision and
width in format_pieces. These are used in various spots in gdb, and
it seemed better to me to implement them than to remove the uses.
gdb/ChangeLog
2019-10-01 Pedro Alves <palves@redhat.com>
Tom Tromey <tom@tromey.com>
* unittests/format_pieces-selftests.c: Add gdb_format parameter.
(test_gdb_formats): New function.
(run_tests): Call it.
(test_format_specifier): Update.
* utils.h (fputs_filtered): Update comment.
(vfprintf_styled, vfprintf_styled_no_gdbfmt)
(fputs_styled_unfiltered): Declare.
* utils.c (fputs_styled_unfiltered): New function.
(vfprintf_maybe_filtered): Add gdbfmt parameter.
(vfprintf_filtered): Update.
(vfprintf_unfiltered, vprintf_filtered): Update.
(vfprintf_styled, vfprintf_styled_no_gdbfmt): New functions.
* ui-out.h (enum ui_out_flag) <unfiltered_output,
disallow_ui_out_field>: New constants.
(enum class field_kind): New.
(struct base_field_s, struct signed_field_s): New.
(signed_field): New function.
(struct string_field_s): New.
(string_field): New function.
(struct styled_string_s): New.
(styled_string): New function.
(class ui_out) <message>: Add comment.
<vmessage, call_do_message>: New methods.
<do_message>: Add style parameter.
* ui-out.c (ui_out::call_do_message, ui_out::vmessage): New
methods.
(ui_out::message): Rewrite.
* mi/mi-out.h (class mi_ui_out) <do_message>: Add style
parameter.
* mi/mi-out.c (mi_ui_out::do_message): Add style parameter.
* gdbsupport/format.h (class format_pieces) <format_pieces>: Add
gdb_extensions parameter.
(class format_piece): Add parameter to constructor.
(n_int_args): New field.
* gdbsupport/format.c (format_pieces::format_pieces): Add
gdb_extensions parameter. Handle '*'.
* cli-out.h (class cli_ui_out) <do_message>: Add style parameter.
* cli-out.c (cli_ui_out::do_message): Add style parameter. Call
vfprintf_styled_no_gdbfmt.
(cli_ui_out::do_field_string, cli_ui_out::do_spaces)
(cli_ui_out::do_text, cli_ui_out::field_separator): Allow
unfiltered output.
* ui-style.h (struct ui_file_style) <ptr>: New method.
gdb/testsuite/ChangeLog
2019-10-01 Tom Tromey <tom@tromey.com>
* gdb.base/style.exp: Update tests.
The pretty-print test case fails on s390/s390x because it relies on a
little-endian representation of bit fields. Little-endian architectures
typically allocate bit fields from least to most significant bit, but
big-endian architectures typically use the reverse order, allocating the
most significant bit first. Thus the two bit fields in each of the test
case's unions overlap either in their lower or in their higher bits,
depending on the target's endianness:
union {
int three : 3;
int four : 4;
};
Now, when initializing 'three' with 3, 'four' will become 3 on little
endian targets, but 6 on big-endian targets, making it FAIL there.
Fix this by initializing the longer bit field instead and using an
all-ones bit pattern. In this way the result does not depend on
endianness. Use 'unsigned' instead of int for one of the bit fields in
each of the unions, to increase the variety of resulting values.
gdb/testsuite/ChangeLog:
* gdb.base/pretty-print.c (struct s1_t): Change fields 'three' and
'six' to unsigned.
(s1): Initialize fields 'four' and 'six' instead of 'three' and
'five'. Use an all-ones bit pattern for each.
* gdb.base/pretty-print.exp: Adjust expected output of "print s1"
to its changed values.
With rustc 1.37, I started seeing compiler warnings from the traits.rs
test case:
warning: trait objects without an explicit `dyn` are deprecated
It seems to me that we generally do not want warnings in these test
cases. At some point, we'll probably have to patch traits.rs to use
the "dyn" keyword; by that time I expect that all the Rust compilers
in common use will support it. In the meantime it seemed simplest to
simply disable all warnings in this file.
gdb/testsuite/ChangeLog
2019-09-30 Tom Tromey <tromey@adacore.com>
* gdb.rust/traits.rs: Disable all warnings.
When running a test-case gdb.base/foo.exp with cc-with-dwz-m, a file
build/gdb/testsuite/outputs/gdb.base/foo/foo.dwz will be created, alongside
executable build/gdb/testsuite/outputs/gdb.base/foo/foo.
This can cause problems in f.i. test-cases that test file name completion.
Make these problems less likely by moving foo.dwz to a .tmp subdir:
build/gdb/testsuite/outputs/gdb.base/foo/.tmp/foo.dwz.
Tested on x86_64-linux.
gdb/ChangeLog:
2019-09-29 Tom de Vries <tdevries@suse.de>
* contrib/cc-with-tweaks.sh (get_tmpdir): New function.
Use $tmpdir/$(basename "$output_file").dwz instead of
"${output_file}.dwz".
gdb/testsuite/ChangeLog:
2019-09-29 Tom de Vries <tdevries@suse.de>
* gdb.dwarf2/gdb-index.exp: Handle new location of .dwz file.
With cc-with-dwz-m, we get:
...
PASS: gdb.dwarf2/gdb-index.exp: objcopy
PASS: gdb.dwarf2/gdb-index.exp: objcopy
...
Make the pass message unique by using with_test_prefix:
...
PASS: gdb.dwarf2/gdb-index.exp: objcopy
PASS: gdb.dwarf2/gdb-index.exp: modify dwz file: objcopy
...
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-09-29 Tom de Vries <tdevries@suse.de>
* gdb.dwarf2/gdb-index.exp: Use with_test_prefix for second objcopy.
The commit 68f7d34dd5 "[gdb/testsuite] Add KFAIL for missing support of
reverse-debugging of vmovd" rewrites a gdb_test into a gdb_test_multiple but
forgets to add the $gdb_prompt part in the regexp.
Add the missing parts of the regexps.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-09-27 Tom de Vries <tdevries@suse.de>
* gdb.reverse/step-precsave.exp: Add missing $gdb_prompt in regexps.
On my openSUSE Leap 15.1 system I run into:
...
(gdb) PASS: gdb.reverse/step-precsave.exp: turn on process record
break 76^M
Breakpoint 2 at 0x400654: file step-reverse.c, line 76.^M
(gdb) PASS: gdb.reverse/step-precsave.exp: breakpoint at end of main
continue^M
Continuing.^M
Process record does not support instruction 0xc5 at address 0x7ffff783fc70.^M
Process record: failed to record execution log.^M
^M
Program stopped.^M
0x00007ffff783fc70 in __memset_avx2_unaligned_erms () from /lib64/libc.so.6^M
(gdb) FAIL: gdb.reverse/step-precsave.exp: run to end of main
...
The problem is that the vmovd instruction is not supported in
reverse-debugging (PR record/23188).
Add a KFAIL for this PR.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-09-27 Tom de Vries <tdevries@suse.de>
PR record/23188
* gdb.reverse/step-precsave.exp: Add kfail for PR record/23188.
dwarf2read.c will create stub types for Ada "Taft Amendment" types.
These stub types can currently be exposed to Python code, where they
show up as TYPE_CODE_VOID types (but that, mysteriously, can sometimes
be used in other ways).
While it's possible to work with such types by using strip_typedefs,
this seemed unpleasant to me. This patch takes another approach
instead, which is to try not to expose stub types to Python users.
gdb/ChangeLog
2019-09-26 Tom Tromey <tromey@adacore.com>
* python/py-type.c (type_to_type_object): Call check_typedef
for stub types.
gdb/testsuite/ChangeLog
2019-09-26 Tom Tromey <tromey@adacore.com>
* gdb.ada/py_taft.exp: New file.
* gdb.ada/py_taft/main.adb: New file.
* gdb.ada/py_taft/pkg.adb: New file.
* gdb.ada/py_taft/pkg.ads: New file.
On my openSUSE Leap 15.1 x86_64 Skylake system with the default (4.12) kernel,
I run into:
...
FAIL: gdb.base/gcore.exp: corefile restored all registers
...
The problem is that there's a difference in the mxcsr register value before
and after the gcore command:
...
- mxcsr 0x0 [ ]
+ mxcsr 0x400440 [ DAZ OM ]
...
This can be traced back to amd64_linux_nat_target::fetch_registers, where
xstateregs is partially initialized by the ptrace call:
...
char xstateregs[X86_XSTATE_MAX_SIZE];
struct iovec iov;
amd64_collect_xsave (regcache, -1, xstateregs, 0);
iov.iov_base = xstateregs;
iov.iov_len = sizeof (xstateregs);
if (ptrace (PTRACE_GETREGSET, tid,
(unsigned int) NT_X86_XSTATE, (long) &iov) < 0)
perror_with_name (_("Couldn't get extended state status"));
amd64_supply_xsave (regcache, -1, xstateregs);
...
after which amd64_supply_xsave is called.
The amd64_supply_xsave call is supposed to only use initialized parts of
xstateregs, but due to a kernel bug on intel skylake (fixed from 4.14 onwards
by commit 0852b374173b "x86/fpu: Add FPU state copying quirk to handle XRSTOR
failure on Intel Skylake CPUs") it can happen that the mxcsr part of
xstateregs is not initialized, while amd64_supply_xsave expects it to be
initialized, which explains the FAIL mentioned above.
Fix the undetermined behaviour by initializing xstateregs before calling
ptrace, which makes sure we get a 0x0 for mxcsr when this kernel bug occurs,
and which also happens to fix the FAIL.
Furthermore, add an xfail for this FAIL which triggers the same kernel bug:
...
FAIL: gdb.arch/amd64-init-x87-values.exp: check_setting_mxcsr_before_enable: \
check new value of MXCSR is still in place
...
Both FAILs pass when using a 5.3 kernel instead on the system mentioned above.
Tested on x86_64-linux.
gdb/ChangeLog:
2019-09-24 Tom de Vries <tdevries@suse.de>
PR gdb/23815
* amd64-linux-nat.c (amd64_linux_nat_target::fetch_registers):
Initialize xstateregs before ptrace PTRACE_GETREGSET call.
gdb/testsuite/ChangeLog:
2019-09-24 Tom de Vries <tdevries@suse.de>
PR gdb/24598
* gdb.arch/amd64-init-x87-values.exp: Add xfail.
We currently run into:
...
248 n = callee1 (n + l5);
(gdb) PASS: gdb.base/restore.exp: caller5 calls callee1; return callee now
print l1
$51 = <optimized out>
(gdb) FAIL: gdb.base/restore.exp: caller5 calls callee1; return restored l1 \
to 32492
...
The problem is that we try to access the value of l1 in function caller5, but
variable l1 has no DW_AT_location attribute. Since l1 is declared using the
register keyword, it's valid for gcc to emit no DW_AT_location at -O0.
Change the FAIL into an UNSUPPORTED.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-09-22 Tom de Vries <tdevries@suse.de>
* gdb.base/restore.exp: Allow register variables to be optimized out at
-O0.
If gdb_test is used with fewer than five arguments, then the question_string
defaults to "^FOOBAR$":
...
if [llength $args]==5 {
set question_string [lindex $args 3]
set response_string [lindex $args 4]
} else {
set question_string "^FOOBAR$"
}
...
This can however match "FOOBAR", so perhaps "\$FOOBAR^" would have been a
better choice.
Eliminate the FOOBAR pattern from gdb_test by instead of defining a default
regexp, conditionally appending the regexp matching to a user_code variable.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-09-19 Tom de Vries <tdevries@suse.de>
* lib/gdb.exp (gdb_test): Eliminate "^FOOBAR$" pattern.
In commit 81dc3ab594 "[gdb/testsuite] Handle unreachable network in
server-connect.exp" a regression was introduced in gdb_target_cmd, causing
ERRORs like this:
...
ERROR: tcl error sourcing src/gdb/testsuite/gdb.server/abspath.exp.
ERROR: wrong # args: should be "gdb_target_cmd {$args}"
while executing
"gdb_target_cmd $gdbserver_protocol $gdbserver_gdbport"
...
Fix the argument passing in gdb_target_cmd.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-09-19 Tom de Vries <tdevries@suse.de>
* lib/gdbserver-support.exp (gdb_target_cmd): Fix argument passing.
When running gdb.server/server-connect.exp I run into:
...
FAIL: gdb.server/server-connect.exp: tcp6: connect to gdbserver using tcp6:::1
FAIL: gdb.server/server-connect.exp: tcp6-with-brackets: connect to gdbserver \
using tcp6:[::1]
FAIL: gdb.server/server-connect.exp: udp6: connect to gdbserver using udp6:::1
FAIL: gdb.server/server-connect.exp: udp6-with-brackets: connect to gdbserver \
using udp6:[::1]
...
The FAIL is caused by the fact that the ipv6 loopback address is not available:
...
PASS: gdb.server/server-connect.exp: tcp6: start gdbserver
target remote tcp6:::1:2347^M
A program is being debugged already. Kill it? (y or n) y^M
tcp6:::1:2347: Network is unreachable.^M
(gdb) FAIL: gdb.server/server-connect.exp: tcp6: connect to gdbserver using tcp6:::1
...
This should be marked UNSUPPORTED rather than FAIL.
Furthermore, the test-case takes about 4 minutes, because the 'Network is
unreachable' response is not explicitly handled in gdb_target_cmd, so instead
it runs into the timeout case.
Fix this by handling the 'Network is unreachable' response as UNSUPPORTED.
This reduces testing time from 4 minutes to about 2 seconds.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-09-19 Tom de Vries <tdevries@suse.de>
* lib/gdbserver-support.exp (gdb_target_cmd_ext): Return 2 (meaning
UNSUPPORTED) for 'Network is unreachable' message. Factor out of ...
(gdb_target_cmd): ... here.
* gdb.server/server-connect.exp: Use gdb_target_cmd_ext, handle return
value 2.
Give a test an actual name in order to avoid having a directory name
in the .sum file.
gdb/testsuite/ChangeLog:
* gdb.base/source-dir.exp: Avoid having directory names in test
names.
The 'directory' command allows the user to provide a list of filesystem
directories in which to search for source code. The directories in this
search path are used as the base directory for the source filename from
the debug information (DW_AT_name). Thus the directory search path
provides alternatives to the existing compilation directory from the
debug information (DW_AT_comp_dir). Generally speaking, DW_AT_name
stores the filename argument passed to the compiler (including any
directory components), and DW_AT_comp_dir stores the current working
directory from which the compiler was executed. For example:
$ cd /path/to/project/subdir1
$ gcc -c a/test.c -g
The corresponding debug information will look like this:
DW_AT_name : a/test.c
DW_AT_comp_dir : /path/to/project/subdir1
When compiling with the -fdebug-prefix-map GCC option, the compilation
directory can be arbitrarily rewritten. In the above example, we may
rewrite the compilation directory as follows:
$ gcc -c a/test.c -g -fdebug-prefix-map=/path/to/project=
In this case, the corresponding debug information will look like:
DW_AT_name : a/test.c
DW_AT_comp_dir : /subdir1
This prevents GDB from finding the corresponding source code based on
the debug information alone. In some cases, a substitute-path command
can be used to re-map a consistent prefix in the rewritten compilation
directory to the real filesystem path. However, there may not be a
consistent prefix remaining in the debug symbols (for example in a
project that has source code in many subdirectories under the project's
root), thereby requiring multiple substitute-path rules. In this case,
it is easier to add the missing prefix to the directory search path via
the 'directory' command.
The function find_and_open_source currently searches in:
SEARCH_PATH/FILENAME
where SEARCH_PATH corresponds to each individual entry in the directory
search path (which is guaranteed to contain the compilation directory
from the debug information, as well as the current working directory).
FILENAME corresponds to the source filename (DW_AT_name), which may have
directory components in it. In addition, GDB searches in:
SEARCH_PATH/FILE_BASENAME
where FILE_BASENAME is the basename of the DW_AT_name entry.
This change modifies find_and_open_source to additionally search in:
SEARCH_PATH/COMP_DIR/FILENAME
where COMP_DIR is the compilation directory from the debug symbols. In
the example given earlier, running:
(gdb) directory /path/to/project
will now allow GDB to correctly locate the source code from the debug
information.
gdb/ChangeLog:
* source.c (prepare_path_for_appending): New function.
(openp): Make use of new function.
(find_and_open_source): Search for the compilation directory and
source file as a relative path beneath the directory search path.
gdb/doc/ChangeLog:
* gdb.texinfo (Source Path): Additional text to better describe
how the source path directory list is used when searching for
source files.
gdb/testsuite/ChangeLog:
* gdb.base/source-dir.exp: Add extra test for mapped compilation
directory.
The source_cache::get_line_charpos function can currently throw an
exception if the source file is missing, which doesn't match the
expected behaviour documented in the functions header file. The
documented behaviour is to return false on failure, and this is how
the function appears to be used throughout GDB.
I spotted this in the 'info source' command, currently for a missing
source file you'll see something like this:
(gdb) info source
Current source file is /path/to/src/file.c
Compilation directory is /path/to/build/
/path/to/src/file.c: No such file or directory.
(gdb)
After this patch we see this:
(gdb) info source
Current source file is /path/to/src/file.c
Compilation directory is /path/to/build/
Source language is c.
Producer is COMPILER VERSION AND FLAGS.
Compiled with DWARF 2 debugging format.
Does not include preprocessor macro info.
We don't currently indicate that the source file can't be found, and
maybe that would be something worth adding in the future.
gdb/ChangeLog:
* source-cache.c (source_cache::get_line_charpos): Catch
exceptions and return false, this matches the behaviour documented
in the header file.
gdb/testsuite/ChangeLog:
* gdb.base/list-missing-source.exp: New file.
When running gdb.ada/rename_subscript_param.exp with gnatmake 7.4.1, we get:
...
FAIL: gdb.ada/rename_subscript_param.exp: print rename_subscript_param_b \
before changing its value
FAIL: gdb.ada/rename_subscript_param.exp: print rename_subscript_param_b \
after changing its value
...
The commit last touching the test-case (afcfda091e) states:
...
The test still fails with old compilers that do not properly
generate debug info for this renaming:
...
Fix this by requiring at least gnatmake 8 for the test-case.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-09-14 Tom de Vries <tdevries@suse.de>
PR teststuite/24599
* gdb.ada/rename_subscript_param.exp: Require gnatmake 8.
* lib/ada.exp (gnatmake_version_at_least): New proc.
Make use of exec_has_index_section library function rather than
manually checking in the 'maintenance info sections' output. Should
make no difference to the test results, just makes the code easier to
read.
gdb/testsuite/ChangeLog:
* gdb.base/maint.exp: Use exec_has_index_section.
In this commit:
commit 6eac171f06
Date: Fri Aug 16 00:25:14 2019 +0200
[gdb] Make maint info sections print relocated addresses
A couple of things broke with the 'maintenance info sections' command,
here is some before output:
(gdb) maintenance info sections
Exec file:
`/path/to/gdb/build/gdb/testsuite/outputs/gdb.base/maint/maint',
file type elf64-x86-64.
[0] 0x00400238->0x00400254 at 0x00000238: .interp ALLOC LOAD READONLY DATA HAS_CONTENTS
[1] 0x00400254->0x00400274 at 0x00000254: .note.ABI-tag ALLOC LOAD READONLY DATA HAS_CONTENTS
[2] 0x00400274->0x00400298 at 0x00000274: .note.gnu.build-id ALLOC LOAD READONLY DATA HAS_CONTENTS
[3] 0x00400298->0x004002bc at 0x00000298: .gnu.hash ALLOC LOAD READONLY DATA HAS_CONTENTS
[4] 0x004002c0->0x00400380 at 0x000002c0: .dynsym ALLOC LOAD READONLY DATA HAS_CONTENTS
[5] 0x00400380->0x004003e3 at 0x00000380: .dynstr ALLOC LOAD READONLY DATA HAS_CONTENTS
[6] 0x004003e4->0x004003f4 at 0x000003e4: .gnu.version ALLOC LOAD READONLY DATA HAS_CONTENTS
[7] 0x004003f8->0x00400418 at 0x000003f8: .gnu.version_r ALLOC LOAD READONLY DATA HAS_CONTENTS
[8] 0x00400418->0x00400460 at 0x00000418: .rela.dyn ALLOC LOAD READONLY DATA HAS_CONTENTS
[9] 0x00400460->0x004004c0 at 0x00000460: .rela.plt ALLOC LOAD READONLY DATA HAS_CONTENTS
[10] 0x004004c0->0x004004d7 at 0x000004c0: .init ALLOC LOAD READONLY CODE HAS_CONTENTS
[11] 0x004004e0->0x00400530 at 0x000004e0: .plt ALLOC LOAD READONLY CODE HAS_CONTENTS
[12] 0x00400530->0x00400802 at 0x00000530: .text ALLOC LOAD READONLY CODE HAS_CONTENTS
[13] 0x00400804->0x0040080d at 0x00000804: .fini ALLOC LOAD READONLY CODE HAS_CONTENTS
[14] 0x00400810->0x0040084e at 0x00000810: .rodata ALLOC LOAD READONLY DATA HAS_CONTENTS
[15] 0x00400850->0x004008c4 at 0x00000850: .eh_frame_hdr ALLOC LOAD READONLY DATA HAS_CONTENTS
[16] 0x004008c8->0x00400ab8 at 0x000008c8: .eh_frame ALLOC LOAD READONLY DATA HAS_CONTENTS
[17] 0x00600e00->0x00600e08 at 0x00000e00: .init_array ALLOC LOAD DATA HAS_CONTENTS
[18] 0x00600e08->0x00600e10 at 0x00000e08: .fini_array ALLOC LOAD DATA HAS_CONTENTS
[19] 0x00600e10->0x00600ff0 at 0x00000e10: .dynamic ALLOC LOAD DATA HAS_CONTENTS
[20] 0x00600ff0->0x00601000 at 0x00000ff0: .got ALLOC LOAD DATA HAS_CONTENTS
[21] 0x00601000->0x00601038 at 0x00001000: .got.plt ALLOC LOAD DATA HAS_CONTENTS
[22] 0x00601038->0x0060103c at 0x00001038: .data ALLOC LOAD DATA HAS_CONTENTS
[23] 0x00601040->0x006012c8 at 0x0000103c: .bss ALLOC
[24] 0x00000000->0x0000002c at 0x0000103c: .comment READONLY HAS_CONTENTS
[25] 0x00000000->0x00000060 at 0x00001068: .debug_aranges READONLY HAS_CONTENTS
[26] 0x00000000->0x0000061b at 0x000010c8: .debug_info READONLY HAS_CONTENTS
[27] 0x00000000->0x00000264 at 0x000016e3: .debug_abbrev READONLY HAS_CONTENTS
[28] 0x00000000->0x000001e6 at 0x00001947: .debug_line READONLY HAS_CONTENTS
[29] 0x00000000->0x00000487 at 0x00001b2d: .debug_str READONLY HAS_CONTENTS
(gdb)
And here is the output after the above commit:
(gdb) maintenance info sections
+maintenance info sections
Exec file:
`/path/to/gdb/build/gdb/testsuite/outputs/gdb.base/maint/maint',
file type elf64-x86-64.
0x00400238->0x00400254 at 0x00000238: .interp ALLOC LOAD READONLY DATA HAS_CONTENTS
0x00400254->0x00400274 at 0x00000254: .note.ABI-tag ALLOC LOAD READONLY DATA HAS_CONTENTS
0x00400274->0x00400298 at 0x00000274: .note.gnu.build-id ALLOC LOAD READONLY DATA HAS_CONTENTS
0x00400298->0x004002bc at 0x00000298: .gnu.hash ALLOC LOAD READONLY DATA HAS_CONTENTS
0x004002c0->0x00400380 at 0x000002c0: .dynsym ALLOC LOAD READONLY DATA HAS_CONTENTS
0x00400380->0x004003e3 at 0x00000380: .dynstr ALLOC LOAD READONLY DATA HAS_CONTENTS
0x004003e4->0x004003f4 at 0x000003e4: .gnu.version ALLOC LOAD READONLY DATA HAS_CONTENTS
0x004003f8->0x00400418 at 0x000003f8: .gnu.version_r ALLOC LOAD READONLY DATA HAS_CONTENTS
0x00400418->0x00400460 at 0x00000418: .rela.dyn ALLOC LOAD READONLY DATA HAS_CONTENTS
0x00400460->0x004004c0 at 0x00000460: .rela.plt ALLOC LOAD READONLY DATA HAS_CONTENTS
0x004004c0->0x004004d7 at 0x000004c0: .init ALLOC LOAD READONLY CODE HAS_CONTENTS
0x004004e0->0x00400530 at 0x000004e0: .plt ALLOC LOAD READONLY CODE HAS_CONTENTS
0x00400530->0x00400802 at 0x00000530: .text ALLOC LOAD READONLY CODE HAS_CONTENTS
0x00400804->0x0040080d at 0x00000804: .fini ALLOC LOAD READONLY CODE HAS_CONTENTS
0x00400810->0x0040084e at 0x00000810: .rodata ALLOC LOAD READONLY DATA HAS_CONTENTS
0x00400850->0x004008c4 at 0x00000850: .eh_frame_hdr ALLOC LOAD READONLY DATA HAS_CONTENTS
0x004008c8->0x00400ab8 at 0x000008c8: .eh_frame ALLOC LOAD READONLY DATA HAS_CONTENTS
0x00600e00->0x00600e08 at 0x00000e00: .init_array ALLOC LOAD DATA HAS_CONTENTS
0x00600e08->0x00600e10 at 0x00000e08: .fini_array ALLOC LOAD DATA HAS_CONTENTS
0x00600e10->0x00600ff0 at 0x00000e10: .dynamic ALLOC LOAD DATA HAS_CONTENTS
0x00600ff0->0x00601000 at 0x00000ff0: .got ALLOC LOAD DATA HAS_CONTENTS
0x00601000->0x00601038 at 0x00001000: .got.plt ALLOC LOAD DATA HAS_CONTENTS
0x00601038->0x0060103c at 0x00001038: .data ALLOC LOAD DATA HAS_CONTENTS
0x00601040->0x006012c8 at 0x0000103c: .bss ALLOC
0x00000000->0x00000000 at 0x00000000: *COM* IS_COMMON
0x00000000->0x00000000 at 0x00000000: *UND*
0x00000000->0x00000000 at 0x00000000: *ABS*
0x00000000->0x00000000 at 0x00000000: *IND*
(gdb)
We lost the section index numbers, but more importantly, we lost the
information about the .debug* sections. We also gained entries for
the "fake" sections *COM*, *UND*, *ABS*, and *IND*.
I noticed this when running:
make check-gdb RUNTESTFLAGS="--target_board=cc-with-gdb-index gdb.base/maint.exp"
As this test relies on looking in the 'maint info sections' output to
see if we have a .debug_names or .gdb_index section, and these are
debug sections so they no longer show up in the 'main info sections'
output, the gdb.base/maint.exp test fails.
This commit restores the old behaviour while keeping the important
change that the above commit introduced, the addresses printed for
sections are the relocated addresses where appropriate. The above
commit mentions using this test:
make check-gdb RUNTESTFLAGS="CFLAGS_FOR_TARGET='-pie' gdb.base/compare-sections.exp"
And this still passes after this commit.
The output for 'maint info sections' now looks like this:
(gdb) maintenance info sections
Exec file:
`/home/andrew/projects/binutils-gdb/build/gdb/testsuite/outputs/gdb.base/maint/maint',
file type elf64-x86-64.
[0] 0x00400238->0x00400254 at 0x00000238: .interp ALLOC LOAD READONLY DATA HAS_CONTENTS
[1] 0x00400254->0x00400274 at 0x00000254: .note.ABI-tag ALLOC LOAD READONLY DATA HAS_CONTENTS
[2] 0x00400274->0x00400298 at 0x00000274: .note.gnu.build-id ALLOC LOAD READONLY DATA HAS_CONTENTS
[3] 0x00400298->0x004002bc at 0x00000298: .gnu.hash ALLOC LOAD READONLY DATA HAS_CONTENTS
[4] 0x004002c0->0x00400380 at 0x000002c0: .dynsym ALLOC LOAD READONLY DATA HAS_CONTENTS
[5] 0x00400380->0x004003e3 at 0x00000380: .dynstr ALLOC LOAD READONLY DATA HAS_CONTENTS
[6] 0x004003e4->0x004003f4 at 0x000003e4: .gnu.version ALLOC LOAD READONLY DATA HAS_CONTENTS
[7] 0x004003f8->0x00400418 at 0x000003f8: .gnu.version_r ALLOC LOAD READONLY DATA HAS_CONTENTS
[8] 0x00400418->0x00400460 at 0x00000418: .rela.dyn ALLOC LOAD READONLY DATA HAS_CONTENTS
[9] 0x00400460->0x004004c0 at 0x00000460: .rela.plt ALLOC LOAD READONLY DATA HAS_CONTENTS
[10] 0x004004c0->0x004004d7 at 0x000004c0: .init ALLOC LOAD READONLY CODE HAS_CONTENTS
[11] 0x004004e0->0x00400530 at 0x000004e0: .plt ALLOC LOAD READONLY CODE HAS_CONTENTS
[12] 0x00400530->0x00400802 at 0x00000530: .text ALLOC LOAD READONLY CODE HAS_CONTENTS
[13] 0x00400804->0x0040080d at 0x00000804: .fini ALLOC LOAD READONLY CODE HAS_CONTENTS
[14] 0x00400810->0x0040084e at 0x00000810: .rodata ALLOC LOAD READONLY DATA HAS_CONTENTS
[15] 0x00400850->0x004008c4 at 0x00000850: .eh_frame_hdr ALLOC LOAD READONLY DATA HAS_CONTENTS
[16] 0x004008c8->0x00400ab8 at 0x000008c8: .eh_frame ALLOC LOAD READONLY DATA HAS_CONTENTS
[17] 0x00600e00->0x00600e08 at 0x00000e00: .init_array ALLOC LOAD DATA HAS_CONTENTS
[18] 0x00600e08->0x00600e10 at 0x00000e08: .fini_array ALLOC LOAD DATA HAS_CONTENTS
[19] 0x00600e10->0x00600ff0 at 0x00000e10: .dynamic ALLOC LOAD DATA HAS_CONTENTS
[20] 0x00600ff0->0x00601000 at 0x00000ff0: .got ALLOC LOAD DATA HAS_CONTENTS
[21] 0x00601000->0x00601038 at 0x00001000: .got.plt ALLOC LOAD DATA HAS_CONTENTS
[22] 0x00601038->0x0060103c at 0x00001038: .data ALLOC LOAD DATA HAS_CONTENTS
[23] 0x00601040->0x006012c8 at 0x0000103c: .bss ALLOC
[24] 0x00000000->0x0000002c at 0x0000103c: .comment READONLY HAS_CONTENTS
[25] 0x00000000->0x00000060 at 0x00001068: .debug_aranges READONLY HAS_CONTENTS
[26] 0x00000000->0x0000061b at 0x000010c8: .debug_info READONLY HAS_CONTENTS
[27] 0x00000000->0x00000264 at 0x000016e3: .debug_abbrev READONLY HAS_CONTENTS
[28] 0x00000000->0x000001e6 at 0x00001947: .debug_line READONLY HAS_CONTENTS
[29] 0x00000000->0x00000487 at 0x00001b2d: .debug_str READONLY HAS_CONTENTS
(gdb)
This is basically as it was before, except that the index numbers are
now padded so the section information all lines up.
When GDB has relocated a section then the relocated addresses will be
printed, otherwise the non-relocated addresses from the bfd will be
printed.
I've added a test to gdb.base/maint.exp to do some basic validation of
the output format.
gdb/ChangeLog:
* maint.c: Add 'cmath' include.
(struct maint_print_section_data): New structure.
(print_section_index): New function.
(print_bfd_section_info): Add header comment, small whitespace
cleanup, and update to call new print_section_index function.
(print_objfile_section_info): Likewise.
(maint_obj_section_from_bfd_section): New function.
(print_bfd_section_info_maybe_relocated): New function.
(maintenance_info_sections): Add header comment, always use
bfd_map_over_sections instead of ALL_OBJFILE_OSECTIONS.
gdb/testsuite/ChangeLog:
* gdb.base/maint.exp: Add test for 'maint info sections'.
The test-case gdb.base/store.exp fails with gcc 7.4.0:
...
nr of unexpected failures 27
...
The first FAIL:
...
110 l = add_float (l, r);
(gdb) PASS: gdb.base/store.exp: continue to wack_float
print l
$21 = <optimized out>
FAIL: gdb.base/store.exp: var float l; print old l, expecting -1
...
relates to this bit in the test-case (compiled at -O0):
...
106 float
107 wack_float (register float u, register float v)
108 {
109 register float l = u, r = v;
110 l = add_float (l, r);
111 return l + r;
112 }
...
and it expects to be able to read and modify variable l before executing line
110, but it already fails to read the value, because l has no DW_AT_location
attribute in the debug info.
Variable l is declared with the register keyword, and GCC implements the
register keyword at -O0 like so:
...
the compiler allocates distinct stack memory for all variables that do not
have the register storage-class specifier; if register is specified, the
variable may have a shorter lifespan than the code would indicate and may
never be placed in memory.
...
The fact that l has no DW_AT_location attribute, matches with the documented
"variable may have a shorter lifespan that code would indicate", (though it
is the most extreme case of it) so the gcc behaviour is valid. We can of
course improve gcc to generate better debuginfo (filed gcc PR91611), but
this not a wrong-debug problem.
[ The test-case passes with gcc 4.2.1, but for the failing test discussed
above, it passes simply because it doesn't store l in a register. ]
With the debug info missing for l, reading and setting l is unsupported, so
fix the FAIL by marking the test UNSUPPORTED instead.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-09-12 Tom de Vries <tdevries@suse.de>
* gdb.base/store.exp: Allow register variables to be optimized out at
-O0.
With this patch, we e.g. get:
[Switching to task 2 "task_list(1)"]
[Current task is 2 "task_list(1)"]
instead of
[Switching to task 2]
[Current task is 2]
The logic to produce the taskno optionally followed
by the task name has been factorized in the task_to_str function.
Task names are output between double quotes in the new messages,
similarly to what GDB does for thread names.
However, no quotes are put around task names in 'info tasks' Name column.
This was discussed with Tom, that preferred no quotes there, while I
was more in favour of visual consistency.
I discussed with a few more users, which led to (exactly) 50% preferring
quotes and 50% preferring no quotes :).
To arrive to the decision to remove the quotes, the following "killing args"
were used:
* To have quotes or to not have quotes, that is the question; yes
but not *THE* question :).
* If there is not a clear majority that prefers quotes, better to
not disturb the existing user basis for a (somewhat) irrelevant
aspect.
* The opinion of the reviewer has more weight.
So, compared to the previous version, this version remotes the quotes
in 'info tasks'.
It improves the alignement of 'info tasks' output.
With this patch, we get:
(gdb) info task
ID TID P-ID Pri State Name
* 1 555555759030 48 Runnable main_task
2 555555759e30 1 48 Selective Wait mit
(gdb)
instead of
(gdb) info task
ID TID P-ID Pri State Name
* 1 555555759030 48 Runnable main_task
2 555555759e30 1 48 Selective Wait mit
(gdb)
(e.g. the first one properly shows parent and priority under the
correct header).
This is version 4 of the 'task name' patch.
Compared to version 3, the changes are:
output task names between quotes but not in 'info tasks'
gdb/ChangeLog
2019-09-12 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* NEWS: Announce that Ada task names are now shown at more places,
and between quotes (except in info task output).
* gdb/ada-tasks.c (task_to_str): New function.
(display_current_task_id): Call task_to_str.
(task_command_1): Likewise.
(print_ada_task_info): In non-mi mode, Properly align headers and data
when task-id length is > 9 (9 is the default for a 32 bits CORE_ADDR).
gdb/doc/ChangeLog
2019-09-12 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* gdb.texinfo (Ada Tasks): Tell the task name is printed, update
examples.
gdb/testsuite/ChangeLog
2019-09-12 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* gdb.ada/rdv_wait.exp: Update to new task names.
* gdb.base/task_switch_in_core.exp: Likewise.
* gdb.base/info_sources_base.c: Likewise.
This adds Ada support to the cc-with-tweaks.exp board file, so that we
can test Ada this way. The cc-with-tweaks.sh script already works
reasonably well as a wrapper for gnatmake.
gdb/testsuite/ChangeLog
2019-09-10 Tom Tromey <tromey@adacore.com>
* boards/cc-with-tweaks.exp: Set GNATMAKE_FOR_TARGET.
An internal Ada test case showed that the .debug_names code does not
compute the same list of file names as the partial symbol reader. In
particular, the partial symbol reader uses the DW_AT_name of the CU:
/* Allocate a new partial symbol table structure. */
filename = dwarf2_string_attr (comp_unit_die, DW_AT_name, cu);
if (filename == NULL)
filename = "";
pst = create_partial_symtab (per_cu, filename);
This patch changes the .debug_names reader to follow.
gdb/ChangeLog
2019-09-10 Tom Tromey <tromey@adacore.com>
* dwarf2read.c (dw2_get_file_names_reader): Add the
CU's file name to the results.
gdb/testsuite/ChangeLog
2019-09-10 Tom Tromey <tromey@adacore.com>
* gdb.ada/dgopt.exp: New file.
* gdb.ada/dgopt/x.adb: New file.
If a TUI window has a long title, it can overflow the title line.
This changes the TUI to use just the tail part of the title in this
case.
gdb/ChangeLog
2019-09-08 Tom Tromey <tom@tromey.com>
* tui/tui-wingeneral.c (box_win): Truncate long window titles.
gdb/testsuite/ChangeLog
2019-09-08 Tom Tromey <tom@tromey.com>
* gdb.tui/resize.exp: Remove setup_xfail.
* gdb.tui/regs.exp: Remove setup_xfail.
* gdb.tui/basic.exp: Remove setup_xfail.
In gdb.base/ui-redirect.exp, the "save breakpoint" command is used to write
the current breakpoints to a file, but the actual output is not verified.
Consequently, the test has regressed in that the "print 1" command associated
with a breakpoint on main is removed by a subsequent runto_main, which first
deletes all breakpoints:
...
(gdb) break main
Breakpoint 1 at 0x4004d7: file start.c, line 34.
(gdb) commands
Type commands for breakpoint(s) 1, one per line.
End with a line saying just "end".
> PASS: gdb.base/ui-redirect.exp: commands
print 1
> PASS: gdb.base/ui-redirect.exp: print 1
end
(gdb) PASS: gdb.base/ui-redirect.exp: end
delete breakpoints
Delete all breakpoints? (y or n) y
...
and consequently the "save breakpoint" output is missing the breakpoint
command for main:
...
break main
- commands
- print 1
- end
break foo
break bar
...
Fix this by replacing "gdb_breakpoint main" with runto_main, and verifying the
"save breakpoints" output.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-09-05 Tom de Vries <tdevries@suse.de>
* lib/gdb.exp (cmp_file_string): New proc.
* gdb.base/ui-redirect.exp: Replace "gdb_breakpoint main" with
runto_main. Verify save breakpoints output.
Once the executable is started, info variables can show thousands
of variables belonging to glibc (see below).
This long list of variables then causes the test to fail, due
to expect's buffer overflow:
Running /bd/home/philippe/gdb/git/build_binutils-gdb/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/info-var.exp ...
ERROR: internal buffer is full.
ERROR: internal buffer is full.
ERROR: internal buffer is full.
Fix this by testing 'info variables' without running the executable.
gdb ./info-var
...
Reading symbols from ./info-var...
(gdb) |info variables|wc
27 54 971
(gdb) start
Temporary breakpoint 1 at 0x1129: file /bd/home/philippe/gdb/git/build_binutils-gdb/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/info-var-f1.c, line 23.
Starting program: /bd/home/philippe/gdb/git/build_binutils-gdb/gdb/testsuite/outputs/gdb.base/info-var/info-var
Temporary breakpoint 1, main ()
at /bd/home/philippe/gdb/git/build_binutils-gdb/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/info-var-f1.c:23
23 return global_var + get_offset() + f1_var;
(gdb) |info variables|wc
4334 14581 130738
(gdb)
gdb/testsuite/ChangeLog
2019-09-04 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* gdb.base/info-var.exp: Test info variables without running
to main, to avoid expect's buffer overflow.
In Ada, the programmer can request that a range type with a non-zero
base be stored in the minimal number of bits required for the range.
This is done by biasing the values; so, for example, a range of -7..-4
may be stored as two bits with a bias of -7.
This patch implements this for gdb. It is done by adding a bias to
struct range_bounds and then adjusting a few spots to handle this.
The test case is written to use -fgnat-encodings=minimal, but a future
compiler patch will change the compiler to emit DW_AT_GNU_bias with
-fgnat-encodings=gdb. It seemed good to get the gdb patch in first.
Tested on x86-64 Fedora 29; plus a variety of targets using AdaCore's
internal test suite.
gdb/ChangeLog
2019-09-03 Tom Tromey <tromey@adacore.com>
* ada-valprint.c (ada_val_print_num): Don't recurse for range
types.
(has_negatives): Unbias a range type bound.
* dwarf2read.c (read_subrange_type): Handle DW_AT_GNU_bias.
* gdbtypes.c (operator==): Handle new field.
(create_range_type): Add "bias" parameter.
(create_static_range_type, resolve_dynamic_range): Update.
* gdbtypes.h (struct range_bounds) <bias>: New member.
(create_range_type): Add bias parameter.
* printcmd.c (print_scalar_formatted): Unbias range types.
* value.c (unpack_long): Unbias range types.
(pack_long): Bias range types.
gdb/testsuite/ChangeLog
2019-09-03 Tom Tromey <tromey@adacore.com>
* gdb.ada/bias.exp: New file.
* gdb.ada/bias/bias.adb: New file.
* gdb.ada/print_chars.exp: Add regression test.
* gdb.ada/print_chars/foo.adb (My_Character): New type.
(MC): New variable.
This testcase was originally for PR gdb/15415, a problem with the
"run" command expanding symlinks in the name of the program being run.
It does not correctly distinguish between files on build, host, and
target, and it is not clear if it would be testing anything useful in
configurations where "run" is not being used.
2019-08-29 Sandra Loosemore <sandra@codesourcery.com>
* gdb.base/argv0-symlink.exp: Run only on native target
and local host.
The gdb.fortran/info-types.exp test-case passes with gcc 7 (though not on
openSUSE, due to the extra debug info) and fails with gcc 4.8 and gcc 8.
Fix the gdb_test regexp to fix all those cases.
gdb/testsuite/ChangeLog:
2019-08-29 Tom de Vries <tdevries@suse.de>
* gdb.fortran/info-types.exp: Fix gdb_test regexp to allow more
diverse debug info.
* lib/fortran.exp (fortran_int8): New proc, based on fortran_int4.
On openSUSE Leap 15.1, I get:
...
FAIL: gdb.base/info-var.exp: info variables
FAIL: gdb.base/info-var.exp: info variables -n
...
because the info variables command prints info also for init.c:
...
File init.c:^M
24: const int _IO_stdin_used;^M
...
while the regexps in the test-case only expect info for info-var-f1.c and
info-var-f2.c.
Fix this by extending the regexps.
Tested on x86_64-linux, both openSUSE Leap 15.1 and Fedora 30.
gdb/testsuite/ChangeLog:
2019-08-28 Tom de Vries <tdevries@suse.de>
* gdb.base/info-var.exp: Allow info variables to print info for files
other than info-var-f1.c and info-var-f2.c.
Currently the 'info types' command will return symbols that correspond
to Fortran modules. This is because the symbols are created with
domain MODULE_DOMAIN and address_class LOC_TYPEDEF. The address_class
LOC_TYPEDEF is the same address_class used for type symbols which is
why the modules show up when listing types.
This commit explicitly prevents symbols in the MODULE_DOMAIN from
appearing when we search for symbols in the TYPES_DOMAIN, this
prevents the Fortran module symbols from appearing in the output of
'info types'.
gdb/ChangeLog:
* symtab.c (search_symbols): Don't include MODULE_DOMAIN symbols
when searching for types.
gdb/testsuite/ChangeLog:
* gdb.fortran/info-types.exp: Add module.
* gdb.fortran/info-types.f90: Update expected results.
Implement an la_print_typedef method for Fortran, this allows 'info
types' to work for Fortran. The implementation is just copied from
ada_print_typedef (with the appropriate changes).
To support the testing of this patch I added a new proc,
fortran_character1, to lib/fortran.exp which returns a regexp to match
a 1-byte character type. The regexp returned is correct for current
versions of gFortran. All of the other regexp are guesses based on
all of the other support procs in lib/fortran.exp, I haven't tested
them myself.
gdb/ChangeLog:
* f-lang.c (f_language_defn): Use f_print_typedef.
* f-lang.h (f_print_typedef): Declare.
* f-typeprint.c (f_print_typedef): Define.
gdb/testsuite/ChangeLog:
* gdb.fortran/info-types.exp: New file.
* gdb.fortran/info-types.f90: New file.
* lib/fortran.exp (fortran_character1): New proc.
The 'info variables', its alias 'whereis', and 'info functions' all
include non-debug symbols in the output by default. The list of
non-debug symbols can sometimes be quite long, resulting in the
debug symbol based results being scrolled off the screen.
This commit adds a '-n' flag to all of the commands listed above that
excludes the non-debug symbols from the results, leaving just the
debug symbol based results.
gdb/ChangeLog:
* cli/cli-utils.c (info_print_options_defs): Delete.
(make_info_print_options_def_group): Delete.
(extract_info_print_options): Delete.
(info_print_command_completer): Delete.
(info_print_args_help): Add extra parameter, and optionally
include text about -n flag.
* cli/cli-utils.h (struct info_print_options): Delete.
(extract_info_print_options): Delete declaration.
(info_print_command_completer): Delete declaration.
(info_print_args_help): Add extra parameter, extend header
comment.
* python/python.c (gdbpy_rbreak): Pass additional parameter to
search_symbols.
* stack.c (struct info_print_options): New type.
(info_print_options_defs): New file scoped variable.
(make_info_print_options_def_group): New static function.
(info_print_command_completer): New static function.
(info_locals_command): Update to use new local functions.
(info_args_command): Likewise.
(_initialize_stack): Add extra parameter to calls to
info_print_args_help.
* symtab.c (search_symbols): Add extra parameter, use this to
possibly excluse non-debug symbols.
(symtab_symbol_info): Add extra parameter, which is passed on to
search_symbols.
(struct info_print_options): New type.
(info_print_options_defs): New file scoped variable.
(make_info_print_options_def_group): New static function.
(info_print_command_completer): New static function.
(info_variables_command): Update to use local functions, and pass
extra parameter through to symtab_symbol_info.
(info_functions_command): Likewise.
(info_types_command): Pass additional argument through to
symtab_symbol_info.
(rbreak_command): Pass extra argument to search_symbols.
(_initialize_symtab): Add extra arguments for calls to
info_print_args_help, and update help text for 'info variables',
'whereis', and 'info functions' commands.
* symtab.h (search_symbols): Add extra argument to declaration.
* NEWS: Mention new flags.
gdb/doc/ChangeLog:
* gdb.texinfo (Symbols): Add information about the -n flag to
"info variables" and "info functions".
gdb/testsuite/ChangeLog:
* gdb.base/info-fun.exp: Extend to test the -n flag for 'info
functions'. Reindent as needed.
* gdb.base/info-var-f1.c: New file.
* gdb.base/info-var-f2.c: New file.
* gdb.base/info-var.exp: New file.
* gdb.base/info-var.h: New file.
When using catch catch/rethrow/catch, a libstdcxx with SDT probes is required
for both the regexp argument, and the convenience variable $_exception (
https://sourceware.org/gdb/current/onlinedocs/gdb/Set-Catchpoints.html ).
Currently, when using these features with a libstdcxx without SDT probes, we
get the cryptic error message:
...
not stopped at a C++ exception catchpoint
...
Improve this by instead emitting the more helpful:
...
did not find exception probe (does libstdcxx have SDT probes?)
...
Tested on x86_64-linux.
gdb/ChangeLog:
2019-08-26 Tom de Vries <tdevries@suse.de>
PR c++/24852
* break-catch-throw.c (fetch_probe_arguments): Improve error mesage
when pc_probe.prob == NULL.
gdb/testsuite/ChangeLog:
2019-08-26 Tom de Vries <tdevries@suse.de>
PR c++/24852
* gdb.cp/no-libstdcxx-probe.exp: New test.
The tcl proc skip_libstdcxx_probe_tests currently returns 0 if the probe tests
need to be skipped, while tcl interprets 0 as false rather than true, which is
confusing.
Fix this by making skip_libstdcxx_probe_tests return 1 if the probe tests need
to be skipped.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-08-26 Tom de Vries <tdevries@suse.de>
* lib/gdb.exp (skip_libstdcxx_probe_tests_prompt): Return 1 if probe
* tests need to be skipped.
* gdb.cp/exceptprint.exp: Update call to skip_libstdcxx_probe_tests.
* gdb.mi/mi-catch-cpp-exceptions.exp: Update call to
mi_skip_libstdcxx_probe_tests.
The way unrecognized escape sequences are handled has changed in
Python 3.8: users now see a SyntaxWarning message, which will
eventually become a SyntaxError in future versions of Python:
(gdb) source /blabla/gdb.python/py-xmethods/py-xmethods.py
/blabla/gdb.python/py-xmethods/py-xmethods.py:204: SyntaxWarning: invalid escape seque
nce \+
'operator\+',
/blabla/gdb.python/py-xmethods/py-xmethods.py:211: SyntaxWarning: invalid escape seque
nce \+
'operator\+\+',
One of our testcases, gdb.python/py-xmethods.exp, contains strings in
the form of "operator\+". This is not recognized by Python, but is
still needed by the testsuite to work properly. The solution is
simple: we just have to make sure these strings are marked as
raw (i.e, r""). This is what this patch does. I took the opportunity
to also convert other strings to raw, which, in two cases, allowed the
removal of an extra backslash.
I tested this using Python 3.7 and Python 3.8, and everything works
fine.
I think I could push this as obvious, but decided to send it to
gdb-patches just in case.
gdb/testsuite/ChangeLog:
2019-08-26 Sergio Durigan Junior <sergiodj@redhat.com>
* gdb.python/py-xmethods.exp: Use raw strings when passing
arguments to SimpleXMethodMatcher.
This racy fail message, reported in PR24929:
...
FAIL: gdb.multi/multi-term-settings.exp: inf1_how=attach: inf2_how=attach: \
stop with control-c
...
does not make clear which gdb_test fails here:
...
if {$expect_ttou} {
gdb_test "" "Quit" "stop with control-c"
} else {
gdb_test "" "received signal SIGINT.*" "stop with control-c"
}
...
Fix this by making the gdb_test message argument more informative.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-08-22 Tom de Vries <tdevries@suse.de>
* gdb.multi/multi-term-settings.exp (coretest): Make gdb_test messages
more informative.
Running 'with' without arguments crashes GDB. This fixes it.
gdb/ChangeLog:
2019-08-21 Bogdan Harjoc <harjoc@gmail.com>
* cli/cli-cmds.c (with_command_1): Error out if no arguments.
gdb/testsuite/ChangeLog:
2019-08-21 Pedro Alves <palves@redhat.com>
* gdb.base/with.exp: Test "with" with no arguments.
The test-case gdb-caching-proc.exp tests each gdb_caching_proc in
gdb/testsuite/lib/*.exp. However, the order of .exp file being tested can
change from run to run, because of using glob.
Fix this by sorting the glob result.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-08-21 Tom de Vries <tdevries@suse.de>
* gdb.base/gdb-caching-proc.exp: Sort files.
When running a pascal test with the stabs target board:
...
$ test=gdb.pascal/case-insensitive-symbols.exp
$ cd build/gdb/testsuite
$ make check RUNTESTFLAGS="$test --target_board=stabs"
...
we get:
...
nr of untested testcases 1
nr of unsupported tests 1
...
due to:
...
Error: Illegal parameter: -gstabs+^M
Error: /usr/bin/ppcx64 returned an error exitcode^M
...
OTOH, when running the same pascal test without the stabs target board:
...
$ make check RUNTESTFLAGS="$test"
...
we get:
...
nr of expected passes 20
...
But when subsequently again running with the stabs target board:
...
$ make check RUNTESTFLAGS="$test --target_board=stabs"
...
we now get:
...
nr of expected passes 20
...
The problem is that gdb_compile_pascal determines success based on existence
of the exec after compilation:
...
if ![file exists $destfile] {
unsupported "Pascal compilation failed: $result"
return "Pascal compilation failed."
}
...
without removing the exec before compilation, which allows a stale exec to
make it seem as if compilation has succeeded.
Fix this by removing the stale exec before compilation.
gdb/testsuite/ChangeLog:
2019-08-20 Tom de Vries <tdevries@suse.de>
* lib/pascal.exp (gdb_compile_pascal): Remove $destfile before
compilation.
When running gdb.base/compare-sections.exp with target board -fPIE/-pie, we
get:
...
FAIL: gdb.base/compare-sections.exp: after run to main: compare-sections -r
...
The test expects the read-only sections to have the same contents as in the
file:
...
# Assume startup code doesn't change read-only sections.
compare_sections "-r"
...
but that's not the case for PIE executables.
Fix this by allowing mismatched read-only sections for PIE executables.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-08-16 Tom de Vries <tdevries@suse.de>
* gdb.base/compare-sections.exp ("after run to main"): Allow
mismatched read-only sections for PIE executables.
The TUI execution info window is unusual in that it is always linked
to a source or disassembly window. Even updates of its content are
handled by the source window, so it really has no life of its own.
This patch removes this window entirely and puts its functionality
directly into the source window. This simplifies the code somewhat.
This is a user-visible change, because now the box around the source
(or disassembly) window encloses the execution info as well. I
consider this an improvement as well, though.
Note that this patch caused ncurses to start emitting the "CSI Z"
sequence, so I've added this to the test suite terminal
implementation.
gdb/ChangeLog
2019-08-16 Tom Tromey <tom@tromey.com>
* tui/tui.h (enum tui_win_type) <EXEC_INFO_WIN>: Remove.
* tui/tui-winsource.h (struct tui_exec_info_window): Remove.
(struct tui_source_window_base) <make_visible, refresh_window,
resize>: Remove methods.
<execution_info>: Remove field.
* tui/tui-winsource.c (tui_source_window_base::do_erase_source_content)
(tui_show_source_line, tui_source_window_base)
(~tui_source_window_base): Update.
(tui_source_window_base::resize)
(tui_source_window_base::make_visible)
(tui_source_window_base::refresh_window): Remove.
(tui_source_window_base::update_exec_info): Update.
* tui/tui-source.c (tui_source_window::set_contents): Update.
* tui/tui-disasm.c (tui_disasm_window::set_contents): Update.
gdb/testsuite/ChangeLog
2019-08-16 Tom Tromey <tom@tromey.com>
* lib/tuiterm.exp (_csi_Z): New proc.
* gdb.tui/basic.exp: Update window positions.
* gdb.tui/empty.exp: Update window positions.
This patch fixes a paste-o that was introduced in commit
c8ad9b9a31. Previously the regexp for
the "examine 3 bytes backward from ${address_zero}" test correctly
matched 3 "${byte}" patterns, but in that commit the 6-byte regexp
from the previous test was mistakenly repeated here instead.
2019-08-15 Sandra Loosemore <sandra@codesourcery.com>
gdb/testsuite/
* gdb.base/examine-backward.exp: Correct regexp for
"examine 3 bytes backward from ${address_zero}".
The TUI currently has two different ways to resize a window: the
resize method, and the methods make_invisible_and_set_new_height and
make_visible_with_new_height.
There's no deep reason to have two different ways to resize a window,
so this patch unifies them, leaving just the "resize" method.
This also changes the locator to be handled more like an ordinary
window and less like an adjunct of the associated source window.
gdb/ChangeLog
2019-08-15 Tom Tromey <tom@tromey.com>
* tui/tui-io.c (tui_puts_internal): Check TUI_CMD_WIN before
calling update_cmdwin_start_line.
* tui/tui-winsource.h (struct tui_source_window_base)
<do_make_visible_with_new_height, set_new_height>: Don't declare.
<rerender>: Declare.
* tui/tui-winsource.c (tui_source_window_base::update_tab_width):
Call rerender.
(tui_source_window_base::set_new_height): Remove.
(tui_source_window_base::rerender): Rename from
do_make_visible_with_new_height.
* tui/tui-win.c (tui_resize_all, tui_adjust_win_heights): Use
resize method.
(tui_win_info::make_invisible_and_set_new_height)
(tui_win_info::make_visible_with_new_height): Remove.
* tui/tui-stack.h (struct tui_locator_window) <rerender>:
Declare.
* tui/tui-stack.c (tui_locator_window::rerender): New method.
* tui/tui-regs.h (struct tui_data_window) <set_new_height,
do_make_visible_with_new_height>: Don't declare.
<rerender>: Declare.
* tui/tui-regs.c (tui_data_window::rerender): Rename from
set_new_height.
(tui_data_window::do_make_visible_with_new_height): Remove.
* tui/tui-layout.c (show_source_disasm_command, show_data): Don't
call tui_show_locator_content.
(tui_gen_win_info::resize): Call rerender.
(show_source_or_disasm_and_command): Don't call
tui_show_locator_content.
* tui/tui-data.h (struct tui_gen_win_info) <rerender>: New
method.
(struct tui_win_info) <rerender>: Declare.
<set_new_height, make_invisible_and_set_new_height,
make_visible_with_new_height>: Don't declare.
* tui/tui-data.c (tui_win_list::rerender): New method.
* tui/tui-command.h (struct tui_cmd_window)
<do_make_visible_with_new_height>: Don't declare.
* tui/tui-command.c
(tui_cmd_window::do_make_visible_with_new_height): Remove.
gdb/testsuite/ChangeLog
2019-08-15 Tom Tromey <tom@tromey.com>
* gdb.tui/empty.exp: Enable resizing tests.
gnat encodes character enumeration literals using a few different
schemes. The gnat compiler documented the "QU" and "QW" encodings,
but failed to document that a simpler encoding was used for certain
characters.
This patch updates gdb to handle this simple Q encoding. Note that
wide character literals are still not handled.
gdb/ChangeLog
2019-08-15 Tom Tromey <tromey@adacore.com>
* ada-exp.y (convert_char_literal): Handle "Q%c" encoding.
* ada-lang.c (ada_enum_name): Likewise.
gdb/testsuite/ChangeLog
2019-08-15 Tom Tromey <tromey@adacore.com>
* gdb.ada/char_enum.exp: Add regression tests.
* gdb.ada/char_enum/foo.adb (Char_Enum_Type): Use '_'
and '0'.
(Char, Gchar): Update.
* gdb.ada/char_enum/pck.ads (Global_Enum_Type): Use '+'.
I could not tell if GdbSetPythonDirectory is internal or not because
I could not find any references to it, so I left it as-is.
Tested by running the testsuite on gdb.python/*.exp; everything still
passes.
2019-08-15 Christian Biesinger <cbiesinger@google.com>
* python/lib/gdb/__init__.py (GdbOutputFile): Rename to have a
leading underscore.
(GdbOutputErrorFile): Likewise.
(global scope): Adjust constructor calls to GdbOutput{,Error}File
accordingly.
(execute_unwinders): Rename to have a leading underscore.
(auto_load_packages): Likewise.
(global scope): Adjust call to auto_load_packages accordingly.
(GdbSetPythonDirectory): Likewise.
* python/py-unwind.c (pyuw_sniffer): Call _execute_unwinders
instead of execute_unwinders.
gdb/testsuite/ChangeLog:
2019-08-15 Christian Biesinger <cbiesinger@google.com>
* gdb.python/python.exp: Expect a leading underscore on
GdbOutput{,Error}File.
This test has many hardwired assumptions that pathnames on build and
host are the same, and that POSIX pathname syntax is used. This
results in dozens of failures on a remote Windows host. Fixing these
assumptions would involve nontrivial rewrites; meanwhile, let's make
the test results reflect the reality that this testcase isn't supported
on remote host.
2019-08-15 Sandra Loosemore <sandra@codesourcery.com>
gdb/testsuite/
* gdb.dwarf2/dw2-dir-file-name.exp: Skip on remote or
Windows host.
This group of tests assume that the gdb "shell" command launches a
POSIX-compliant shell supporting the PPID environment variable, which
is used to get gdb's pid for killing it from a remote_exec shell. But
on Windows host "shell" launches cmd.exe, which doesn't have an
equivalent query.
2019-08-15 Sandra Loosemore <sandra@codesourcery.com>
gdb/testsuite/
* gdb.base/batch-preserve-term-settings.exp
(test_terminal_settings_preserved_after_sigterm): Skip on Windows.
Dejagnu produces an objdir like /c/, but GDB expects something like c:/.
So fix it up in lib/gdb.exp.
gdb/testsuite/ChangeLog:
2019-08-14 Christian Biesinger <cbiesinger@google.com>
* lib/gdb.exp: When running on a mingw target, replace
/x/ with x:/.
When saving registers to the stack at the start of a function, not all state
needs to be saved. For example, only the first 64bits of float registers need
saving. However, a program may choose to store extra state if it wishes,
there is nothing preventing it doing so.
The aarch64_analyze_prologue will error if it detects extra state being
stored. Relex this restriction.
Tested via aarch64-prologue test.
gdb/ChangeLog:
* aarch64-tdep.c (aarch64_analyze_prologue): Allow any valid
register sizes.
gdb/testsuite/ChangeLog:
* gdb.arch/aarch64-prologue.c: New test.
* gdb.arch/aarch64-prologue.exp: New file.
With gdb.gdb/selftest.exp, we get:
...
(xgdb) PASS: gdb.gdb/selftest.exp: send SIGINT signal to child process
^M
Thread 1 "xgdb" received signal SIGINT, Interrupt.^M
0x00007ffff5bf01db in poll () from /lib64/libc.so.6^M
(gdb) FAIL: gdb.gdb/selftest.exp: send ^C to child process again
...
The failure is due to gdb printing 'Thread 1 "xgdb" received signal SIGINT',
but the regexp in the test-case expecting 'Program received signal SIGINT'.
Fix this by updating the regexp, similar to how that is done earlier in the
test-case.
gdb/testsuite/ChangeLog:
2019-08-13 Tom de Vries <tdevries@suse.de>
* gdb.gdb/selftest.exp (send ^C to child process again): Accept also
Thread.
This patch fixes several test ERRORs and FAILs seen from running
gdb.python tests on a remote Windows host. The problems fixed
generally fall into these categories:
- Failure to copy the .py script to the host.
- Confusion between build and host pathnames.
- Assuming pathnames printed on the host include "/" as a directory
separator.
- Tests that need to be conditionally disabled due to missing features
on the host, etc.
2019-08-13 Sandra Loosemore <sandra@codesourcery.com>
gdb/testsuite/
* gdb.python/py-completion.exp: Download the .py file to the host
and use its host pathname. Conditionalize tests that use
tab completion and manipulate files on the build machine.
* gdb.python/py-events.exp: Download the .py file to the host
and use its host pathname.
* gdb.python/py-evsignal.exp: Likewise.
* gdb.python/py-evthreads.exp: Likewise.
* gdb.python/py-framefilter-invalidarg.exp: Match Windows
pathname syntax.
* gdb.python/py-framefilter.exp: Download the .py file to the right
place on the host. Match Windows pathname syntax.
* gdb.python/py-mi-var-info-path-expression.exp: Download the
.py file to the host and use its host pathname.
* gdb.python/py-objfile-script.exp: Match Windows pathname syntax.
* gdb.python/py-objfile.exp: Expect a host pathname, not a
build pathname. Skip symlink test on Windows host. Add missing
newline at end of file.
* gdb.python/py-pp-maint.exp: Download the .py file to the host
and use its host pathname.
* gdb.python/py-pp-registration.exp: Match Windows pathname syntax.
* gdb.python/py-section-script.exp: Use host location of binfile
on safe-path. Use correct path separator on Windows host.
Reorder alternatives in gdb_test_multiple to prevent matching
the wrong alternative on success.
* gdb.python/py-symtab.exp: Match Windows pathname syntax.
After the sync there is one testsuite regression, the test
"signal SIGINT" in gdb.gdb/selftest.exp which now FAILs. Previously,
the readline 6.2 SIGINT handler would temporarily reinstall the
underlying application's SIGINT handler and immediately re-raise SIGINT
so that the orginal handler gets invoked. But now (since readline 6.3)
its SIGINT handler does not re-raise SIGINT or directly invoke the
original handler; it now sets a flag marking that SIGINT was raised, and
waits until readline explicitly has control to call the application's
SIGINT handler. Anyway, because SIGINT is no longer re-raised from
within readline's SIGINT handler, doing "signal SIGINT" with a stopped
inferior gdb process will no longer resume and then immediately stop the
process (since there is no 2nd SIGINT to immediately catch). Instead,
the inferior gdb process will now just print "Quit" and continue to run.
So with this commit, this particular test case is adjusted to reflect
this change in behavior (we now have to send a 2nd SIGINT manually to
stop it).
gdb/testsuite/ChangeLog
2019-08-12 Patrick Palka <patrick@parcs.ath.cx>
* gdb.gdb/selftest.exp (test_with_self): Update test to now
expect the GDB inferior to no longer immediately stop after
being resumed with "signal SIGINT".
With gdb.tui/basic.exp and check-read1, we run into (using -v for
verbose log):
...
^[[0+++ _csi_0 <<<>>>
ERROR: (DejaGnu) proc "_csi_0" does not exist.
...
In contrast, without check-read1, we have:
...
^[[0;10m<SNIP>+++ _csi_m <<<0;10>>>
...
The problem is that this regexp in _accept:
...
-re "^\x1b\\\[(\[0-9;\]*)(\[0-9a-zA-Z@\])" {
...
while matching the longer sequence '^[' '[' '0' ';' '1' '0' 'm', also matches
the shorter sequence '^[' '[' '0'.
The regexp attempts to match a CSI (Control Sequence Introducer) sequence, and
the final byte of such a sequence cannot be a digit.
Fix the regexp accordingly:
...
- -re "^\x1b\\\[(\[0-9;\]*)(\[0-9a-zA-Z@\])" {
+ -re "^\x1b\\\[(\[0-9;\]*)(\[a-zA-Z@\])" {
...
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-08-08 Tom de Vries <tdevries@suse.de>
PR testsuite/24862
* lib/tuiterm.exp (_accept): Fix CSI regexp.
With this patch, the help docs now respect 2 invariants:
* The first line of a command help is terminated by a '.' character.
* The last character of a command help is not a newline character.
Note that the changes for the last invariant were done by Tom, as part of :
[PATCH] Remove trailing newlines from help text
https://sourceware.org/ml/gdb-patches/2019-06/msg00050.html
but some occurrences have been re-introduced since then.
Some help docs had to be rephrased/restructured to respect the above
invariants.
Before this patch, print_doc_line was printing the first line
of a command help documentation, but stopping at the first '.'
or ',' character.
This was giving inconsistent results :
* The first line of command helps was sometimes '.' terminated,
sometimes not.
* The first line of command helps was not always designed to be
readable/understandable/unambiguous when stopping at the first
'.' or ',' character.
This e.g. created the following inconsistencies/problems:
< catch exception -- Catch Ada exceptions
< catch handlers -- Catch Ada exceptions
< catch syscall -- Catch system calls by their names
< down-silently -- Same as the `down' command
while the new help is:
> catch exception -- Catch Ada exceptions, when raised.
> catch handlers -- Catch Ada exceptions, when handled.
> catch syscall -- Catch system calls by their names, groups and/or numbers.
> down-silently -- Same as the `down' command, but does not print anything.
Also, the command help doc should not be terminated by a newline
character, but this was not respected by all commands.
The cli-option -OPT framework re-introduced some occurences.
So, the -OPT build help framework was changed to not output newlines at the
end of %OPTIONS% replacement.
This patch changes the help documentations to ensure the 2 invariants
given above.
It implied to slightly rephrase or restructure some help docs.
Based on the above invariants, print_doc_line (called by
'apropos' and 'help' commands to print the first line of a command
help) now outputs the full first line of a command help.
This all results in a lot of small changes in the produced help docs.
There are less code changes than changes in the help docs, as a lot
of docs are produced by some code (e.g. the remote packet usage settings).
gdb/ChangeLog
2019-08-07 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* cli/cli-decode.h (print_doc_line): Add for_value_prefix argument.
* cli/cli-decode.c (print_doc_line): Likewise. It now prints
the full first line, except when FOR_VALUE_PREFIX. In this case,
the trailing '.' is not output, and the first character is uppercased.
(print_help_for_command): Update call to print_doc_line.
(print_doc_of_command): Likewise.
* cli/cli-setshow.c (deprecated_show_value_hack): Likewise.
* cli/cli-option.c (append_indented_doc): Do not append newline.
(build_help_option): Append newline after first appended_indented_doc
only if a second call is done.
(build_help): Append 2 new lines before each option, except the first
one.
* compile/compile.c (_initialize_compile): Add new lines after
%OPTIONS%, when not at the end of the help.
Change help doc or code
producing the help doc to respect the invariants.
* maint-test-options.c (_initialize_maint_test_options): Likewise.
Also removed the new line after 'Options:', as all other commands
do not put an empty line between 'Options:' and the first option.
* printcmd.c (_initialize_printcmd): Likewise.
* stack.c (_initialize_stack): Likewise.
* interps.c (interpreter_exec_cmd): Fix "Usage:" line that was
incorrectly telling COMMAND is optional.
* ada-lang.c (_initialize_ada_language): Change help doc or code
producing the help doc to respect the invariants.
* ada-tasks.c (_initialize_ada_tasks): Likewise.
* breakpoint.c (_initialize_breakpoint): Likewise.
* cli/cli-cmds.c (_initialize_cli_cmds): Likewise.
* cli/cli-logging.c (_initialize_cli_logging): Likewise.
* cli/cli-setshow.c (_initialize_cli_setshow): Likewise.
* cli/cli-style.c (cli_style_option::add_setshow_commands,
_initialize_cli_style): Likewise.
* corelow.c (core_target_info): Likewise.
* dwarf-index-cache.c (_initialize_index_cache): Likewise.
* dwarf2read.c (_initialize_dwarf2_read): Likewise.
* filesystem.c (_initialize_filesystem): Likewise.
* frame.c (_initialize_frame): Likewise.
* gnu-nat.c (add_task_commands): Likewise.
* infcall.c (_initialize_infcall): Likewise.
* infcmd.c (_initialize_infcmd): Likewise.
* interps.c (_initialize_interpreter): Likewise.
* language.c (_initialize_language): Likewise.
* linux-fork.c (_initialize_linux_fork): Likewise.
* maint-test-settings.c (_initialize_maint_test_settings): Likewise.
* maint.c (_initialize_maint_cmds): Likewise.
* memattr.c (_initialize_mem): Likewise.
* printcmd.c (_initialize_printcmd): Likewise.
* python/lib/gdb/function/strfns.py (_MemEq, _StrLen, _StrEq,
_RegEx): Likewise.
* ravenscar-thread.c (_initialize_ravenscar): Likewise.
* record-btrace.c (_initialize_record_btrace): Likewise.
* record-full.c (_initialize_record_full): Likewise.
* record.c (_initialize_record): Likewise.
* regcache-dump.c (_initialize_regcache_dump): Likewise.
* regcache.c (_initialize_regcache): Likewise.
* remote.c (add_packet_config_cmd, init_remote_threadtests,
_initialize_remote): Likewise.
* ser-tcp.c (_initialize_ser_tcp): Likewise.
* serial.c (_initialize_serial): Likewise.
* skip.c (_initialize_step_skip): Likewise.
* source.c (_initialize_source): Likewise.
* stack.c (_initialize_stack): Likewise.
* symfile.c (_initialize_symfile): Likewise.
* symtab.c (_initialize_symtab): Likewise.
* target-descriptions.c (_initialize_target_descriptions): Likewise.
* top.c (init_main): Likewise.
* tracefile-tfile.c (tfile_target_info): Likewise.
* tracepoint.c (_initialize_tracepoint): Likewise.
* tui/tui-win.c (_initialize_tui_win): Likewise.
* utils.c (add_internal_problem_command): Likewise.
* valprint.c (value_print_option_defs): Likewise.
gdb/testsuite/ChangeLog
2019-08-07 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* gdb.base/style.exp: Update tests for help doc new invariants.
* gdb.base/help.exp: Likewise.
This adds more styling to the disassemble command. In particular,
addresses and function names in the disassembly are now styled.
This required fixing a small latent bug in set_output_style. This
function always passed NULL to emit_style_escape; but when writing to
a file other than gdb_stdout, it should emit the style escape
directly. (FWIW this is another argument for better integrating the
pager with ui_file and getting rid of this entire layer.)
gdb/ChangeLog
2019-08-06 Tom Tromey <tom@tromey.com>
* utils.c (set_output_style): Sometimes pass stream to
emit_style_escape.
* ui-out.h (class ui_out) <can_emit_style_escape>: Declare.
* record-btrace.c (btrace_insn_history): Update.
* mi/mi-out.h (class mi_ui_out) <can_emit_style_escape>: New
method.
* disasm.h (gdb_pretty_print_disassembler): Add uiout parameter.
Update initializers.
<m_uiout>: New field.
<m_di>: Move lower.
* disasm.c (gdb_pretty_print_disassembler::pretty_print_insn):
Remove "uiout" parameter.
(dump_insns): Update.
* cli-out.h (class cli_ui_out) <can_emit_style_escape>: Declare.
* cli-out.c (cli_ui_out::can_emit_style_escape): New method.
gdb/testsuite/ChangeLog
2019-08-06 Tom Tromey <tom@tromey.com>
* gdb.base/style.exp: Add disassemble test.
* gdb.base/style.c (some_called_function): New function.
(main): Use it.
Currently we support iteration on blocks; this patch extends that to make
subscript access work as well.
gdb/ChangeLog:
2019-08-05 Christian Biesinger <cbiesinger@google.com>
* NEWS: Mention dictionary access on blocks.
* python/py-block.c (blpy_getitem): New function.
(block_object_as_mapping): New struct.
(block_object_type): Use new struct for tp_as_mapping field.
gdb/doc/ChangeLog:
2019-08-05 Christian Biesinger <cbiesinger@google.com>
* python.texi (Blocks In Python): Document dictionary access on blocks.
gdb/testsuite/ChangeLog:
2019-08-05 Christian Biesinger <cbiesinger@google.com>
* gdb.python/py-block.exp: Test dictionary access on blocks.
Running
make check-read1 TESTS="gdb.mi/list-thread-groups-available.exp"
on my machine results in timeout failures. Running it while having
`tail -F testsuite/gdb.log` on the side shows that the test is never
really blocked, it is just slow at consuming the large output generated
by `-list-thread-groups --available` (which lists all the processes on
the system).
If I increase the timeout to a large value, the test passes in ~30
seconds (compared to under 1 second normally).
Increase the timeout for the particular mi_gdb_test that is long to
execute under read1. The new timeout value is a bit arbitrary. The
default timeout is 10 seconds, so I set the new timeout to be
"old-timeout * 10", so 100 seconds in the typical case.
gdb/testsuite/ChangeLog:
PR gdb/24863
* gdb.mi/list-thread-groups-available.exp: Increase timeout for
-list-thread-groups --available test when running under
check-read1.
When running tests with check-read1, we run into some timeouts where the tests
are not easy to rewrite using gdb_test_sequence:
...
FAIL: gdb.base/help.exp: help data (timeout)
FAIL: gdb.base/help.exp: help files (timeout)
FAIL: gdb.base/help.exp: help internals (timeout)
FAIL: gdb.base/help.exp: help user-defined (timeout)
FAIL: gdb.base/help.exp: help breakpoint "b" abbreviation (timeout)
FAIL: gdb.base/help.exp: help breakpoint "br" abbreviation (timeout)
FAIL: gdb.base/help.exp: help breakpoint "bre" abbreviation (timeout)
FAIL: gdb.base/info-macros.exp: info macros 2 (timeout)
FAIL: gdb.base/info-macros.exp: next (timeout)
FAIL: gdb.base/info-macros.exp: info macros 3 (timeout)
FAIL: gdb.base/info-macros.exp: next (timeout)
FAIL: gdb.base/info-macros.exp: next (timeout)
FAIL: gdb.base/info-macros.exp: info macros (timeout)
FAIL: gdb.base/info-macros.exp: next (timeout)
FAIL: gdb.base/info-macros.exp: next (timeout)
FAIL: gdb.base/info-macros.exp: info macros 7 (timeout)
FAIL: gdb.cp/nested-types.exp: ptype S10 (limit = -1) // parse failed (timeout)
FAIL: gdb.cp/nested-types.exp: set print type nested-type-limit 1 (timeout)
...
Fix these by increasing the timeout by a factor 10.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-08-05 Tom de Vries <tdevries@suse.de>
PR testsuite/24863
* lib/gdb.exp (with_read1_timeout_factor): New proc.
* gdb.base/help.exp: Use with_read1_timeout_factor.
* gdb.base/info-macros.exp: Same.
* gdb.cp/nested-types.exp: Same.
When running gdb.base/break-idempotent.exp with
--target_board=unix/-fno-PIE/-no-pie, we get:
...
nr of expected passes 140
...
The test-case is compiled once with nopie and once with pie, but in both cases
we end up with a non-PIE executable. The "-fno-PIE -no-pie" options specified
using the target_board are interpreted by dejagnu as multilib_flags, and end up
overriding the pie flags.
Fix this by checking in gdb_compile if the resulting exec is non-PIE despite of
a pie setting, and if so return an error:
...
Running gdb/testsuite/gdb.base/break-idempotent.exp ...
gdb compile failed, pie failed to generate PIE executable
=== gdb Summary ===
nr of expected passes 70
nr of untested testcases 1
...
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-08-05 Tom de Vries <tdevries@suse.de>
* lib/gdb.exp (version_at_least): Factor out of ...
(tcl_version_at_least): ... here.
(gdb_compile): Fail if pie results in non-PIE executable.
(readelf_version, readelf_prints_pie): New proc.
(exec_is_pie): Return -1 if unknown.
In tcl_version_at_least we compare a minor against a major version number:
...
} elseif { $tcl_version_major == $major \
&& $tcl_version_major >= $minor } {
...
Fix this by using $tcl_version_minor in the comparison instead.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-08-05 Tom de Vries <tdevries@suse.de>
* lib/gdb.exp (tcl_version_at_least): Fix typo.
This patch introduces a test for the 'info sources' command
and its new arguments [-dirname | -basename] [--] [REGEXP].
gdb/testsuite/ChangeLog
2019-08-03 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* gdb.base/info_sources.exp: New file.
* gdb.base/info_sources.c: New file.
* gdb.base/info_sources_base.c: New file.
Adjust gdb.base/batch-exit-status.exp so that test prefixes don't show
directory names for the source scripts passed with -x, to make test
results from different build directories comparable.
gdb/testsuite/ChangeLog:
2019-08-01 Pedro Franco de Carvalho <pedromfc@linux.ibm.com>
* gdb.base/batch-exit-status.exp: Call test_exit_status with
prefix argument.
(test_exit_status): Add prefix argument.
With gdb.threads/fork-plus-threads.exp and check-run1 we get:
...
FAIL: gdb.threads/fork-plus-threads.exp: detach-on-fork=off: \
inferior 1 exited (timeout)
...
Fix this by calling exp_continue for new thread and thread exited messages.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-08-01 Tom de Vries <tdevries@suse.de>
PR testsuite/24863
* gdb.threads/fork-plus-threads.exp: Fix check-run1 timeout by
calling exp_continue for new thread and thread exited messages.
With gdb.base/structs.exp and check-read1 we get:
...
FAIL: gdb.base/structs.exp: p chartest (timeout)
...
Fix this by using gdb_test_sequence.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-08-01 Tom de Vries <tdevries@suse.de>
PR testsuite/24863
* gdb.base/structs.exp: Fix check-read1 timeout using
gdb_test_sequence.
* lib/gdb.exp (tcl_version_at_least, lrepeat): New proc.
With gdb.base/break-interp.exp and check-read1, we run get:
...
FAIL: gdb.base/break-interp.exp: LDprelinkNOdebugNO: \
BINprelinkNOdebugNOpieNO: symbol-less: info files (timeout)
FAIL: gdb.base/break-interp.exp: LDprelinkNOdebugNO: \
BINprelinkNOdebugNOpieYES: symbol-less: info files (timeout)
FAIL: gdb.base/break-interp.exp: LDprelinkNOdebugIN: \
BINprelinkNOdebugNOpieNO: symbol-less: info files (timeout)
FAIL: gdb.base/break-interp.exp: LDprelinkNOdebugIN: \
BINprelinkNOdebugNOpieYES: symbol-less: info files (timeout)
...
Fix this by calling exp_continue after each "info files" line.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-08-01 Tom de Vries <tdevries@suse.de>
PR testsuite/24863
* gdb.base/break-interp.exp: Use exp_continue after each "info files"
line.
With gdb.base/signals.exp and check-read1 we get:
...
FAIL: gdb.base/signals.exp: info signals (timeout)
...
Fix this by using gdb_test_sequence.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-08-01 Tom de Vries <tdevries@suse.de>
PR testsuite/24863
* gdb.base/signals.exp: Fix check-read1 timeout using gdb_test_sequence.
In Ada, it's possible to have nested functions. However,
block.c:contained_in does not recognize this. Normally, this is no
problem, but if gdb is stopped inside a nested function, then you can
end up in the unexpected situation that "print" of an expression will
work, whereas "display" of the same expression will not -- because
contained_in returns 0.
This patch simply removes the BLOCK_FUNCTION check from contained_in.
The rationale here is that in languages without nested functions, this
will not cause any issues.
gdb/ChangeLog
2019-07-30 Tom Tromey <tromey@adacore.com>
* block.c (contained_in): Remove BLOCK_FUNCTION check.
gdb/testsuite/ChangeLog
2019-07-30 Tom Tromey <tromey@adacore.com>
* gdb.ada/display_nested.exp: New file.
* gdb.ada/display_nested/foo.adb: New file.
* gdb.ada/display_nested/pack.adb: New file.
* gdb.ada/display_nested/pack.ads: New file.
Similar to lookup_global_symbol, except that it checks the
STATIC_SCOPE.
gdb/ChangeLog:
2019-07-30 Christian Biesinger <cbiesinger@google.com>
PR/24474: Add a function to lookup static variables.
* NEWS: Mention this new function.
* python/py-symbol.c (gdbpy_lookup_static_symbol): New function.
* python/python-internal.h (gdbpy_lookup_static_symbol): New function.
* python/python.c (python_GdbMethods): Add new function.
gdb/doc/ChangeLog:
2019-07-30 Christian Biesinger <cbiesinger@google.com>
* python.texi (Symbols In Python): Document new function
gdb.lookup_static_symbol.
gdb/testsuite/ChangeLog:
2019-07-30 Christian Biesinger <cbiesinger@google.com>
* gdb.python/py-symbol.c: Add a static variable and one in an anonymous
namespace.
* gdb.python/py-symbol.exp: Test gdb.lookup_static_symbol.
When running libsegfault.exp with check-read1, I get:
...
Running gdb/testsuite/gdb.base/libsegfault.exp ...
ERROR: tcl error sourcing gdb/testsuite/gdb.base/libsegfault.exp.
ERROR: no such variable
(read trace on "env(LD_PRELOAD)")
invoked from within
"set env(LD_PRELOAD)"
("uplevel" body line 1)
invoked from within
"uplevel 1 [list set $var]"
invoked from within
"if [uplevel 1 [list array exists $var]] {
set saved_arrays($var) [uplevel 1 [list array get $var]]
} else {
set saved_scalars($var) [uplevel ..."
invoked from within
"if [uplevel 1 [list info exists $var]] {
if [uplevel 1 [list array exists $var]] {
set saved_arrays($var) [uplevel 1 [list array get $var]]
..."
(procedure "save_vars" line 11)
invoked from within
"save_vars { env(LD_PRELOAD) } {
if { ![info exists env(LD_PRELOAD) ]
|| $env(LD_PRELOAD) == "" } {
set env(LD_PRELOAD) "$lib"
} else {
..."
(procedure "gdb_spawn_with_ld_preload" line 4)
invoked from within
"gdb_spawn_with_ld_preload $libsegfault """
...
There are several things here interacting with environment variable
LD_PRELOAD:
- the expect "binary" build/gdb/testsuite/expect-read1 with does
export LD_PRELOAD=build/gdb/testsuite/read1.so before calling native expect
- read1.so which does unsetenv ("LD_PRELOAD") upon first call to read
- the test-case, which wants to set or append libSegFault.so to LD_PRELOAD
The error occurs when accessing $env(LD_PRELOAD), in a branch where
"info exists env(LD_PRELOAD)" returns true. AFAIU, this is
https://core.tcl-lang.org/tcl/tktview?name=67fd4f973a "incorrect results of
'info exists' when unset env var in one interp and check for existence from
another interp".
Work around the tcl bug by not unsetting the variable, but setting it to ""
instead:
...
- unsetenv ("LD_PRELOAD");
+ setenv ("LD_PRELOAD", "", 1);
...
Verified that reverting commit de28a3b72e "[gdb/testsuite, 2/2] Fix
gdb.linespec/explicit.exp with check-read1" reintroduced the check-read1
failure in gdb.linespec/explicit.exp.
This fixes a similar error in attach-slow-waitpid.exp, which also sets
LD_PRELOAD.
Tested on x86_64-linux with check-read1.
gdb/testsuite/ChangeLog:
2019-07-30 Tom de Vries <tdevries@suse.de>
* lib/read1.c (read): Don't use unsetenv (v), use setenv (v, "", 1)
instead.
When running gdb.base/dump.exp with --target_board=unix/-fPIE/-pie, we get:
...
Running gdb/testsuite/gdb.base/dump.exp ...
FAIL: gdb.base/dump.exp: dump array as value, intel hex
...
The FAIL happens because although the test specifies nopie, the exec is
in fact compiled as PIE. The "-fPIE -pie" options specified using the
target_board are interpreted by dejagnu as multilib_flags, and end up
overriding the nopie flags.
Fix this by checking in gdb_compile if the resulting exec is PIE despite of
a nopie setting, and if so return an error:
...
Running gdb/testsuite/gdb.base/dump.exp ...
gdb compile failed, nopie failed to prevent PIE executable
=== gdb Summary ===
nr of untested testcases 1
...
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-07-30 Tom de Vries <tdevries@suse.de>
PR testsuite/24834
* lib/gdb.exp (gdb_compile): Fail if nopie results in PIE executable.
(exec_is_pie): New proc.
This is essentially the inverse of Symbol.objfile. This allows
handling different symbols with the same name (but from different
objfiles) and can also be faster if the objfile is known.
gdb/ChangeLog:
2019-07-29 Christian Biesinger <cbiesinger@google.com>
* NEWS: Mention new functions Objfile.lookup_{global,static}_symbol.
* python/py-objfile.c (objfpy_lookup_global_symbol): New function.
(objfpy_lookup_static_symbol): New function.
(objfile_object_methods): Add new functions.
gdb/doc/ChangeLog:
2019-07-29 Christian Biesinger <cbiesinger@google.com>
* python.texi (Objfiles In Python): Document new functions
Objfile.lookup_{global,static}_symbol.
gdb/testsuite/ChangeLog:
2019-07-29 Christian Biesinger <cbiesinger@google.com>
* gdb.python/py-objfile.c: Add global and static vars.
* gdb.python/py-objfile.exp: Test new functions Objfile.
lookup_global_symbol and lookup_static_symbol.
Exactly which escape sequences are emitted by gdb in TUI mode are
determined largely by the curses implementation. Testing my latest
(as yet unsubmitted) series to refactor the TUI showed a couple of
failures that I tracked to the test suite's terminal implementation.
In particular, the CSI "@" sequence was not implemented; and the CSI
"X" sequence was implemented incorrectly.
This patch fixes both of these problems. Tested on x86-64 Fedora 28.
gdb/testsuite/ChangeLog
2019-07-29 Tom Tromey <tom@tromey.com>
* lib/tuiterm.exp (Term::_csi_@): New proc.
(Term::_csi_X): Don't move cursor.
Updated tests to test the new options and new values.
Test the default for print_what in python frame filtering.
Updated the tests impacted by the default in python frame filtering
which is now consistent with the backtrace command.
gdb/testsuite/ChangeLog
2019-07-29 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* gdb.base/options.exp: Update backtrace - completion to
new option -frame-info.
* gdb.base/frame-args.exp: Test new 'frame-arguments presence'.
Test new 'set print frame-info'. Test backtrace -frame-info
overriding 'set print frame-info'.
* gdb.python/py-framefilter.exp: Test new 'frame-arguments presence'.
Test new 'set print frame-info'.
Verify consistency of backtrace with and without filters, with and
without -no-filters.
* gdb.python/py-framefilter-invalidarg.exp: Update to new print_what
default.
When running gdb.linespec/explicit.exp with check-read1, we get:
...
(gdb) PASS: gdb.linespec/explicit.exp: set max-completions unlimited
break
-function
...
top
(gdb) PASS: gdb.linespec/explicit.exp: complete with no arguments
break
-function
...
top
(gdb) FAIL: gdb.linespec/explicit.exp: complete with no arguments (clearing input line)
...
The problem is that the send_gdb "\t\t" triggers completion twice:
...
set tst "complete with no arguments"
send_gdb "break \t"
gdb_test_multiple "" $tst {
"break \\\x07" {
send_gdb "\t\t"
gdb_test_multiple "" $tst {
...
}
clear_input_line $tst
...
but the following gdb_test_multiple only parses it once, so the second
completion is left for clear_input_line, which fails.
Fix this by triggering completion only once.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-07-29 Tom de Vries <tdevries@suse.de>
* gdb.linespec/explicit.exp: Fix completion trigger for "complete with
no arguments".
When running gdb.linespec/explicit.exp with check-read1, we get:
...
(gdb) PASS: gdb.linespec/explicit.exp: complete unique file name: break -source "3explicit.c"
break -source exp^Glicit^G^M
explicit.c explicit2.c ^M
(gdb) FAIL: gdb.linespec/explicit.exp: complete non-unique file name
...
The problem is that we have a gdb_test_multiple where we match two regexps:
...
set tst "complete non-unique file name"
send_gdb "break -source exp\t"
gdb_test_multiple "" $tst {
-re "break -source exp\\\x07licit" {
...
}
-re "break -source exp\\\x07l" {
# This pattern may occur when glibc debuginfo is installed.
...
}
}
...
but since second is a substring of the first, we'll usually match the first,
but with check-read1 we'll match the second.
Fix this by using a single regexp and merging the related code.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-07-29 Tom de Vries <tdevries@suse.de>
* gdb.linespec/explicit.exp: Fix gdb_test_multiple regexps where second
is a substring of the first for "complete non-unique file name".
when running python/python.exp with check-read1, we get:
...
(gdb) PASS: gdb.python/python.exp: prompt substitution readline - end
python gdb.prompt_hook = error_prompt^M
Python Exception <type 'exceptions.RuntimeError'> Python exception calledPASS: gdb.python/python.exp: set hook
: ^M
(gdb) PASS: gdb.python/python.exp: set the hook to default
python gdb.prompt_hook = None^M
(gdb) PASS: gdb.python/python.exp: set print-stack full for prompt error test
set python print-stack full^M
(gdb) FAIL: gdb.python/python.exp: set the hook
python gdb.prompt_hook = error_prompt^M
Traceback (most recent call last):^M
File "<string>", line 3, in error_prompt^M
RuntimeError: Python exception called^M
(gdb) FAIL: gdb.python/python.exp: set the hook to default
...
The problem is that gdb_test_multiple here:
...
gdb_test_multiple "python gdb.prompt_hook = error_prompt" "set the hook" {
-re "Python Exception (exceptions.RuntimeError|<(type 'exceptions.|class ')RuntimeError'>) Python excepti
on called.*" {
pass "set hook"
}
}
...
specifies a regexp that ends with ".*" but doesn't specify the expected
$gdb_prompt.
Consequently, due to check-read1, the ".*" is matched to "" and the remaining
$gdb_prompt is read by the the following gdb_py_test_silent_cmd, which has
its own $gdb_prompt read by the following gdb_py_test_silent_cmd, which has
its own $gdb_prompt causing a mismatch for the following gdb_test_multiple:
...
gdb_test_multiple "python gdb.prompt_hook = error_prompt" "set the hook" {
-re "Traceback.*File.*line.*RuntimeError.*Python exception called.*" {
pass "set hook"
}
}
...
which causes both FAILs.
The second gdb_test_multiple has the same problem as the first, but it happens
not to cause a FAIL because it's followed by a gdb_py_test_silent_cmd and a
clean_restart.
Fix the regexps in both gdb_test_multiple calls.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-07-29 Tom de Vries <tdevries@suse.de>
* gdb.python/python.exp: Don't terminate gdb_test_multiple regexp
with ".*".
With check-read1 we get:
...
FAIL: gdb.mi/mi-catch-cpp-exceptions.exp: check for stap probe in libstdc++
FAIL: gdb.mi/mi-nonstop.exp: probe for target remote
...
In both cases this is due to using gdb_test_multiple (which expects $gdb_prompt
by default) in combination with gdb using $gdb_mi_prompt, similar to the
problem fixed by commit d17725d72f "Don't expect gdb_prompt in
mi_skip_python_test".
Fix this by adding the $prompt_regexp argument to the gdb_test_multiple calls.
gdb/testsuite/ChangeLog:
2019-07-29 Tom de Vries <tdevries@suse.de>
* lib/gdb.exp (skip_libstdcxx_probe_tests_prompt, gdb_is_target_1):
Pass prompt_regexp parameter to gdb_test_multiple calls.
With gdb.base/maint.exp and check-read1, we get:
...
FAIL: gdb.base/maint.exp: maint print registers
...
Using this patch:
...
diff --git a/gdb/testsuite/gdb.base/maint.exp b/gdb/testsuite/gdb.base/maint.exp
index a7675ea215..b81d7ec660 100644
--- a/gdb/testsuite/gdb.base/maint.exp
+++ b/gdb/testsuite/gdb.base/maint.exp
@@ -81,7 +81,9 @@ gdb_test_multiple $test $test {
exp_continue
}
-re "$gdb_prompt $" {
- gdb_assert { $saw_registers && $saw_headers } $test
+ gdb_assert { $saw_headers } "$test: saw headers"
+ gdb_assert { $saw_registers } "$test: saw registers"
+ pass "$test: got prompt"
}
}
...
We get more information:
...
PASS: gdb.base/maint.exp: maint print registers: saw headers
FAIL: gdb.base/maint.exp: maint print registers: saw registers
PASS: gdb.base/maint.exp: maint print registers: got prompt
...
The problem is that when matching:
...
(gdb) maint print registers^M
Name Nr Rel Offset Size Type ^M
rax 0 0 0 8 int64_t ^M
...
the regexp for $saw_headers ends in "\[\r\n\]+", which
allows it to match only the "\r". The remaining "\n" then start the next line
to be matched, which doesn't match for the $saw_registers regexp since it
starts with "^\[^\r\n\]+".
Fix this by ending the regexps with "\r\n".
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-07-29 Tom de Vries <tdevries@suse.de>
* gdb.base/maint.exp: Use "\r\n" instead of "\[\r\n\]+" in "maint
print registers" regexps.
When running gdb.base/define.exp with check-read1, we get:
...
show prompt^M
Gdb's prompt is "(gdb) ".^M
(gdb) PASS: gdb.base/define.exp: save gdb_prompt
set prompt \(blah\) ^M
(blah) PASS: gdb.base/define.exp: set gdb_prompt
set prompt (gdb) PASS: gdb.base/define.exp: reset gdb_prompt
^M
(gdb) FAIL: gdb.base/define.exp: define do-define
...
The problem is that the "$gdb_prompt $" regexp here:
...
gdb_test_multiple "set prompt $prior_prompt " "reset gdb_prompt" {
-re "$gdb_prompt $" {
pass "reset gdb_prompt"
}
}
...
triggers for the echoing of the command "set prompt $prior_prompt " rather
than for the prompt after the command has executed.
Fix this by changing the regexp to "\r\n$gdb_prompt $".
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-07-29 Tom de Vries <tdevries@suse.de>
* gdb.base/define.exp: Add "\r\n" to "reset gdb_prompt" regexp.
When running gdb.python/py-mi-events.exp with make check-read1, we get:
...
(gdb) ^M
python print ('test')^M
&"python print ('test')\n"^M
~"test\n"^M
^done^M
(gdb) FAIL: gdb.python/py-mi-events.exp: verify python support
^M
python print (sys.version_info[0])^M
&"python print (sys.version_info[0])\n"^M
~"2\n"^M
^done^M
(gdb) FAIL: gdb.python/py-mi-events.exp: check if python 3
^M
...
The FAILs happen as follows.
On one hand, skip_python_tests_prompt uses the prompt_regexp parameter for the
user_code argument of gdb_test_multiple:
...
proc skip_python_tests_prompt { prompt_regexp } {
global gdb_py_is_py3k
gdb_test_multiple "python print ('test')" "verify python support" {
-re "not supported.*$prompt_regexp" {
unsupported "Python support is disabled."
return 1
}
-re "$prompt_regexp" {}
}
gdb_test_multiple "python print (sys.version_info\[0\])" "check if python 3" {
-re "3.*$prompt_regexp" {
set gdb_py_is_py3k 1
}
-re ".*$prompt_regexp" {
set gdb_py_is_py3k 0
}
}
...
On the other hand, gdb_test_multiple itself uses $gdb_prompt:
...
-re "\r\n$gdb_prompt $" {
if ![string match "" $message] then {
fail "$message"
}
set result 1
}
...
So when mi_skip_python_test calls skip_python_tests_prompt with prompt_regexp
set to $mi_gdb_prompt:
...
proc mi_skip_python_tests {} {
global mi_gdb_prompt
return [skip_python_tests_prompt "$mi_gdb_prompt$"]
}
...
and expect reads "(gdb) " and tries to match it (due to the READ1=1 setting),
the user_code regexps using $prompt_regexp (set to $mi_gdb_prompt) don't match,
but the $gdb_prompt regexp in gdb_test_multiple does match.
Fix this by adding a prompt_regexp parameter to gdb_test_multiple, and using the
parameter in skip_python_tests_prompt.
Tested gdb.python/py-mi-events.exp with make check READ1=1 x86_64-linux.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-07-29 Tom de Vries <tdevries@suse.de>
PR gdb/24855
* lib/gdb.exp (gdb_test_multiple): Add prompt_regexp parameter.
(skip_python_tests_prompt): Add prompt_regexp argument to
gdb_test_multiple calls.
This adds a new test that checks that the "file" command will show the
program's "main".
gdb/testsuite/ChangeLog
2019-07-27 Tom Tromey <tom@tromey.com>
* gdb.tui/main.exp: New file.
My original intent here was to add a test case to test that empty TUI
windows re-render their contents after a resize. However, this seems
pretty broken at the moment, so a lot of the test is actually
disabled.
gdb/testsuite/ChangeLog
2019-07-27 Tom Tromey <tom@tromey.com>
* lib/tuiterm.exp (Term::clean_restart): Make "executable"
optional.
* gdb.tui/empty.exp: New file.
This adds a test case that resizes the terminal and then checks that
the TUI updates properly.
gdb/testsuite/ChangeLog
2019-07-27 Tom Tromey <tom@tromey.com>
* lib/tuiterm.exp (spawn): New proc.
(Term::resize): New proc.
* gdb.tui/resize.exp: New file.
This adds a test to check that the "list" command will update the TUI
source window.
gdb/testsuite/ChangeLog
2019-07-27 Tom Tromey <tom@tromey.com>
* gdb.tui/list.exp: New file.
This adds a test of "layout split" to the TUI test suite.
gdb/testsuite/ChangeLog
2019-07-27 Tom Tromey <tom@tromey.com>
* gdb.tui/basic.exp: Add "layout split" test.
This adds a very simple test for "layout asm".
gdb/testsuite/ChangeLog
2019-07-27 Tom Tromey <tom@tromey.com>
* gdb.tui/basic.exp: Add "layout asm" test.
This patch implements a simple ANSI terminal emulator for the test
suite. It is still quite basic, but it is good enough to allow some
simple TUI testing to be done.
gdb/testsuite/ChangeLog
2019-07-27 Tom Tromey <tom@tromey.com>
* lib/tuiterm.exp: New file.
* gdb.tui/basic.exp: New file.
I recently noticed the following behavior while debugging
dw2-ranges-func-low-cold. This is one of the test programs associated
with the test gdb.dwarf2/dw2-ranges-func.exp.
(gdb) b 70
Breakpoint 1 at 0x401129: file dw2-ranges-func-lo-cold.c, line 70.
(gdb) run
Starting program: dw2-ranges-func-lo-cold
Breakpoint 1, foo ()
at dw2-ranges-func-lo-cold.c:70
70 if (e) foo_cold (); /* foo foo_cold call */
(gdb) set var e=1
(gdb) step
[Inferior 1 (process 12545) exited normally]
This is incorrect. When stepping, we expect a step to occur. We do not
expect the program to exit. Instead, we should see the following behavior:
...
(gdb) set var e=1
(gdb) step
foo ()
at dw2-ranges-func-lo-cold.c:54
54 baz (); /* foo_cold baz call */
(Note that I've shortened the paths in the above sessions to improve
readability.)
The bug is in fill_in_stop_func() in infrun.c. While working on
non-contiguous address range improvements in 2018, I replaced the
call to find_pc_partial_function() with a call to
find_function_entry_range_from_pc(). Although this seemed like the
right thing to do at the time, I now think that calling
find_pc_partial_function (along with some other tweaks) is the right
thing to do.
For blocks with a single contiguous range, these functions do pretty
much the same thing: when the function succeeds, the function name,
start address, and end address are all filled in. Additionally,
find_pc_partial_function contains an additional output parameter
which is set to the block containing that PC.
For blocks with non-contiguous ranges, find_pc_partial_function
sets the start and end addresses to the start and end addresses
of the range containing the pc. find_function_entry_range_from_pc
does what it says; it sets the start and end addresses to those
of the range containing the entry pc.
The reason that I had thought that using the entry pc range was
correct is due to the fact that fill_in_stop_func() contains some
code for advancing past the function start and entry point. To do
this, we'd need the range that contains the entry pc.
However, when stepping, we actually want the range that contains the
stop pc. If that range also contains the entry pc, we should then
attempt to advance stop_func_start past the start offset and entry
point. (I haven't thought very hard about the reason for advancing
the stop_func_start in this manner. Since it's been there for quite
a while, I'm assuming that it's still a good idea.)
Back when I wrote the test case, I had included a test for doing the
step shown in the example above. I had problems with it, however. At
the time, I thought it was due to differing compiler versions, so I
disabled that portion of the test. I have now reenabled those tests,
but have left in place the logic which may be used to disable it.
The changes to dw2-ranges-func.exp depend on my other recent changes
to the file which have not been pushed yet.
Finally, I'll note that the only caller of
find_function_entry_range_from_pc() is/was fill_in_stop_func(). Once
this commit goes in, it'll be dead code. I considered removing it,
but I think that it ought to be used (instead of
find_pc_partial_function) for determining the correct range to scan
for prologue analysis, so I'm going to leave it in place for now.
gdb/ChangeLog:
* infrun.c (fill_in_stop_func): Use find_pc_partial_function
instead of find_function_entry_range_from_pc.
testsuite/ChangeLog:
* gdb.dwarf2/dw2-ranges-func.exp (enable_foo_cold_stepping):
Enable tests associated with this flag. Adjust regex
referencing "foo_low" to now refer to "foo_cold" instead.
The original dw2-ranges-func.exp test caused a function named foo to be
created with two non-contiguous address ranges. In the C source file,
a function named foo_low was incorporated into the function foo which
was also defined in that file. The DWARF assembler is used to do this
manipulation. The source file had been laid out so that foo_low would
likely be placed (by the compiler and linker) at a lower address than
foo().
The case where a range at a higher set of addresses (than foo) was not
being tested. In a recent discussion on gdb-patches, it became clear
that performing such tests are desirable because bugs were discovered
which only became evident when the other range was located at high(er)
addresses than the range containing the entry point for the function.
This other (non entry pc) address range is typically used for "cold"
code which executes less frequently. Thus, I renamed foo_low to
foo_cold and renamed the C source file from dw-ranges-func.c to
dw-ranges-func-lo.c. I then made a copy of this file, naming it
dw-ranges-func-hi.c. (That was my intent anyway. According to git,
I renamed dw-ranges-func.c to dw-ranges-func-hi.c and then modified it.
dw-ranges-func-lo.c shows up as an entirely new file.)
Within dw-ranges-func-hi.c, I changed the placement of foo_cold()
along with some of the other functions so that foo_cold() would be at
a higher address than foo() while also remaining non-contiguous. The
two files, dw-ranges-func-lo.c and dw-ranges-func-hi.c, are
essentially the same except for the placement of some of the functions
therein.
The tests in dw2-ranges-func.exp where then wrapped in a new proc named
do_test which was then called in a loop from the outermost level. The
loop causes each of the source files to have the same tests run upon
them.
I also added a few new tests which test functionality fixed by the other
commits to this patch series. Due to the reorganization of the file,
it's hard to identify these changes in the patch. So, here are the
tests which were added:
with_test_prefix "no-cold-names" {
# Due to the calling sequence, this backtrace would normally
# show function foo_cold for frame #1. However, we don't want
# this to be the case due to placing it in the same block
# (albeit at a different range) as foo. Thus it is correct to
# see foo for frames #1 and #2. It is incorrect to see
# foo_cold at frame #1.
gdb_test_sequence "bt" "backtrace from baz" {
"\[\r\n\]#0 .*? baz \\(\\) "
"\[\r\n\]#1 .*? foo \\(\\) "
"\[\r\n\]#2 .*? foo \\(\\) "
"\[\r\n\]#3 .*? main \\(\\) "
}
# Doing x/2i foo_cold should show foo_cold as the first symbolic
# address and an offset from foo for the second. We also check to
# make sure that the offset is not too large - we don't GDB to
# display really large offsets that would (try to) wrap around the
# address space.
set foo_cold_offset 0
set test "x/2i foo_cold"
gdb_test_multiple $test $test {
-re " (?:$hex) <foo_cold>.*?\n (?:$hex) <foo\[+-\](\[0-9\]+)>.*${gdb_prompt}" {
set foo_cold_offset $expect_out(1,string)
pass $test
}
}
gdb_assert {$foo_cold_offset <= 10000} "offset to foo_cold is not too large"
# Likewise, verify that second address shown by "info line" is at
# and offset from foo instead of foo_cold.
gdb_test "info line *foo_cold" "starts at address $hex <foo_cold> and ends at $hex <foo\[+-\].*?>.*"
}
When run against a GDB without the requisite bug fixes (from this patch
series), these 6 failures should be seen:
FAIL: gdb.dwarf2/dw2-ranges-func.exp: lo-cold: no-cold-names: backtrace from baz (pattern 4)
FAIL: gdb.dwarf2/dw2-ranges-func.exp: lo-cold: no-cold-names: x/2i foo_cold
FAIL: gdb.dwarf2/dw2-ranges-func.exp: lo-cold: no-cold-names: info line *foo_cold
FAIL: gdb.dwarf2/dw2-ranges-func.exp: hi-cold: no-cold-names: backtrace from baz (pattern 3)
FAIL: gdb.dwarf2/dw2-ranges-func.exp: hi-cold: no-cold-names: x/2i foo_cold
FAIL: gdb.dwarf2/dw2-ranges-func.exp: hi-cold: no-cold-names: info line *foo_cold
gdb/testsuite/ChangeLog:
* gdb.dwarf2/dw2-ranges-func.c: Rename to...
* gdb.dwarf2/dw2-ranges-func-lo-cold.c: ...this.
* gdb.dwarf2/dw2-ranges-func-lo-cold.c (foo_low): Change name to
foo_cold. Revise comments to match.
* gdb.dwarf2/dw2-ranges-func-hi-cold.c: New file.
* gdb.dwarf2/dw2-ranges-func.exp (do_test): New proc. Existing tests
were wrapped into this proc; Call do_test in loop from outermost
level.
(foo_low): Rename all occurrences to "foo_cold".
(backtrace from baz): New test.
(x2/i foo_cold): New test.
(info line *foo_cold): New test.
I ran into this error:
...
ERROR: tcl error sourcing gdb/testsuite/gdb.arch/i386-pkru.exp.
ERROR: missing "
while executing
"untested ""
invoked from within
"if { [prepare_for_testing "failed to prepare" ${testfile} ${srcfile} \
[list debug additional_flags=${comp_flags}]] } {
untested "failed to c..."
(file "gdb/testsuite/gdb.arch/i386-pkru.exp" line 25)
invoked from within
...
caused by:
...
untested "failed to compile x86 PKEYS test.
...
Fix the unterminated string.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-07-26 Tom de Vries <tdevries@suse.de>
* gdb.arch/i386-pkru.exp: Fix unterminated string.
On a system without SDT probes in libstdc++, we run into:
...
FAIL: gdb.mi/mi-catch-cpp-exceptions.exp: all with invalid regexp: run until \
breakpoint in main (unknown output after running)
...
The test-case uses a regexp argument for the catch throw/rethrow/catch
command, which is only supported on systems with SDT probes in libstdc++.
Fix this by marking the portions of the test-case that use a regexp argument
as unsupported on a system without SDT probes.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-07-25 Tom de Vries <tdevries@suse.de>
PR testsuite/24830
* gdb.mi/mi-catch-cpp-exceptions.exp: Call
mi_skip_libstdcxx_probe_tests, and skip unsupported tests.
* lib/gdb.exp (skip_libstdcxx_probe_tests_prompt): Factor out of ...
(skip_libstdcxx_probe_tests): ... here.
* lib/mi-support.exp (mi_skip_libstdcxx_probe_tests): New proc.
When running gdb.objc/objcdecode.exp we get:
...
objcdecode.m: In function '-[Decode multipleDef]':
objcdecode.m:14:3: warning: incompatible implicit declaration of built-in \
function 'printf'
printf("method multipleDef\n");
^~~~~~
objcdecode.m:14:3: note: include '<stdio.h>' or provide a declaration of \
'printf'
...
Fix this in the three gdb.objc/*.m test-cases by including stdio.h.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-07-24 Tom de Vries <tdevries@suse.de>
PR testsuite/24807
* gdb.objc/basicclass.m: Include stdio.h.
* gdb.objc/nondebug.m: Same.
* gdb.objc/objcdecode.m: Same.
When running gdb.base/infoline-reloc-main-from-zero.exp, I see:
...
Running gdb/testsuite/gdb.base/infoline-reloc-main-from-zero.exp ...
gdb compile failed, ld: infoline-reloc-main-from-zero: \
not enough room for program headers, try linking with -N
ld: final link failed: bad value
collect2: error: ld returned 1 exit status
UNTESTED: gdb.base/infoline-reloc-main-from-zero.exp: infoline-reloc-main-from-zero.exp
UNTESTED: gdb.base/infoline-reloc-main-from-zero.exp: failed to compile
...
Fix this by following the suggestion:
...
-set opts {debug "additional_flags=-nostdlib -emain -Wl,-Ttext=0x00"}
+set opts {debug "additional_flags=-nostdlib -emain -Wl,-Ttext=0x00 -Wl,-N"}
...
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-07-24 Tom de Vries <tdevries@suse.de>
PR testsuite/24612
* gdb.base/infoline-reloc-main-from-zero.exp: Add -Wl,-N to
additional_flags.
We currently have these FAILs:
...
FAIL: gdb.multi/tids.exp: two inferiors: info threads -1
FAIL: gdb.multi/tids.exp: two inferiors: info threads -$one
...
because we're expecting:
...
Invalid thread ID: -1
...
but instead we have:
...
Unrecognized option at: -1
...
This error message for info threads has changed since commit 54d6600669
'Make "info threads" use the gdb::option framework'.
Update the test accordingly.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-07-24 Tom de Vries <tdevries@suse.de>
PR testsuite/24831
* gdb.multi/tids.exp: Update error messages for info threads.
On openSUSE Leap 15.0, I get:
...
FAIL: gdb.base/info-types.exp: l=c: info types
FAIL: gdb.base/info-types.exp: l=c++: info types
...
because the info type command prints info for files info-types.c, stddef.h,
elf-init.c and init.c, while the regexp in the test-case expect only info for
info-types.c.
Fix this by extending the regexp.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-07-24 Tom de Vries <tdevries@suse.de>
* gdb.base/info-types.exp: Allow info types to print info for more than
one file.
When running multidictionary.exp in conjunction with:
...
$ stress -c $(($(cat /proc/cpuinfo | grep -c "^processor") + 1))
...
we get:
...
Running gdb/testsuite/gdb.dwarf2/multidictionary.exp ...
ERROR: Couldn't load multidictionary into gdb.
=== gdb Summary ===
nr of unresolved testcases 1
...
The multidictionary test-case needs -readnow, and achieves this using:
...
gdb_spawn_with_cmdline_opts "-readnow"
gdb_load
...
but the initial gdb prompt is not read. Usually, the following gdb_load
command accidentally consumes that initial prompt (at the gdb_expect for the
kill command in gdb_file_cmd). But under high load, that doesn't happen and
we run into the error.
Fix this by consuming the initial gdb prompt after spawning gdb.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-07-23 Tom de Vries <tdevries@suse.de>
PR testsuite/24842
* gdb.dwarf2/multidictionary.exp: Consume initial prompt after
gdb_spawn_with_cmdline_opts.
GDB is not able to execute "step" command on function calls of Armv8-M cmse secure entry functions.
Everytime GNU linker come across definition of any cmse secure entry function in object file(s),
it creates two new instructions secure gateway (sg) and original branch destination (b.w),
place those two instructions in ".gnu.sgstubs" section of executable.
Any function calls to these cmse secure entry functions is re-directed through secure gateway (sg)
present in ".gnu.sgstubs" section.
Example:
Following is a function call to cmse secure entry function "foo":
...
bl xxxx <foo> --->(a)
...
<foo>
xxxx: push {r7, lr}
GNU linker on finding out "foo" is a cmse secure entry function, created sg and b.w instructions and
place them in ".gnu.sgstubs" section (marked by c).
The "bl" instruction (marked by a) which is a call to cmse secure entry function is modified by GNU linker
(as marked by b) and call flow is re-directly through secure gateway (sg) in ".gnu.sgstubs" section.
...
bl yyyy <foo> ---> (b)
...
section .gnu.sgstubs: ---> (c)
yyyy <foo>
yyyy: sg // secure gateway
b.w xxxx <__acle_se_foo> // original_branch_dest
...
0000xxxx <__acle_se_foo>
xxxx: push {r7, lr} ---> (d)
On invoking GDB, when the control is at "b" and we pass "step" command, the pc returns "yyyy"
(sg address) which is a trampoline and which does not exist in source code. So GDB jumps
to next line without jumping to "__acle_se_foo" (marked by d).
The above details are published on the Arm website [1], please refer to section 5.4 (Entry functions)
and section 3.4.4 (C level development flow of secure code).
[1] https://developer.arm.com/architectures/cpu-architecture/m-profile/docs/ecm0359818/latest/armv8-m-security-extensions-requirements-on-development-tools-engineering-specification
This patch fixes above problem by returning target pc "xxxx" to GDB on executing "step"
command at "b", so that the control jumps to "__acle_se_foo" (marked by d).
gdb/ChangeLog:
* arm-tdep.c (arm_skip_cmse_entry): New function.
(arm_is_sgstubs_section): New function.
(arm_skip_stub): Add call to arm_skip_cmse_entry function.
gdb/testsuite/ChangeLog:
* gdb.arch/arm-cmse-sgstubs.c: New test.
* gdb.arch/arm-cmse-sgstubs.exp: New file.
When running gdb.mi/mi-complete.exp in conjunction with:
...
$ stress -c $(($(cat /proc/cpuinfo | grep -c "^processor") + 1))
...
we get less than 50% full passes:
...
$ for n in $(seq 1 100); do \
make V=1 -O check \
'RUNTESTFLAGS=gdb.mi/mi-complete.exp --target_board=unix'; \
done 2>&1 \
| grep "expected passes" | sort | uniq -c
45 # of expected passes 7
9 # of expected passes 8
46 # of expected passes 9
...
A diff between a passing and failing gdb.log shows this difference:
...
-&"set max-completions 1\n"
2-complete br
+&"set max-completions 1\n"
...
The problem is that the test-case issues the "set max-completion <n>" command,
and without waiting for the output issues a next command, and tries to parse
the results of both commands, expecting a specific interleaving of the various
output streams.
Fix the FAIL by waiting for the result of the "set max-completion <n>" command
before issuing another command.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-07-23 Tom de Vries <tdevries@suse.de>
PR testsuite/24711
* gdb.mi/mi-complete.exp: Wait for "set max-completions" result before
issuing next command.
Currently each language has a la_print_typedef method, this is only
used for the "info types" command.
The documentation for "info types" says:
Print a brief description of all types whose names match the regular
expression @var{regexp} (or all types in your program, if you supply
no argument).
However, if we consider this C code:
typedef struct {
int a;
} my_type;
Then currently with "info types" this will be printed like this:
3: typedef struct {
int a;
} my_type;
I see two problems with this, first the indentation is clearly broken,
second, if the struct contained more fields then it feels like the
actual type names could easily get lost in the noise.
Given that "info types" is about discovering type names, I think there
is an argument to be made that we should focus on giving _only_ the
briefest summary for "info types", and if the user wants to know more
they can take the type name and plug it into "ptype". As such, I
propose that a better output would be:
3: typedef struct {...} my_type;
The user understands that there is a type called `my_type`, and that
it's an alias for an anonymous structure type.
The change to achieve this turns out to be pretty simple, but only
effects languages that make use of c_print_typedef, which are C, C++,
asm, minimal, d, go, objc, and opencl. Other languages will for now
do whatever they used to do.
The patch to change how anonymous structs are displayed also changes
the display of anonymous enums, consider this code sample:
typedef enum {
AA, BB, CC
} anon_enum_t;
This used to be displayed like this:
3: typedef enum {AA, BB, CC} anon_enum_t;
Which will quickly become cluttered for enums with a large number of
values. The modified output looks like this:
3: typedef enum {...} anon_enum_t;
Again, the user can always make use of ptype if they want to see the
details of the anon_enum_t type.
It is worth pointing out that this change (to use {...}) only effects
anonymous structs and enums, named types don't change with this patch,
consider this code:
struct struct_t {
int i;
};
enum enum_t {
AA, BB, CC
};
The output from 'info types' remains unchanged, like this:
4: enum enum_t;
1: struct struct_t;
An additional area of interest is how C++ handles anonymous types used
within a typedef; enums are handled basically inline with how C
handles them, but structs (and classes) are slightly different. The
behaviour before the patch is different, and is unchanged by this
patch. Consider this code compiled for C++:
typedef struct {
int i;
} struct_t;
Both before and after this patch, this is show by 'info types' as:
3: typedef struct_t struct_t;
Unions are displayed similarly to structs in both C and C++, the
handling of anonymous unions changes for C in the same way that
it changes for anonymous structs.
I did look at ada, as this is the only language to actually have some
tests for "info types", however, as I understand it ada doesn't really
support typedefs, however, by forcing the language we can see what ada
would print. So, if we 'set language ada', then originally we printed
this:
3: record
a: int;
end record
Again the indentation is clearly broken, but we also have no mention
of the type name at all, which is odd, but understandable given the
lack of typedefs. If I make a similar change as I'm proposing for C,
then we now get this output:
3: record ... end record
Which is even less informative I think. However, the original output
_is_ tested for in gdb.ada/info_auto_lang.exp, and its not clear to me
if the change is a good one or not, so for now I have left this out.
gdb/ChangeLog:
* c-typeprint.c (c_print_typedef): Pass -1 instead of 0 to
type_print.
gdb/testsuite/ChangeLog:
* gdb.ada/info_auto_lang.exp: Update expected results.
* gdb.base/info-types.c: Add additional types to check.
* gdb.base/info-types.exp: Update expected results.
This commit makes two changes to the "info types" command:
First, only use typedef_print for printing typedefs, and use
type_print for printing non-typedef scalar (non-struct) types. The
result of this is the output for builtin types goes from this:
typedef double;
typedef float;
typedef int;
to this:
double;
float;
int;
which seems to make more sense.
Next GDB no longer matches msymbols as possible type names. When
looking for function symbols it makes sense to report matching
msymbols from the text sections, and for variables msymbols from the
data/bss sections, but when reporting types GDB would match msymbols
of type absolute. But I don't see why these are likely to indicate
type names. As such I've updated the msymbol matching lists in
symtab.c:search_symbols so that when searching in the TYPES_DOMAIN, we
never match any msymbols.
gdb/ChangeLog:
* symtab.c (search_symbols): Adjust msymbol matching type arrays
so that GDB doesn't match any msymbols when searching in the
TYPES_DOMAIN.
(print_symbol_info): Print using typedef_print or type_print based
on the type of the symbol. Add updated FIXME comment moved from...
(_initialize_symtab): ... move and update FIXME comment to above.
gdb/testsuite/ChangeLog:
* gdb.base/info-types.c: New file.
* gdb.base/info-types.exp: New file.
Tom de Vries
Andrew Burgess
Tom Tromey
Simon Marchi
Andreas Arnez
Weimin Pan
Tom Tromey
Pedro Alves
Ulrich Weigand
Mike Gulick
Philippe Waroquiers
David Blaikie
Sandra Loosemore
Sergio Durigan Junior
Christian Biesinger
Alan Hayward
Patrick Palka
Simon Marchi
Pedro Franco de Carvalho
Kevin Buettner
Srinath Parvathaneni