| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Consider the following test-case:
...
$ cat 1.c
typedef int (*final_t) (int arg);
int final (int arg)
{ return arg + 1; }
final_t gnu_ifunc (void)
{ return final; }
int gnu_ifunc_alias (int) __attribute__ ((ifunc ("gnu_ifunc")));
int main (void)
{ return gnu_ifunc_alias (10); }
...
with result:
...
$ gcc 1.c
$ ./a.out; echo $?
11
...
The test-case uses the ifunc attribute, but there's another solution using
%gnu_indirect_function. Consider 2.c and 3.c:
...
$ cat 2.c
typedef int (*final_t) (int arg);
int final (int arg)
{ return arg + 1; }
asm (".type gnu_ifunc, %gnu_indirect_function");
final_t gnu_ifunc (void)
{ return final; }
$ cat 3.c
extern int gnu_ifunc (int);
int main (void)
{ return gnu_ifunc (10); }
...
However, it can be inconvenient to have seperate files for the incompatible
decls of gnu_ifunc, so we can use this in a single file like this:
...
$ cat 4.c
typedef int (*final_t) (int arg);
int final (int arg)
{ return arg + 1; }
asm (".type gnu_ifunc, %gnu_indirect_function");
final_t gnu_ifunc (void)
{ return final; }
extern int gnu_ifunc_alias (int arg) __attribute__ ((alias ("gnu_ifunc")));
int main (void)
{ return gnu_ifunc_alias (10); }
...
This alias trick works ok at -O0, but not at -O2:
...
$ gcc 4.c
$ ./a.out; echo $?
11
$ gcc 4.c
$ ./a.out; echo $?
176
...
and produces a warning with gcc-8 and later:
...
$ gcc-8 4.c
4.c:7:12: warning: 'gnu_ifunc_alias' alias between functions of incompatible \
types 'int(int)' and 'int (*(void))(int)' [-Wattribute-alias]
extern int gnu_ifunc_alias (int arg) __attribute__ ((alias ("gnu_ifunc")));
^~~~~~~~~~~~~~~
4.c:5:9: note: aliased declaration here
final_t gnu_ifunc (void)
^~~~~~~~~
...
The warning is correct, but the mismatch is intentional.
The last variant (%gnu_indirect_function + alias) is used in
gdb.compile/compile-ifunc.c, so we run into the warning with recent gcc.
Fix the warning by compiling with -Wno-attribute-alias.
Tested the test-case on x86_64-linux with gcc-10, and observed I no longer see
the warning:
...
Running src/gdb/testsuite/gdb.compile/compile-ifunc.exp ...
=== gdb Summary ===
nr of untested testcases 1
...
gdb/testsuite/ChangeLog:
2020-05-06 Tom de Vries <tdevries@suse.de>
* gdb.compile/compile-ifunc.exp: Use -Wno-attribute-alias.
|
|
When running test-case gdb.base/async.exp with gcc-8, we run into:
...
FAIL: gdb.base/async.exp: stepi&
...
The problem is that with gcc-8, the instruction address is no longer printed:
...
stepi&
-(gdb) 0x00000000004004b2 9 x = 5; x = 5; x = 5;
+(gdb) 9 x = 5; x = 5; x = 5;
completed.
-PASS: gdb.base/async.exp: stepi&
+FAIL: gdb.base/async.exp: stepi&
...
This is due to the fact that gcc-8 contains more precise line info, making the
address being stepped to a "recommended breakpoint location", and consequently
gdb doesn't print the address prefix anymore.
Given that:
- we step through statements on the same line, and
- there's no addres prefix anymore,
this gives the impression of lack of progress, which could be improved upon,
filed as enhancement PR25911 - "Show column when stepping through line".
Fix the FAIL by checking in the test-case whether addresses are at
"recommended breakpoint location" or not.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-05-04 Tom de Vries <tdevries@suse.de>
* gdb.base/async.exp: Check whether instruction addresses are a
"recommended breakpoint location".
|
|
I looked at all the calls to add_prefix_cmd, and replaced them with
calls to add_basic_prefix_cmd or add_show_prefix_cmd when appropriate.
This makes gdb's command language a bit more regular. I don't think
there's a significant downside.
Note that this patch removes a couple of tests. The removed ones are
completely redundant.
gdb/ChangeLog
2020-05-03 Tom Tromey <tom@tromey.com>
* breakpoint.c (catch_command, tcatch_command): Remove.
(_initialize_breakpoint): Use add_basic_prefix_cmd,
add_show_prefix_cmd.
(set_breakpoint_cmd, show_breakpoint_cmd): Remove
* utils.c (set_internal_problem_cmd, show_internal_problem_cmd):
Remove.
(add_internal_problem_command): Use add_basic_prefix_cmd,
add_show_prefix_cmd.
* mips-tdep.c (set_mipsfpu_command): Remove.
(_initialize_mips_tdep): Use add_basic_prefix_cmd.
* dwarf2/index-cache.c (set_index_cache_command): Remove.
(_initialize_index_cache): Use add_basic_prefix_cmd.
* memattr.c (dummy_cmd): Remove.
(_initialize_mem): Use add_basic_prefix_cmd, add_show_prefix_cmd.
* tui/tui-win.c (set_tui_cmd, show_tui_cmd): Remove.
(_initialize_tui_win): Use add_basic_prefix_cmd,
add_show_prefix_cmd.
* cli/cli-logging.c (set_logging_command): Remove.
(_initialize_cli_logging): Use add_basic_prefix_cmd,
add_show_prefix_cmd.
(show_logging_command): Remove.
* target.c (target_command): Remove.
(add_target): Use add_basic_prefix_cmd.
gdb/testsuite/ChangeLog
2020-05-03 Tom Tromey <tom@tromey.com>
* gdb.base/sepdebug.exp: Remove "catch" test.
* gdb.base/break.exp: Remove "catch" test.
* gdb.base/default.exp: Update expected output.
|
|
When running test-case gdb.arch/i386-mpx.exp with gcc-10, we get:
...
Running src/gdb/testsuite/gdb.arch/i386-mpx.exp ...
gdb compile failed, xgcc: warning: switch '-mmpx' is no longer supported
xgcc: warning: switch '-fcheck-pointer-bounds' is no longer supported
...
The test-case uses a combination of options, -mmpx and -fcheck-pointer-bounds.
The -fcheck-pointer-bounds option requires the -mmpx option:
...
$ gcc -fcheck-pointer-bounds ~/hello.c
hello.c:1:0: warning: Pointer Checker requires MPX support on this target. \
Use -mmpx options to enable MPX.
#include <stdio.h>
cc1: error: ‘-fcheck-pointer-bounds’ is not supported for this target
...
Both options is no longer supported in gcc-9.
Fix the warnings by testing if the option combination is supported.
Tested on x86_64-linux, with gcc-7.5.0 and gcc-10.0.1.
gdb/testsuite/ChangeLog:
2020-05-02 Tom de Vries <tdevries@suse.de>
* lib/gdb.exp (supports_mpx_check_pointer_bounds): New proc.
* gdb.arch/i386-mpx-call.exp: Use supports_mpx_check_pointer_bounds.
* gdb.arch/i386-mpx-map.exp: Same.
* gdb.arch/i386-mpx-sigsegv.exp: Same.
* gdb.arch/i386-mpx-simple_segv.exp: Same.
* gdb.arch/i386-mpx.exp: Same.
|
|
When running test-case gdb.base/psym-external-decl.exp with gcc-10, we have:
...
(gdb) print aaa^M
'aaa' has unknown type; cast it to its declared type^M
(gdb) FAIL: gdb.base/psym-external-decl.exp: print aaa
...
With an an earlier version, gcc still emits the debug info for the
declaration of aaa:
...
<0><d2>: Abbrev Number: 1 (DW_TAG_compile_unit)
<d8> DW_AT_name : psym-external-decl.c
<1><f4>: Abbrev Number: 2 (DW_TAG_variable)
<f5> DW_AT_name : aaa
<ff> DW_AT_external : 1
<ff> DW_AT_declaration : 1
...
but with gcc-10 that's no longer the case.
Fix the test-case by adding a use of aaa in psym-external-decl.c.
That still doesn't work for clang, so skip test in that case.
Tested with x86_64-linux, with gcc 7.5.0, gcc 10.0.0 and clang 5.0.2.
Also tested by reverting corresponding fix and ensuring test-case still
fails.
gdb/testsuite/ChangeLog:
2020-05-02 Tom de Vries <tdevries@suse.de>
* gdb.base/psym-external-decl.c (main): Add use of variable aaa.
|
|
When running test-case gdb.ada/operator_bp.exp with gcc-10, I run into:
...
FAIL: gdb.ada/operator_bp.exp: break "+"
FAIL: gdb.ada/operator_bp.exp: break "-"
FAIL: gdb.ada/operator_bp.exp: break "<"
FAIL: gdb.ada/operator_bp.exp: break "<="
FAIL: gdb.ada/operator_bp.exp: break ">"
FAIL: gdb.ada/operator_bp.exp: break ">="
FAIL: gdb.ada/operator_bp.exp: break "="
FAIL: gdb.ada/operator_bp.exp: break "and"
FAIL: gdb.ada/operator_bp.exp: break "or"
FAIL: gdb.ada/operator_bp.exp: break "xor"
FAIL: gdb.ada/operator_bp.exp: break "not"
...
The first FAIL is because two breakpoint locations are expected, but there are
more than 2:
...
(gdb) break "+"
Breakpoint 2 at 0x402c3c: "+". (6 locations)
(gdb) info break
Num Type Disp Enb Address What
2 breakpoint keep y <MULTIPLE>
2.1 y 0x0000000000402c3c in ops."+"
at operator_bp/ops.adb:25
2.2 y 0x0000000000402e5b in ops."+"
at operator_bp/ops.adb:119
2.3 y 0x0000000000414207 in
system.storage_elements."+" at s-stoele.adb:82
2.4 y 0x0000000000414404 in
system.storage_elements."+" at s-stoele.adb:87
2.5 y 0x0000000000414413 in
system.storage_elements."+" at s-stoele.adb:87
2.6 y 0x0000000000414430 in
system.storage_elements."+" at s-stoele.adb:81
...
This can be traced back to a extra debug info in the executable:
...
$ readelf -w ops_test | grep system__storage_elements__Oadd
<28104> DW_AT_name : system__storage_elements__Oadd__2
<2812e> DW_AT_name : system__storage_elements__Oadd
...
Fix the FAILs by allowing more than the required amount of breakpoint
locations.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-05-01 Tom de Vries <tdevries@suse.de>
* gdb.ada/operator_bp.exp: Allow more than required amount of
breakpoint.
|
|
When running test-case gdb.reverse/until-reverse.exp or
gdb.reverse/until-precsave.exp with gcc-10, we run into a Wunused-result
warning:
...
gdb compile failed, gdb.reverse/until-reverse.c: In function 'main':
gdb.reverse/until-reverse.c:40:14: warning: ignoring return value of \
'malloc' declared with attribute 'warn_unused_result' [-Wunused-result]
40 | (void) malloc (1);
| ^~~~~~~~~~
...
Fix this by using the result of malloc as argument to a free call.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-05-01 Tom de Vries <tdevries@suse.de>
* gdb.reverse/until-reverse.c (main): Fix Wunused-result warning.
|
|
Sizes of stubbed types are calculated on demand in check_typedef, so the
same must also be done for arrays of stubbed types.
A stubbed type is usually a structure that has only been forward declared,
but can also happen if the structure has a virtual function that's not
inline in the class definition.
For these stubbed types, the size must be recalculated once the full
definition is available.
gdb/ChangeLog:
2020-04-30 Hannes Domani <ssbssa@yahoo.de>
PR gdb/18706
* gdbtypes.c (check_typedef): Calculate size of array of
stubbed type.
gdb/testsuite/ChangeLog:
2020-04-30 Hannes Domani <ssbssa@yahoo.de>
PR gdb/18706
* gdb.cp/stub-array-size.cc: New test.
* gdb.cp/stub-array-size.exp: New file.
* gdb.cp/stub-array-size.h: New test.
* gdb.cp/stub-array-size2.cc: New test.
|
|
gdb/testsuite/ChangeLog:
2020-04-30 Hannes Domani <ssbssa@yahoo.de>
* gdb.python/py-format-string.exp: Adjust pretty_arrays expected
output to the new format.
|
|
These test names are duplicated:
2 PASS: gdb.base/break.exp: set breakpoint via non-integer convenience variable disallowed
2 PASS: gdb.base/break.exp: set convenience variable $foo to 81.5
Wrap them with `with_test_prefix`. I've actually wrapped a bit more
tests that are related, I think it helps to give the test names a bit
more context. The modified test names are:
-PASS: gdb.base/break.exp: set convenience variable $foo to bp_location11
-PASS: gdb.base/break.exp: set breakpoint via convenience variable
-PASS: gdb.base/break.exp: set convenience variable $foo to 81.5
-PASS: gdb.base/break.exp: set breakpoint via non-integer convenience variable disallowed
+PASS: gdb.base/break.exp: set line breakpoint via convenience variable: set convenience variable $foo to bp_location11
+PASS: gdb.base/break.exp: set line breakpoint via convenience variable: break $foo
+PASS: gdb.base/break.exp: set line breakpoint via convenience variable: set convenience variable $foo to 81.5
+PASS: gdb.base/break.exp: set line breakpoint via convenience variable: non-integer convenience variable disallowed
-PASS: gdb.base/break.exp: set $l = 47
-PASS: gdb.base/break.exp: break break.c:$l
-PASS: gdb.base/break.exp: set convenience variable $foo to 81.5
-PASS: gdb.base/break.exp: set breakpoint via non-integer convenience variable disallowed
+PASS: gdb.base/break.exp: set line:file breakpoint via convenience variable: set $l = 47
+PASS: gdb.base/break.exp: set line:file breakpoint via convenience variable: break break.c:$l
+PASS: gdb.base/break.exp: set line:file breakpoint via convenience variable: set convenience variable $foo to 81.5
+PASS: gdb.base/break.exp: set line:file breakpoint via convenience variable: non-integer convenience variable disallowed
gdb/testsuite/ChangeLog:
* gdb.base/break.exp: Use with_test_prefix.
|
|
With target board debug-types, we have these FAILs:
...
FAIL: gdb.guile/scm-symtab.exp: test simple_struct in static symbols
FAIL: gdb.python/py-symtab.exp: test simple_struct in static symbols
...
due to PR gcc/90232, as explained in commit 15cd93d05e8 "[gdb/symtab] Handle
struct decl with DW_AT_signature".
Marks these as XFAILs.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-04-29 Tom de Vries <tdevries@suse.de>
* lib/gdb.exp (debug_types): New proc.
* gdb.guile/scm-symtab.exp: Add xfail for PR gcc/90232.
* gdb.python/py-symtab.exp: Same.
|
|
Currently, printing with array pretty formatting makes the output actually
less readable than without:
(gdb) p -array on -- {{1,2,3},{4,5,6}}
$1 = { {1,
2,
3},
{4,
5,
6}}
(gdb) p -array on -array-indexes on -- {{1,2,3},{4,5,6}}
$2 = {[0] = {[0] = 1,
[1] = 2,
[2] = 3},
[1] = {[0] = 4,
[1] = 5,
[2] = 6}}
These changes now also put the first element and the array end bracket on a new
line, similar to the structure pretty formatter:
(gdb) p -array on -- {{1,2,3},{4,5,6}}
$1 = {
{
1,
2,
3
},
{
4,
5,
6
}
}
(gdb) p -array on -array-indexes on -- {{1,2,3},{4,5,6}}
$2 = {
[0] = {
[0] = 1,
[1] = 2,
[2] = 3
},
[1] = {
[0] = 4,
[1] = 5,
[2] = 6
}
}
gdb/ChangeLog:
2020-04-29 Hannes Domani <ssbssa@yahoo.de>
PR gdb/17320
* ada-valprint.c (val_print_packed_array_elements): Move array
end bracket to new line.
(ada_val_print_string): Remove extra spaces before first array
element.
* c-valprint.c (c_value_print_array): Likewise.
* m2-valprint.c (m2_print_array_contents): Likewise.
(m2_value_print_inner): Likewise.
* p-valprint.c (pascal_value_print_inner): Likewise.
* valprint.c (generic_val_print_array): Likewise.
(value_print_array_elements): Move first array element and array
end bracket to new line.
gdb/testsuite/ChangeLog:
2020-04-29 Hannes Domani <ssbssa@yahoo.de>
PR gdb/17320
* gdb.base/pretty-array.c: New test.
* gdb.base/pretty-array.exp: New file.
|
|
With target board debug-types, we have:
...
FAIL: gdb.cp/cpexprs.exp: list policy1::function
...
This is a regression triggered by commit 770479f223e "gdb: Fix toplevel types
with -fdebug-types-section".
However, the FAIL is caused by commit 4dedf84da98 "Change
decode_compound_collector to use std::vector" which changes a VEC_iterate loop
into a range loop:
...
- for (ix = 0; VEC_iterate (symbolp, sym_classes, ix, sym); ++ix)
+ unsigned int ix = 0;
+ for (const auto &sym : *sym_classes)
...
but fails to ensure that the increment of ix happens every iteration.
Fix this by calculating the index variable at the start of the loop body:
...
for (const auto &elt : *sym_classes)
{
unsigned int ix = &elt - &*sym_classes->begin ();
...
Tested on x86_64-linux, with native and target board debug-types.
gdb/ChangeLog:
2020-04-29 Tom de Vries <tdevries@suse.de>
PR symtab/25889
* linespec.c (find_method): Fix ix calculation.
gdb/testsuite/ChangeLog:
2020-04-29 Tom de Vries <tdevries@suse.de>
PR symtab/25889
* gdb.cp/cpexprs.exp: Adapt for inclusion.
* gdb.cp/cpexprs-debug-types.exp: New file. Set -fdebug-types-section
and include cpexprs.exp.
|
|
|
|
When debugging a program compiled with -fdebug-types-section,
only the first top-level type in each file is visible to gdb.
The problem was caused by moving the assignment to list_in_scope
from process_full_comp_unit and process_full_type_unit to
start_symtab. This was fine for process_full_comp_unit, because
symtabs and comp units are one-to-one. But there can be many type
units per symtab (one for each type), and we only call start_symtab
for the first one. This adds the necessary assignments on the paths
where start_symtab is not called.
gdb/Changelog:
2020-04-28 Mark Williams <mark@myosotissp.com>
PR gdb/24480
* dwarf2read.c: Add missing assingments to list_in_scope when
start_symtab was already called.
gdb/testsuite/Changelog:
2020-04-28 Mark Williams <mark@myosotissp.com>
PR gdb/24480
* dw4-toplevel-types.exp: Test for top level types.
* dw4-toplevel-types.cc: Test for top level types.
|
|
gdb/stubs/ChangeLog:
2020-04-28 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* ia64vms-stub.c: Fix typo in comment (thead -> thread).
gdb/testsuite/ChangeLog:
2020-04-28 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* gdb.threads/stop-with-handle.exp: Fix typo in comment
(theads -> threads).
gdbsupport/ChangeLog:
2020-04-28 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* gdb-sigmask.h: Fix typo (pthead_sigmask -> pthread_sigmask).
|
|
With test-case gdb.opt/inline-cmds.exp, we have:
...
KFAIL: gdb.opt/inline-cmds.exp: next to second func1 (PRMS: gdb/NNNN)
...
I've filed PR25884 for this failure.
Set the KFAIL PR accordingly.
gdb/testsuite/ChangeLog:
2020-04-28 Tom de Vries <tdevries@suse.de>
* gdb.opt/inline-cmds.exp: Set KFAIL PR.
|
|
When running test-case gdb.base/info-macros.exp, we have:
...
(gdb) KFAIL: gdb.base/info-macros.exp: info macros info-macros.c:42 \
(PRMS: gdb/NNNN)
...
The described failure mode however:
...
set test "info macros info-macros.c:42"
set r1 ".*define DEF_MACROS"
set r2 ".*define ONE"
setup_kfail "gdb/NNNN" *-*-*
gdb_test "$test" "$r1$r2"
...
does not match the actual output, given that both defines are in fact
printed.
The pattern fails to match because it's missing a trailing ".*".
Fix this by removing the KFAIL and adding the missing trailing ".*".
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-04-28 Tom de Vries <tdevries@suse.de>
* gdb.base/info-macros.exp: Remove KFAIL. Add missing trailing ".*".
|
|
When running test-case gdb.ada/array_ptr_renaming.exp we run into:
...
(gdb) print ntp^M
$3 = (3 => 30, 40)^M
(gdb) KFAIL: gdb.ada/array_ptr_renaming.exp: print ntp (PRMS: gdb/NNNN)
...
I've opened PR25883 for this failure. Reference the PR from the KFAIL, such
that we have:
...
KFAIL: gdb.ada/array_ptr_renaming.exp: print ntp (PRMS: gdb/25883)
...
gdb/testsuite/ChangeLog:
2020-04-28 Tom de Vries <tdevries@suse.de>
* gdb.ada/array_ptr_renaming.exp: Add PR number in KFAIL.
|
|
Consider a test-case with sources 36.c:
...
struct s { int i; };
extern void f (void);
int main (void) {
struct s a;
f ();
return 0;
}
...
and 36b.c:
...
struct s { int j; };
void f (void) {
struct s b;
}
...
compiled like this:
...
$ gcc 36.c 36b.c -g
...
It contains DWARF like this:
...
<0><d2>: Abbrev Number: 1 (DW_TAG_compile_unit)
<d8> DW_AT_name : 36.c
<1><f4>: Abbrev Number: 2 (DW_TAG_structure_type)
<f5> DW_AT_name : s
<2><fe>: Abbrev Number: 3 (DW_TAG_member)
<ff> DW_AT_name : i
<1><110>: Abbrev Number: 5 (DW_TAG_subprogram)
<111> DW_AT_name : main
<2><12d>: Abbrev Number: 6 (DW_TAG_variable)
<12e> DW_AT_name : a
<132> DW_AT_type : <0xf4>
<0><146>: Abbrev Number: 1 (DW_TAG_compile_unit)
<14c> DW_AT_name : 36b.c
<1><168>: Abbrev Number: 2 (DW_TAG_structure_type)
<169> DW_AT_name : s
<2><172>: Abbrev Number: 3 (DW_TAG_member)
<173> DW_AT_name : j
<1><184>: Abbrev Number: 5 (DW_TAG_subprogram)
<185> DW_AT_name : f
<2><19b>: Abbrev Number: 6 (DW_TAG_variable)
<19c> DW_AT_name : b
<1a0> DW_AT_type : <0x168>
...
And when printing "struct s", we get first a random one (with int j), and then
context-specific ones (with int i in main, and int j in f):
...
$ gdb -batch a.out \
-ex "ptype struct s" \
-ex start \
-ex "ptype struct s" \
-ex "break f" -ex continue \
-ex "ptype struct s" \
| grep "int [ij];"
int j;
int i;
int j;
...
Same for -readnow.
However, if we use -fdebug-types-section:
...
$ gcc 36.c 36b.c -g -fdebug-types-section
...
we get:
...
$ gdb ... | grep "int [ij];"
int j;
int i;
int i;
$ gdb -readnow ... | grep "int [ij];"
int j;
int j;
int j;
...
This is due to the fact that both "struct s" DIEs have been moved to the
.debug_types section:
...
Compilation Unit @ offset 0x0:
Signature: 0xfd1462823bb6f7b7
<0><17>: Abbrev Number: 1 (DW_TAG_type_unit)
<1><1d>: Abbrev Number: 2 (DW_TAG_structure_type)
<1e> DW_AT_name : s
<2><27>: Abbrev Number: 3 (DW_TAG_member)
<28> DW_AT_name : i
Compilation Unit @ offset 0x3a:
Signature: 0x534310fbefba324d
<0><51>: Abbrev Number: 1 (DW_TAG_type_unit)
<1><57>: Abbrev Number: 2 (DW_TAG_structure_type)
<58> DW_AT_name : s
<2><61>: Abbrev Number: 3 (DW_TAG_member)
<62> DW_AT_name : j
...
and there's no longer a "struct s" DIE in the 36.c and
and 36b.c CUs to specify which "struct s" belongs in the CU. This is gcc
PR90232.
However, using a tentative patch for gcc that adds these DIEs (according to
DWARF standard: If the complete declaration of a type has been placed in a
separate type unit, an incomplete declaration of that type in the compilation
unit may provide the unique 64-bit signature of the type using a
DW_AT_signature attribute):
...
<0><d2>: Abbrev Number: 5 (DW_TAG_compile_unit)
<d8> DW_AT_name : 36.c
+ <1><f4>: Abbrev Number: 6 (DW_TAG_structure_type)
+ <f5> DW_AT_name : s
+ <f7> DW_AT_signature : signature: 0xfd1462823bb6f7b7
+ <ff> DW_AT_declaration : 1
<0><13c>: Abbrev Number: 5 (DW_TAG_compile_unit)
<142> DW_AT_name : 36b.c
+ <1><15e>: Abbrev Number: 6 (DW_TAG_structure_type)
+ <15f> DW_AT_name : s
+ <161> DW_AT_signature : signature: 0x534310fbefba324d
+ <169> DW_AT_declaration : 1
...
still does not help, because they're declarations, so new_symbol is not called
for them in process_structure_scope.
Fix this by calling new_symbol for these decls.
Build and tested on x86_64-linux.
Also tested with target board enabling by default -fdebug-types-section
-gdwarf-4, and with gcc with aforementioned tentative patch. In this
configuration, the patch reduces number of FAILs from 2888 to 238.
gdb/ChangeLog:
2020-04-28 Tom de Vries <tdevries@suse.de>
* dwarf2/read.c (process_structure_scope): Add symbol for struct decl
with DW_AT_signature.
gdb/testsuite/ChangeLog:
2020-04-28 Tom de Vries <tdevries@suse.de>
* gdb.dwarf2/main-foo.c: New test.
* gdb.dwarf2/struct-with-sig.exp: New file.
|
|
This patch adds a target board debug-types that switches on
-fdebug-types-section by default.
This -fdebug-types-section option is a gcc option that enables the generation
of a .debug_types section, which is only effective for DWARF version 4.
There are two other boards that enable this: dwarf4-gdb-index and fisson, but
while those test some meaningful combination of options, this board is
intended to test only -fdebug-types-section.
Current results with gcc 7.5.0 are:
...
=== gdb Summary ===
# of expected passes 75832
# of unexpected failures 2841
# of expected failures 130
# of known failures 75
# of unresolved testcases 22
# of untested testcases 37
# of unsupported tests 83
...
Related known issues:
- PR gcc/90232 - "gcc drops top-level dies with -fdebug-types-section"
- PR gdb/25875 - "segv in ada_discrete_type_low_bound"
- PR gdb/14148 - "-fdebug-types-section regresses static scope of types"
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-04-25 Tom de Vries <tdevries@suse.de>
* boards/debug-types.exp: New file.
|
|
Having paths in test names makes it harder to compare results from
different builds of GDB.
gdb/testsuite/ChangeLog:
* gdb.btrace/multi-inferior.exp: Avoid paths in test names.
|
|
The DWARF reader has had some odd code since the "physname" patches landed.
In particular, these patches caused PR symtab/12707; namely, they made
it so "set print demangle off" no longer works.
This patch attempts to fix the problem. It arranges to store the
linkage name on the symbol if it exists, and it changes the DWARF
reader so that the demangled name is no longer (usually) stored in the
symbol's "linkage name" field.
c-linkage-name.exp needed a tweak, because it started working
correctly. This conforms to what I think ought to happen, so this
seems like an improvement here.
compile-object-load.c needed a small change to use
symbol_matches_search_name rather than directly examining the linkage
name. Looking directly at the name does the wrong thing for C++.
There is still some name-related confusion in the DWARF reader:
* "physname" often refers to the logical name and not what I would
consider to be the "physical" name;
* dwarf2_full_name, dwarf2_name, and dwarf2_physname all exist and
return different strings -- but this seems like at least one name
too many. For example, Fortran requires dwarf2_full_name, but other
languages do not.
* To my surprise, dwarf2_physname prefers the form emitted by the
demangler over the one that it computes. This seems backward to me,
given that the partial symbol reader prefers the opposite, and it
seems to me that this choice may perform better as well.
I didn't attempt to clean up these things. It would be good to do,
but whenever I contemplate it I get caught up in dreams of truly
rewriting the DWARF reader instead.
gdb/ChangeLog
2020-04-24 Tom Tromey <tom@tromey.com>
PR symtab/12707:
* dwarf2/read.c (add_partial_symbol): Use the linkage name if it
exists.
(new_symbol): Likewise.
* compile/compile-object-load.c (get_out_value_type): Use
symbol_matches_search_name.
gdb/testsuite/ChangeLog
2020-04-24 Tom Tromey <tom@tromey.com>
PR symtab/12707:
* gdb.python/py-symbol.exp: Update expected results for
linkage_name test.
* gdb.cp/print-demangle.exp: New file.
* gdb.base/c-linkage-name.exp: Fix test.
* gdb.guile/scm-symbol.exp: Update expected results for
linkage_name test.
|
|
As mentioned in another thread, there's currently no need to call
compute_and_set_names for partial symbols. Because the DWARF partial
symbol reader constructs demangled names, this call can only demangle
a name by mistake.
So, this patch changes the DWARF reader to simply set the linkage name
on the new symbol. This is equivalent to what was done before. There
should be no user-visible change from this patch, aside from gdb
speeding up a bit.
... there *should* be, but this regressed
dw2-namespaceless-anonymous.exp. However, upon examination, I think
that test is incorrect. It puts a mangled name into DW_AT_name, and
it puts the variable at the top level, not in a namespace. This isn't
what C++ compilers ought to do. So, this patch also updates the test
case.
gdb/ChangeLog
2020-04-24 Tom Tromey <tom@tromey.com>
* dwarf2/read.c (add_partial_symbol): Do not call
compute_and_set_names.
gdb/testsuite/ChangeLog
2020-04-24 Tom Tromey <tom@tromey.com>
* gdb.dwarf2/dw2-namespaceless-anonymous.S: Remove.
* gdb.dwarf2/dw2-namespaceless-anonymous.c: New file.
* gdb.dwarf2/dw2-namespaceless-anonymous.exp: Use DWARF
assembler.
|
|
The test-case gdb.dwarf2/dw2-bad-mips-linkage-name.exp has a CU with
language C, which contains a subprogram with a C++-mangled name as its
DW_AT_mips_linkage_name attribute.
Fix this by changing the language of the CU to C++.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-04-24 Tom de Vries <tdevries@suse.de>
* gdb.dwarf2/dw2-bad-mips-linkage-name.exp: Set language of CU to
C++.
|
|
Some test cases already work fine with minimal encodings (in some
cases perhaps due to the variant parts series) This patch updates
these tests as appropriate.
gdb/testsuite/ChangeLog
2020-04-24 Tom Tromey <tromey@adacore.com>
* gdb.ada/frame_arg_lang.exp: Run with multiple -fgnat-encodings
values.
* gdb.ada/funcall_ref.exp: Run with multiple -fgnat-encodings
values. Update test for minimal encodings.
* gdb.ada/lang_switch.exp: Update test for minimal encodings.
* gdb.ada/var_rec_arr.exp: Run with multiple -fgnat-encodings
values. Update test for minimal encodings.
|
|
This changes the gdb Python API to add support for dynamic types. In
particular, this adds an attribute to gdb.Type, and updates some
attributes to reflect dynamic sizes and field offsets.
There's still no way to get the dynamic type from one of its concrete
instances. This could perhaps be added if needed.
gdb/ChangeLog
2020-04-24 Tom Tromey <tromey@adacore.com>
PR python/23662:
* python/py-type.c (convert_field): Handle
FIELD_LOC_KIND_DWARF_BLOCK.
(typy_get_sizeof): Handle TYPE_HAS_DYNAMIC_LENGTH.
(typy_get_dynamic): Nw function.
(type_object_getset): Add "dynamic".
* NEWS: Add entry.
gdb/doc/ChangeLog
2020-04-24 Tom Tromey <tromey@adacore.com>
PR python/23662:
* python.texi (Types In Python): Document new features.
gdb/testsuite/ChangeLog
2020-04-24 Tom Tromey <tromey@adacore.com>
PR python/23662:
* gdb.ada/variant.exp: Add Python checks.
* gdb.rust/simple.exp: Add dynamic type checks.
|
|
The previous patches largely came without test cases. This was done
to make the patches easier to review; as most of the patches were
needed before existing tests could be updated.
This patch adds a new test and updates some existing tests to test all
the settings of -fgnat-encodings. This ensures that tests are run
both with the old-style "magic symbol name" encoding, and the
new-style DWARF encoding.
Note that in one case, a test is modified to be more lax. See the
comment in mi_var_array.exp. I didn't want to fix this in this
series, as it's already complicated enough. However, I think it could
be fixed; I will file a bug for it.
gdb/testsuite/ChangeLog
2020-04-24 Tom Tromey <tromey@adacore.com>
* gdb.ada/mi_var_array.exp: Try all -fgnat-encodings settings.
Make array type matching more lax.
* gdb.ada/mi_var_union.exp: Try all -fgnat-encodings settings.
* gdb.ada/mi_variant.exp: New file.
* gdb.ada/mi_variant/pck.ads: New file.
* gdb.ada/mi_variant/pkg.adb: New file.
* gdb.ada/packed_tagged.exp: Try all -fgnat-encodings settings.
* gdb.ada/unchecked_union.exp: Try all -fgnat-encodings settings.
|
|
In Ada, a field can have a variable offset. This patch adds support
for this case to gdb, using the existing dynamic type resolution code.
Doing just this, though, would break C++ virtual base handling.
It turns out that virtual base handling only worked by the ugliest of
hacks. In particular, the DWARF reader would call decode_locdesc for
a virtual base location. Here's an example of such an expression from
gdb's m-static test case:
<241> DW_AT_data_member_location: 6 byte block: 12 6 48 1c 6 22 (DW_OP_dup; DW_OP_deref; DW_OP_lit24; DW_OP_minus; DW_OP_deref; DW_OP_plus)
When examining this, decode_locdesc would treat DW_OP_deref as a no-op
and compute some answer (here, -24). This would be stored as the
offset.
Later, in gnu-v3-abi.c, the real offset would be computed by digging
around in the vtable.
This patch cleans up this area. In particular, it now evaluates the
location expression on demand.
Note there is a new FIXME in gnu-v3-abi.c. I think some of the
callers are incorrect here, and have only worked because this member
is unused. I will file a bug for this. I didn't fix this problem in
this series because I felt it was already too complex.
gdb/ChangeLog
2020-04-24 Tom Tromey <tromey@adacore.com>
* dwarf2/read.c (handle_data_member_location): New overload.
(dwarf2_add_field): Use it.
(decode_locdesc): Add "computed" parameter. Update comment.
* gdbtypes.c (is_dynamic_type_internal): Also look for
FIELD_LOC_KIND_DWARF_BLOCK.
(resolve_dynamic_struct): Handle FIELD_LOC_KIND_DWARF_BLOCK.
* gdbtypes.c (is_dynamic_type_internal): Add special case for C++
virtual base classes.
* gnu-v3-abi.c (gnuv3_baseclass_offset): Handle
FIELD_LOC_KIND_DWARF_BLOCK.
gdb/testsuite/ChangeLog
2020-04-24 Tom Tromey <tromey@adacore.com>
* gdb.ada/variant.exp: Add dynamic field offset tests.
* gdb.ada/variant/pck.ads (Nested_And_Variable): New type.
* gdb.ada/variant/pkg.adb: Add new variables.
|
|
In Ada, a type with variant parts can have a variable length. This
patch adds support for this to gdb, by integrating the length
computation into the dynamic type resolution code.
gdb/ChangeLog
2020-04-24 Tom Tromey <tromey@adacore.com>
* dwarf2/read.c (read_structure_type): Handle dynamic length.
* gdbtypes.c (is_dynamic_type_internal): Check
TYPE_HAS_DYNAMIC_LENGTH.
(resolve_dynamic_type_internal): Use TYPE_DYNAMIC_LENGTH.
* gdbtypes.h (TYPE_HAS_DYNAMIC_LENGTH, TYPE_DYNAMIC_LENGTH):
New macros.
(enum dynamic_prop_node_kind) <DYN_PROP_BYTE_SIZE>: New
constant.
gdb/testsuite/ChangeLog
2020-04-24 Tom Tromey <tromey@adacore.com>
* gdb.ada/variant.exp: New file
* gdb.ada/variant/pkg.adb: New file
* gdb.ada/variant/pck.adb: New file
|
|
When running test-case gdb.base/readnever.exp without commit 96038148d0e
"[gdb/testsuite] Skip gdb.base/readnever.exp with target board readnow", we
run into an error:
...
ERROR: (eof) GDB never initialized.
testcase gdb/testsuite/gdb.base/readnever.exp completed in 0 seconds
...
If we additionally run test-case gdb.base/realname-expand.exp, we get an
unresolved for the first test:
...
UNRESOLVED: gdb.base/realname-expand.exp: set basenames-may-differ on
...
Using -v we find out that the UNRESOLVED is due the error triggered in the
previous test-case:
...
(gdb) set basenames-may-differ on^M
(gdb) Error/Warning threshold exceeded: 1 0 (max. 1 3)
UNRESOLVED: gdb.base/realname-expand.exp: set basenames-may-differ on
...
So, the error count of one test spills into the next test, even though we do a
clean restart. That seems like a bad idea.
Fix this by resetting errcnt (as well as warncnt) in clean_restart, such that
we have:
...
Running src/gdb/testsuite/gdb.base/readnever.exp ...
ERROR: (eof) GDB never initialized.
Running src/gdb/testsuite/gdb.base/realname-expand.exp ...
PASS: gdb.base/realname-expand.exp: set basenames-may-differ on
...
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-04-24 Tom de Vries <tdevries@suse.de>
* lib/gdb.exp (clean_restart): Reset errcnt and warncnt.
|
|
When running test-case gdb.dwarf2/dwzbuildid.exp with target board
cc-with-gdb-index, we have:
...
Running src/gdb/testsuite/gdb.dwarf2/dwzbuildid.exp ...
gdb compile failed, warning: File "dwzbuildid5.o" has a different \
build-id, file skipped
could not find '.gnu_debugaltlink' file for dwzbuildid-mismatch
warning: File "dwzbuildid5.o" has a different build-id, file skipped
Error while writing index for `dwzbuildid-mismatch': could not find \
'.gnu_debugaltlink' file for dwzbuildid-mismatch
...
and likewise for target board cc-with-debug-names.
These are gdb-add-index warnings and errors due to the executable
dwzbuildid-mismatch having a build-id mismatch.
Be less verbose by adding "quiet" to the compile flags.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-04-24 Tom de Vries <tdevries@suse.de>
* gdb.dwarf2/dwzbuildid.exp: Add quiet to dwzbuildid-mismatch compile
flags.
|
|
When running test-case gdb.dwarf2/dw2-error.exp with target board
cc-with-gdb-index, we get:
...
Running src/gdb/testsuite/gdb.dwarf2/dw2-error.exp ...
gdb compile failed, Dwarf Error: wrong version in compilation unit header \
(is 153, should be 2, 3, 4 or 5) [in module \
build/gdb/testsuite/outputs/gdb.dwarf2/dw2-error/.tmp/dw2-error]
...
and similar for target board cc-with-debug-names.
Be less verbose by adding "quiet" to the compile flags.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-04-24 Tom de Vries <tdevries@suse.de>
* gdb.dwarf2/dw2-error.exp: Add quiet to compile flags.
|
|
When running test-case gdb.base/readnever.exp with target board readnow, and
without commit 96038148d0e "[gdb/testsuite] Skip gdb.base/readnever.exp with
target board readnow", we run into a bunch of errors, starting with:
...
spawn gdb -nw -nx -data-directory data-directory -ex set sysroot -readnow \
--readnever^M
gdb: '--readnow' and '--readnever' cannot be specified simultaneously^M
ERROR: : spawn id exp9 not open
while executing
"expect {
-i exp9 -timeout 10
-re "$gdb_prompt $" {
verbose "Setting height to 0." 2
}
...
The illegal combination of --readnow and --readnever causes gdb to start,
print an error message and exit. There's a gdb_expect in default_gdb_start
that is supposed to detect the initial gdb prompt and handle related problems,
but since there's no eof case it succeeds, and default_gdb_start continues as
if the gdb prompt had been detected, causing the error above.
Fix this by adding an eof case to the gdb_expect, such that we have the more
accurate:
...
ERROR: (eof) GDB never initialized.
...
Further errors are triggered in clean_restart, because we're not testing for
gdb_start success. Fix this by detecting gdb_start failure, and bailing out.
Finally, we're running into further errors in gdb.base/readnever.exp because
we're not testing for clean_restart success. Fix this by making clean_restart
return -1 upon error, and testing for this.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-04-24 Tom de Vries <tdevries@suse.de>
* lib/gdb.exp (default_gdb_start): Handle eof.
(clean_restart): Detect and handle gdb_start failure. Return -1 upon
failure.
* gdb.base/readnever.exp: Handle clean_restart failure.
|
|
This is a follow-up patch on "[PATCH][gdb/symtab] Prefer def over decl
(inter-CU case)" (
https://sourceware.org/pipermail/gdb-patches/2020-April/167489.html ).
Consider the test-case from that patch. It contains a decl and def of var a
in different CUs, and tests whether var a can be printed using the def, even
if the decl is found first.
However, the test-case does this in a contextless environment, so if we add to
the test-case like this to set the context to the CU containing main:
...
gdb_test "p a" { = \{1, 2\}}
+
+if ![runto_main] then {
+ fail "can't run to main"
+ return 0
+}
+
+gdb_test "p a" { = \{1, 2\}}
...
then the second test fails, because the decl is found in the context.
Fix this by preferring defs over decls in lookup_global_symbol.
Build and reg-tested on x86_64-linux.
gdb/ChangeLog:
2020-04-23 Tom de Vries <tdevries@suse.de>
* symtab.c (lookup_global_symbol): Prefer def over decl.
gdb/testsuite/ChangeLog:
2020-04-23 Tom de Vries <tdevries@suse.de>
* gdb.base/decl-before-def.exp: Run to main and print a again.
|
|
When running test-case gdb.threads/tls.exp with target board -readnow, we
have:
...
(gdb) print a_thread_local^M
Cannot find thread-local storage for process 0, executable file tls/tls:^M
Cannot find thread-local variables on this target^M
(gdb) FAIL: gdb.threads/tls.exp: print a_thread_local
...
while with native we have:
...
(gdb) print a_thread_local^M
Cannot read `a_thread_local' without registers^M
(gdb) PASS: gdb.threads/tls.exp: print a_thread_local
...
The difference in behaviour can be explained as follows. Without -readnow, we
have two a_thread_locals, the def and the decl, each in a different CU:
...
$ gdb -batch outputs/gdb.threads/tls/tls \
-ex "maint expand-symtabs" \
-ex "print a_thread_local" \
-ex "maint print symbols" \
| grep "a_thread_local;"
Cannot read `a_thread_local' without registers
int a_thread_local; computed at runtime
int a_thread_local; unresolved
...
and with -readnow, we have the opposite order:
...
$ gdb -readnow -batch outputs/gdb.threads/tls/tls \
-ex "maint expand-symtabs" \
-ex "print a_thread_local" \
-ex "maint print symbols" \
| grep "a_thread_local;"
Cannot find thread-local storage for process 0, executable file tls/tls:
Cannot find thread-local variables on this target
int a_thread_local; unresolved
int a_thread_local; computed at runtime
...
Fix the FAIL by preferring the def over the decl (something we already do
intra-CU since the fix for PR24971, commit 93e55f0a03 "[gdb/symtab] Prefer var
def over decl").
Build and reg-tested on x86_64-linux.
gdb/ChangeLog:
2020-04-23 Tom de Vries <tdevries@suse.de>
PR symtab/25807
* block.c (best_symbol, better_symbol): Promote to external.
* block.h (best_symbol, better_symbol): Declare.
* symtab.c (lookup_symbol_in_objfile_symtabs): Prefer def over
decl.
gdb/testsuite/ChangeLog:
2020-04-23 Tom de Vries <tdevries@suse.de>
* gdb.base/decl-before-def-decl.c: New test.
* gdb.base/decl-before-def-def.c: New test.
* gdb.base/decl-before-def.exp: New file.
|
|
When running test-case gdb.base/readnever.exp with target board readnow, we
have:
...
spawn gdb -nw -nx -data-directory data-directory -ex set sysroot -readnow \
--readnever^M
gdb: '--readnow' and '--readnever' cannot be specified simultaneously^M
ERROR: : spawn id exp19 not open
...
Fix this by skipping the test when -readnow/--readnow is detected in
GDBFLAGS.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-04-23 Tom de Vries <tdevries@suse.de>
* gdb.base/readnever.exp: Skip if GDBFLAGS contain -readnow/--readnow.
|
|
While investigating PR25862 (an assertion failure with target board
cc-with-debug-names), I noticed that the .debug_aranges section in
gdb.mi/dw2-ref-missing-frame-func.c contains a hardcoded 0:
...
" .4byte 0 \n" // .Ldebug_info0 - Offset of Compilation Unit Info
...
So when looking for an address in the range 0x4004a7-0x4004bf, we should find
the CU at 0xc7:
...
Compilation Unit @ offset 0xc7:
Length: 0xba (32-bit)
Version: 2
Abbrev Offset: 0x64
Pointer Size: 4
<0><d2>: Abbrev Number: 1 (DW_TAG_compile_unit)
<d3> DW_AT_high_pc : 0x4004bf
<d7> DW_AT_low_pc : 0x4004a7
<db> DW_AT_name : file1.txt
<e5> DW_AT_producer : GNU C 3.3.3
<f1> DW_AT_language : 1 (ANSI C)
...
but instead the .debug_aranges entry points us to the CU at 0x0:
...
Length: 28
Version: 2
Offset into .debug_info: 0x0
Pointer Size: 4
Segment Size: 0
Address Length
004004a7 00000018
00000000 00000000
...
Fix this by using a label to refer to the start of the CU, similar to how
that's done for gdb.dlang/watch-loc.c in the fix for PR24522:
...
" .4byte .Lcu1_begin\n" // .Ldebug_info0 - Offset of Compilation Unit Info
...
The label marks the start of the empty .debug_info section for
dw2-ref-missing-frame-func.c, which is supposed to merge with the .debug_info
section in dw2-ref-missing-frame.S, so in order for that to work, we need to
make sure dw2-ref-missing-frame-func.o comes before dw2-ref-missing-frame.o in
the link line.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-04-22 Tom de Vries <tdevries@suse.de>
* gdb.mi/dw2-ref-missing-frame-func.c (.debug_aranges): Fix
debug_info_offset.
* gdb.mi/dw2-ref-missing-frame.exp: Make sure $objfuncfile comes
before $objsfile in the line line.
|
|
While investigating PR25862 (an assertion failure with target board
cc-with-debug-names), I noticed that the .debug_aranges section in
gdb.dlang/watch-loc.c contains a hardcoded 0x1000:
...
" .4byte _Dmain \n" // Address
" .4byte 0x1000 \n" // Length
...
Fix this by using the actual length of _Dmain, along the lines of how that
is done in gdb.mi/dw2-ref-missing-frame-func.c:
...
" .4byte _Dmain_end - _Dmain \n" // Length
...
such that the .debug_aranges entry:
...
Address Length
004004a7 0000000b
00000000 00000000
...
matches the addresses found in the corresponding CU:
...
<2><fd>: Abbrev Number: 6 (DW_TAG_subprogram)
<fe> DW_AT_name : _Dmain
<105> DW_AT_low_pc : 0x4004a7
<10d> DW_AT_high_pc : 0x4004b2
...
With this fix the assertion failure is no longer triggered for
gdb.dlang/watch-loc.exp.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-04-22 Tom de Vries <tdevries@suse.de>
* gdb.dlang/watch-loc.c (.debug_aranges): Fix _Dmain length.
|
|
|
|
Consider a test-case consisting of source file test.c:
...
extern int aaa;
int
main (void)
{
return 0;
}
...
and test-2.c:
...
int aaa = 33;
...
compiled with debug info only for test.c:
...
$ gcc -c test.c -g; gcc -c test2.c; gcc test.o test2.o -g
...
When trying to print aaa, we get:
...
$ gdb -batch a.out -ex "print aaa"
'aaa' has unknown type; cast it to its declared type
...
but with -readnow we have:
...
$ gdb -readnow -batch a.out -ex "print aaa"
$1 = 33
...
In the -readnow case, the symbol for aaa in the full symtab has
LOC_UNRESOLVED, and the symbol type is combined with the minimal symbol
address, to read the value and print it without cast.
Without the -readnow, we create partial symbols, but the aaa decl is missing
from the partial symtabs, so we find it only in the minimal symbols, resulting
in the cast request. If the aaa decl would have been in the partial symtabs,
it would have been found, and the full symtab would have been expanded, after
which things would be as with -readnow.
The function add_partial_symbol has a comment on the LOC_UNRESOLVED +
minimal symbol addres construct at DW_TAG_variable handling:
...
else if (pdi->is_external)
{
/* Global Variable.
Don't enter into the minimal symbol tables as there is
a minimal symbol table entry from the ELF symbols already.
Enter into partial symbol table if it has a location
descriptor or a type.
If the location descriptor is missing, new_symbol will create
a LOC_UNRESOLVED symbol, the address of the variable will then
be determined from the minimal symbol table whenever the variable
is referenced.
...
but it's not triggered due to this test in scan_partial_symbols:
...
case DW_TAG_variable:
...
if (!pdi->is_declaration)
{
add_partial_symbol (pdi, cu);
}
...
Fix this in scan_partial_symbols by allowing external variable decls to be
added to the partial symtabs.
Build and reg-tested on x86_64-linux.
The patch caused this regression:
...
(gdb) print a_thread_local^M
Cannot find thread-local storage for process 0, executable file tls/tls:^M
Cannot find thread-local variables on this target^M
(gdb) FAIL: gdb.threads/tls.exp: print a_thread_local
...
while without the patch we have:
...
(gdb) print a_thread_local^M
Cannot read `a_thread_local' without registers^M
(gdb) PASS: gdb.threads/tls.exp: print a_thread_local
...
However, without the patch but with -readnow we have the same FAIL as with the
patch (filed as PR25807). In other words, the patch has the effect that we
get the same result with and without -readnow.
This can be explained as follows. Without the patch, and without -readnow, we
have two a_thread_locals, the def and the decl:
...
$ gdb -batch outputs/gdb.threads/tls/tls \
-ex "maint expand-symtabs" \
-ex "print a_thread_local" \
-ex "maint print symbols" \
| grep "a_thread_local;"
Cannot read `a_thread_local' without registers
int a_thread_local; computed at runtime
int a_thread_local; unresolved
...
while without the patch and with -readnow, we have the opposite order:
...
$ gdb -readnow -batch outputs/gdb.threads/tls/tls \
-ex "maint expand-symtabs" \
-ex "print a_thread_local" \
-ex "maint print symbols" \
| grep "a_thread_local;"
Cannot find thread-local storage for process 0, executable file tls/tls:
Cannot find thread-local variables on this target
int a_thread_local; unresolved
int a_thread_local; computed at runtime
...
With the patch we have the same order with and without -readnow, but just a
different one than before without -readnow.
Mark the "Cannot find thread-local variables on this target" variant a PR25807
kfail.
gdb/ChangeLog:
2020-04-22 Tom de Vries <tdevries@suse.de>
PR symtab/25764
* dwarf2/read.c (scan_partial_symbols): Allow external variable decls
in psymtabs.
gdb/testsuite/ChangeLog:
2020-04-22 Tom de Vries <tdevries@suse.de>
PR symtab/25764
* gdb.base/psym-external-decl-2.c: New test.
* gdb.base/psym-external-decl.c: New test.
* gdb.base/psym-external-decl.exp: New file.
* gdb.threads/tls.exp: Add PR25807 kfail.
|
|
When running test-case gdb.ada/dgopt.exp with target board
unix/-flto/-O0/-flto-partition=none/-ffat-lto-objects and gcc-8, gcc-9 or
gcc-10, and the fix for PR25700, we run into this regression:
...
(gdb) list x.adb:16, 16^M
No source file named x.adb.^M
(gdb) FAIL: gdb.ada/dgopt.exp: list x.adb:16, 16
...
The reason for the failure is that without the fix for PR25700, we
have an unshared psymtab:
...
{ psymtab gdb.ada/dgopt/x.adb ((struct partial_symtab *) $hex)^M
readin no^M
fullname (null)^M
text addresses 0x0 -- 0x0^M
psymtabs_addrmap_supported yes^M
globals (none)^M
statics (none)^M
dependencies (none)^M
}^M
...
and a shared psymtab (with user field set):
...
{ psymtab gdb.ada/dgopt/x.adb ((struct partial_symtab *) $hex)^M
readin no^M
fullname (null)^M
text addresses 0x0 -- 0x0^M
psymtabs_addrmap_supported yes^M
globals (none)^M
statics (none)^M
user <artificial>@0x159a ((struct partial_symtab *) 0x37b57c0)^M
dependencies (none)^M
}^M
...
The fix for PR25700 removes the unshared psymtab.
Then when trying to find a psymtab matching x.adb in
psym_map_symtabs_matching_filename, we run into this continue for the shared
psymtab:
...
for (partial_symtab *pst : require_partial_symbols (objfile, true))
{
/* We can skip shared psymtabs here, because any file name will be
attached to the unshared psymtab. */
if (pst->user != NULL)
continue;
...
and consequently cannot find the file.
Fix this by not skipping the shared symtab in
psym_map_symtabs_matching_filename.
Build and reg-tested on x86_64-linux.
gdb/ChangeLog:
2020-04-22 Tom de Vries <tdevries@suse.de>
PR symtab/25801
* psymtab.c (psym_map_symtabs_matching_filename): Don't skip shared
symtabs.
gdb/testsuite/ChangeLog:
2020-04-22 Tom de Vries <tdevries@suse.de>
PR symtab/25801
* gdb.dwarf2/imported-unit.exp: Test that we can get imported_unit.c
in "info source" output.
|
|
Consider the executable generated for test-case gdb.dwarf2/imported-unit.exp.
When loading the executable using various tracing:
...
$ gdb \
outputs/gdb.dwarf2/imported-unit/imported-unit \
-batch \
-iex "set verbose on" \
-iex "set debug symtab-create 1"
...
Created psymtab 0x213f380 for module <artificial>@0xc7.
Created psymtab 0x20e7b00 for module imported_unit.c.
Created psymtab 0x215da20 for module imported_unit.c.
Created psymtab 0x2133630 for module elf-init.c.
Created psymtab 0x215b910 for module ../sysdeps/x86_64/crtn.S.
...
we notice that there are two psymtabs generated for imported_unit.c.
This is due to the following: in dwarf2_build_psymtabs_hard we loop over CUs
and generate partial symtabs for those, and if we encounter an import of
another CU, we also generate a partial symtab for that one, unless already
created.
This works well with backward import references:
- the imported CU is read
- then the importing CU is read
- the import is encountered, but the imported CU is already read, so
we're done.
But with forward import references, we have instead:
- the importing CU is read
- the import is encountered, and the imported CU is read
- the imported CU is read once more
Fix this by skipping already created psymtabs in the loop in
dwarf2_build_psymtabs_hard.
Tested on x86_64-linux, with native and target board
unix/-flto/-O0/-flto-partition=none/-ffat-lto-objects.
This causes this regression with the target board:
...
FAIL: gdb.ada/dgopt.exp: list x.adb:16, 16
...
which I consider a seperate PR, filed as PR25801 - "Filename of shared psymtab
is ignored".
gdb/ChangeLog:
2020-04-22 Tom de Vries <tdevries@suse.de>
PR symtab/25700
* dwarf2/read.c (dwarf2_build_psymtabs_hard): Don't create psymtab for
CU if already created.
gdb/testsuite/ChangeLog:
2020-04-22 Tom de Vries <tdevries@suse.de>
PR symtab/25700
* gdb.dwarf2/imported-unit.exp: Verify that there's only one partial
symtab for imported_unit.c.
|
|
Clang fails to compile the above file, with the following errors:
warning: control reaches end of non-void function [-Wreturn-type]
warning: too many arguments in call to 'func'
This prevents the following testcases from executing:
gdb.base/advance.exp
gdb.base/until-nodebug.exp
gdb/testsuite/ChangeLog:
* gdb.base/advance.c (func): New argument, to match call site.
(func2, func3): Add return statements.
|
|
In infrun.c's 'displaced_step_fixup', as part of the 'finish_step_over'
flow, switch to the eventing thread *before* calling
'displaced_step_restore', because down in the flow ptid-dependent
memory accesses are used via current_inferior() and current_top_target().
Without this patch, the problem is exposed with the scenario below:
$ gdb -q
(gdb) maint set target-non-stop on
(gdb) file a.out
Reading symbols from a.out...
(gdb) set remote exec-file a.out
(gdb) target extended-remote | gdbserver --once --multi -
...
(gdb) add-inferior
[New inferior 2]
Added inferior 2 on connection 1 (extended-remote ...)
(gdb) inferior 2
[Switching to inferior 2 [<null>] (<noexec>)]
(gdb) file a.out
Reading symbols from a.out...
(gdb) set remote exec-file a.out
(gdb) run
...
Cannot access memory at address 0x555555555042
(gdb)
The problem is, down inside 'displaced_step_restore', GDB wants to
access the memory for inferior 2 because of an internal breakpoint.
However, the current inferior and inferior_ptid are out of sync.
While inferior_ptid correctly points to the process of inf 2 that was
just started, current_inferior points to inf 1. Then, the attempt to
access the memory fails, because target_has_execution results in false
since inf 1 was not started. I was not able to simplify the failing
scenario, but it shows the problem.
After this patch, we get
... same steps above...
(gdb) run
...
[Inferior 2 (process 28652) exited normally]
(gdb)
Regression-tested on X86_64 Linux with `make check`s default board file
and also `--target_board=native-extended-gdbserver`. In fact, the bug
fixed by this patch was exposed when using the native-extended-gdbserver
board file.
gdb/ChangeLog:
2020-04-21 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* infrun.c (displaced_step_fixup): Switch to the event_thread
before calling displaced_step_restore, not after.
gdb/testsuite/ChangeLog:
2020-04-21 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* gdb.multi/run-only-second-inf.c: New file.
* gdb.multi/run-only-second-inf.exp: New file.
|
|
When there is more than one inferior, the "record btrace" command should
only apply to the current inferior.
gdb/ChangeLog:
2020-03-19 Markus Metzger <markus.t.metzger@intel.com>
* record-btrace.c (record_btrace_enable_warn): Ignore thread if
its inferior is not recorded by us.
(record_btrace_target_open): Replace call to all_non_exited_threads ()
with call to current_inferior ()->non_exited_threads ().
(record_btrace_target::stop_recording): Likewise.
(record_btrace_target::close): Likewise.
(record_btrace_target::wait): Likewise.
(record_btrace_target::record_stop_replaying): Likewise.
gdb/testsuite/ChangeLog:
2020-03-19 Markus Metzger <markus.t.metzger@intel.com>
* gdb.btrace/multi-inferior.c: New test.
* gdb.btrace/multi-inferior.exp: New file.
|
|
In the record-btrace target, while replaying, we can only provide the PC
register. The btrace state is stored in the thread_info. So, when trying
to determine whether we are currently replaying, GDB calls
find_thread_ptid() to obtain the thread_info. It also asserts that we do
have a thread_info.
For new threads, libthread-db may fetch registers before the thread is
known to GDB. In this case, find_thread_ptid() returns nullptr and the
assertion fails.
Forward the fetch_registers request to the target beneath in that case.
gdb/ChangeLog:
2020-03-19 Markus Metzger <markus.t.metzger@intel.com>
* record-btrace.c (record_btrace_target::fetch_registers): Forward
request if we do not have a thread_info.
gdb/testsuite/ChangeLog:
2020-03-19 Markus Metzger <markus.t.metzger@intel.com>
* gdb.btrace/enable-new-thread.c: New test.
* gdb.btrace/enable-new-thread.exp: New file.
|
|
Consider the test-case from this patch, compiled with pthread support:
...
$ gcc gdb/testsuite/gdb.threads/killed-outside.c -lpthread -g
...
After running to all_started, we can print pid:
...
$ gdb a.out -ex "b all_started" -ex run -ex "delete 1" -ex "p pid"
...
Reading symbols from a.out...
Breakpoint 1 at 0x40072b: file killed-outside.c, line 29.
Starting program: /data/gdb_versions/devel/a.out
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[New Thread 0x7ffff77fc700 (LWP 3155)]
Thread 1 "a.out" hit Breakpoint 1, all_started () at killed-outside.c:29
29 }
$1 = 3151
(gdb)
...
If we then kill the inferior using an external SIGKILL:
...
(gdb) shell kill -9 3151
...
and subsequently continue:
...
(gdb) c
Continuing.
Couldn't get registers: No such process.
Couldn't get registers: No such process.
(gdb) Couldn't get registers: No such process.
(gdb) Couldn't get registers: No such process.
(gdb) Couldn't get registers: No such process.
<repeat>
...
gdb hangs repeating the same warning. Typing control-C no longer helps,
and we have to kill gdb.
This is a regression since commit 873657b9e8 "Preserve selected thread in
all-stop w/ background execution". The commit adds a
scoped_restore_current_thread typed variable restore_thread to
fetch_inferior_event, and the hang is caused by the constructor throwing an
exception.
Fix this by catching the exception in the constructor.
Build and reg-tested on x86_64-linux.
gdb/ChangeLog:
2020-04-21 Tom de Vries <tdevries@suse.de>
PR gdb/25471
* thread.c
(scoped_restore_current_thread::scoped_restore_current_thread): Catch
exception in get_frame_id.
gdb/testsuite/ChangeLog:
2020-04-21 Tom de Vries <tdevries@suse.de>
PR gdb/25471
* gdb.threads/killed-outside.c: New test.
* gdb.threads/killed-outside.exp: New file.
|
|
There was an existing jit-protocol.h defining common symbols needed for
JIT-supporting application, however, it was only used by few tests.
Others redeclared the same symbols.
This unifies all tests to use jit-protocol.h
gdb/testsuite/ChangeLog:
2020-02-18 Mihails Strasuns <mihails.strasuns@intel.com>
* gdb.base/jit-attach-pie.c: Use jit-protocol.h.
* gdb.base/jit-elf-main.c: Use jit-protocol.h.
* gdb.base/jit-reader-host.c: Use jit-protocol.h.
* gdb.base/jit-reader-simple-jit.c: Use jit-protocol.h.
* gdb.base/jit-protocol.h: Update definitions to match all usage
contexts.
|
|
Reorganizes how JIT related test files to be more clear what are related
to JIT reader system tests and what use JIT from ELF objfiles. Those two
approaches are quite different in GDB implementation and require very
different test setup. Keeping distinction clear at the file name level
makes it easier to maintain the testsuite.
gdb/testsuite/ChangeLog:
2020-02-18 Mihails Strasuns <mihails.strasuns@intel.com>
* gdb.base: Rename all jit related test and source files.
|
