| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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.
|
|
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.
|
|
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.
|
|
We discovered that the Ada support in gdb depends on the order of the
DW_AT_name and DW_AT_linkage_name attributes in the DWARF. In
particular, if they are emitted in the "wrong" order for some system
symbols, "catch exception" will not work.
This patch fixes this problem by arranging to always prefer the
linkage name if both exist. This seems to be what the full symbol
reader already does -- that is, this is another bug arising from
having two different DWARF readers.
Another possible issue here is that gdb still doesn't really preserve
mangled names properly. There's a PR open about this. However, this
seems to be somewhat involved to fix, which is why this patch
continues to work around the bigger issue.
gdb/ChangeLog
2019-06-28 Tom Tromey <tromey@adacore.com>
* dwarf2read.c (partial_die_info::read): Prefer the linkage name
for Ada.
gdb/testsuite/ChangeLog
2019-06-28 Tom Tromey <tromey@adacore.com>
* gdb.dwarf2/ada-linkage-name.c: New file.
* gdb.dwarf2/ada-linkage-name.exp: New file.
|
|
When we run gdb.dwarf2/varval.exp with board cc-with-dwz, we run into:
...
gdb compile failed, dwz: varval: Couldn't find DIE referenced by \
DW_OP_GNU_variable_value
cc-with-tweaks.sh: dwz did not modify varval.
UNTESTED: gdb.dwarf2/varval.exp: failed to prepare
...
The problem is that varval contains some bad DWARF, which has been added
intentionally to test GDB, but that bad DWARF causes dwz to error out, which
has the consequence that the test-case remains untested with cc-with-dwz,
while the test-case contains also correct DWARF that does not occur in any
other test, and which we would really like to test with board cc-with-dwz.
Fix this by compiling varval twice, once without and once with the bad DWARF,
such that we have at least:
...
PASS: gdb.dwarf2/varval.exp: print varval
PASS: gdb.dwarf2/varval.exp: print varval2
PASS: gdb.dwarf2/varval.exp: print constval
PASS: gdb.dwarf2/varval.exp: print mixedval
PASS: gdb.dwarf2/varval.exp: print pointerval
PASS: gdb.dwarf2/varval.exp: print *pointerval
PASS: gdb.dwarf2/varval.exp: print structval
PASS: gdb.dwarf2/varval.exp: print untypedval
gdb compile failed, dwz: varval: Couldn't find DIE referenced by \
DW_OP_GNU_variable_value
cc-with-tweaks.sh: dwz did not modify varval.
UNTESTED: gdb.dwarf2/varval.exp: failed to prepare
...
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-06-26 Tom de Vries <tdevries@suse.de>
* gdb.dwarf2/varval.exp: Compile twice, once without bad DWARF.
|
|
When running gdb.dwarf2/dw2-restrict.exp with board cc-with-dwz, we run into:
...
dwz: dw2-restrict: DW_AT_stmt_list not DW_FORM_sec_offset or DW_FORM_data4
...
The problem is that the DW_AT_stmt_list is encoded using DW_FORM_addr, while
DW_FORM_sec_offset or DW_FORM_data4 would be appropriate. The test-case uses
a dw2-restrict.S which was generated using clang 2.9, which contained a bug
( https://bugs.llvm.org/show_bug.cgi?id=9995 ) causing this problem.
Fix this by regenerating using clang 5.0.1.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-06-25 Tom de Vries <tdevries@suse.de>
PR testsuite/24727
* gdb.dwarf2/dw2-restrict.S: Regenerate using clang 5.0.1.
|
|
When running gdb.dwarf2/implptr-64bit.exp with board cc-with-dwz-m, we run into:
...
dwz: dwz.c:2363: checksum_die: \
Assertion `\
((!op_multifile && !rd_multifile && !fi_multifile) || cu != die_cu (ref)) \
&& (!op_multifile || cu->cu_chunk == die_cu (ref)->cu_chunk)' failed.
cc-with-tweaks.sh: line 218: 13030 Aborted \
$DWZ -m ${output_file}.dwz "$output_file" ${output_file}.alt > /dev/null
...
In other words, PR dwz/24170.
The trigger for the dwz PR is when intra-CU references are encoded using
section-relative encoding DW_FORM_ref_addr, but could have been encoded using
CU-relative encoding DW_FORM_ref4.
Fix the intra-CU '%' label reference in implptr-64bit.exp.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-06-24 Tom de Vries <tdevries@suse.de>
* gdb.dwarf2/implptr-64bit.exp: Fix intra-CU '%' label reference.
|
|
When running gdb.dwarf2/inlined_subroutine-inheritance.exp with board
cc-with-dwz, we run into:
...
dwz: inlined_subroutine-inheritance: Couldn't find DIE referenced by \
DW_AT_abstract_origin
...
The problem is that the DW_AT_abstract_origin attributes refer to DIEs in
other CUs, while the references are encoded using the cu-relative encoding
DW_FORM_ref4.
Fix this by forcing the references to use DW_FORM_ref_addr.
Tested on x86_64-linux.
Tested with commit c24bdb023c "Introduce dwarf2_cu::get_builder" reverted,
and verified that the test-case fails in the same way before and after this
patch.
gdb/testsuite/ChangeLog:
2019-06-24 Tom de Vries <tdevries@suse.de>
* gdb.dwarf2/inlined_subroutine-inheritance.exp:
|
|
PR 24445 ("dwz multifile index not written to index cache") exposed the
fact that we are not doing things right when we generate an index for an
object file that has is linked to a dwz file. The same happens whether
the index is generated with the intent of populating the index cache or
using the save gdb-index command.
The problem can be observed when running these tests with the
cc-with-dwz-m board:
FAIL: gdb.base/index-cache.exp: test_cache_enabled_hit: check index-cache stats
FAIL: gdb.dwarf2/gdb-index.exp: index used
FAIL: gdb.dwarf2/gdb-index.exp: index used after symbol reloading
When generating the index for such file and inspecting the CU list of the
resulting index (with readelf --debug-dump=gdb_index), we can see something
like:
CU table:
[ 0] 0x0 - 0xb9
[ 1] 0x0 - 0x44
This is supposed to be a sorted list of the ranges of all CUs in the
file this index represents, so already having some overlap is a red
flag. It turns out that we save the ranges of CUs coming from both the
main file and the dwz file in the same index.
After digging a little bit, it became quite obvious that the index in
the main file should only list the CUs present in the main file, and a
separate index should be generated for the dwz file, listing the CUs
present in that file.
First, that's what happens if you run dwz on a file that already has a
GDB index embedded. Second, dwarf2read.c has code to read an index from
a dwz file. The index in the dwz file is actually required to be
present, if the main file has an index.
So this patch changes write_psymtabs_to_index to generate an index for
the dwz file, if present. That index only contains a CU list, just like
what the dwz tool does when processing a file that already contains an
index.
Some notes about the implementation:
- The file management (creating a temp file, make sure it's
close/removed on error - in the right order) is a bit heavy in
write_psymtabs_to_index, and I needed to add a third file. I factored
this pattern in a separate class, index_wip_file.
- It became a bit tedious to keep the call to assert_file_size in
write_psymtabs_to_index, write_gdbindex would have had to return two
sizes. Instead, I moved the calls to assert_file_size where the file
is written. The downside is that we lose the filename at this point,
but it was only used for the very improbable case of ftell failing, so
I think it's not a problem.
- The actual writing of the index file is factored out to
write_gdbindex_1, so it can be re-used for both index files.
- While the "save gdb-index" command will now write two .gdb-index
files, this patch does not update the gdb-add-index.sh script, this
will come in a later patch.
gdb/ChangeLog:
YYYY-MM-DD Simon Marchi <simon.marchi@efficios.com>
PR gdb/24445
* dwarf-index-write.h (write_psymtabs_to_index): Add
dwz_basename parameter.
* dwarf-index-write.c (write_gdbindex): Move file writing to
write_gdbindex_1. Change return type void.
(assert_file_size): Move up, remove filename parameter.
(write_gdbindex_1): New function.
(write_debug_names): Change return type to void, call
assert_file_size.
(struct index_wip_file): New struct.
(write_psymtabs_to_index): Add dwz_basename parameter. Move
file logic to index_wip_file. Write index for dwz file if
needed.
(save_gdb_index_command): Pass basename of dwz file, if present.
* dwarf-index-cache.c (index_cache::store): Obtain and pass
build-id of dwz file, if present.
* dwarf2read.c (struct dwz_file): Move to dwarf2read.h.
(dwarf2_get_dwz_file): Likewise.
* dwarf2read.h (struct dwz_file): Move from dwarf2read.c.
(dwarf2_get_dwz_file): Likewise.
gdb/testsuite/ChangeLog:
YYYY-MM-DD Tom de Vries <tdevries@suse.de>
PR gdb/24445
* gdb.dwarf2/gdb-index.exp (add_gdb_index): Update dwz file with
generated index.
|
|
When running gdb.dwarf2/nonvar-access.exp with board readnow, we have:
...
FAIL: gdb.dwarf2/nonvar-access.exp: print/x def_implicit_s
...
and 12 more similar failures.
I've tracked this down to the range of main being hardcoded to
[_main, _main+0x10000) in the dwarf assembly:
...
DW_TAG_subprogram {
{name main}
{DW_AT_external 1 flag}
{low_pc [gdb_target_symbol main] DW_FORM_addr}
{high_pc [gdb_target_symbol main]+0x10000 DW_FORM_addr}
} {
...
which overlaps with the .debug_info for the elf-init.c CU (containing
__libc_csu_init and __libc_csu_fini).
Fix this by using function_range to find the actual range of main.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-06-11 Tom de Vries <tdevries@suse.de>
PR testsuite/24521
* gdb.dwarf2/nonvar-access.exp: Fix main high_pc.
|
|
Add a test-case gdb.dwarf2/gdb-add-index.exp to test
gdb/contrib/gdb-add-index.sh.
Tested with x86_64-linux.
gdb/testsuite/ChangeLog:
2019-05-24 Tom de Vries <tdevries@suse.de>
* gdb.dwarf2/gdb-add-index.exp: New file.
|
|
A base address selection entry in a location list consist of two (constant or
relocated) address offsets. The two offsets are the same size as an address
on the target machine.
The test-case gdb.dwarf2/dw2-skip-prologue.S encodes a base address selection
entry using .4byte, which is incorrect for 8-byte pointer size. [ Which
triggers an assert in dwz, see PR dwz/24172. ]
Fix this by using PTRBYTE instead.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-05-14 Tom de Vries <tdevries@suse.de>
* gdb.dwarf2/dw2-skip-prologue.S (.debug_loc): Fix base address
selection entry encoding.
|
|
When running gdb.dwarf2/dw2-case-insensitive.exp with target board
cc-with-debug-names, we run into:
...
FAIL: gdb.dwarf2/dw2-case-insensitive.exp: regexp case-sensitive off \
(GDB internal error)
...
in more detail:
...
(gdb) info functions fUnC_lang
gdb/dwarf2read.c:5293: internal-error: \
compunit_symtab* dw2_find_pc_sect_compunit_symtab(objfile*, \
bound_minimal_symbol, CORE_ADDR, obj_section*, int): \
Assertion `result != NULL' failed.
...
The problem is that the .debug_aranges section in dw2-case-insensitive-debug.S
contains a debug_info_offset which is set to 0:
...
.section .debug_aranges,"",@progbits
.4byte .Laranges_end - .Laranges_start
.Laranges_start:
.2byte 0x2
.4byte 0
...
while the compilation unit at offset 0 in the .debug_section of the executable
is in fact not the compilation unit generated from
dw2-case-insensitive-debug.S.
This happens when linked in object files contain dwarf info and are placed in
the .debug_info section before the compilation unit generated from
dw2-case-insensitive-debug.S.
Fix this by defining the debug_info_offset field using the label .Lcu1_begin
that defines the start of the compilation unit:
...
- .4byte 0
+ .4byte .Lcu1_begin
...
Tested on x86_64-linux with native, cc-with-gdb-index and cc-with-debug-names.
gdb/testsuite/ChangeLog:
2019-05-07 Tom de Vries <tdevries@suse.de>
PR testsuite/24522
* gdb.dwarf2/dw2-case-insensitive-debug.S: Fix debug_info_offset in
.debug_aranges section.
|
|
Before this commit using ptype on a Fortran function will include
information about the functions return type, but not the expected
arguments as it would for C or C++. After this commit argument types
are included in the ptype output.
For example, before GDB prints:
(gdb) ptype fun1
type = integer(kind=4) ()
(gdb) ptype is_bigger
type = logical(kind=4) ()
and after GDB prints:
(gdb) ptype fun1
type = integer(kind=4) (integer(kind=4))
(gdb) ptype is_bigger
type = logical(kind=4) (integer(kind=4), integer(kind=4))
gdb/ChangeLog:
* f-typeprint.c (f_type_print_varspec_suffix): Handle printing
function arguments.
gdb/testsuite/ChangeLog:
* gdb.fortran/ptype-on-functions.exp: New file.
* gdb.fortran/ptype-on-functions.f90: New file.
|
|
add_partial_subprogram does not handle DW_AT_ranges, while the full
symtab reader does. This can lead to discrepancies where a function
is not put into a partial symtab, and so is not available to "break"
and the like -- but is available if the full symtab has somehow been
read.
This patch fixes the bug by arranging to read DW_AT_ranges when
reading partial DIEs.
This is PR symtab/23331.
The new test case is derived from dw2-ranges-func.exp, which is why I
kept the copyright dates.
gdb/ChangeLog
2019-04-01 Tom Tromey <tromey@adacore.com>
PR symtab/23331:
* dwarf2read.c (partial_die_info::read): Handle DW_AT_ranges.
gdb/testsuite/ChangeLog
2019-04-01 Tom Tromey <tromey@adacore.com>
PR symtab/23331:
* gdb.dwarf2/dw2-ranges-main.c: New file.
* gdb.dwarf2/dw2-ranges-psym.c: New file.
* gdb.dwarf2/dw2-ranges-psym.exp: New file.
|
|
This patch fixes the copyright year range which escaped
the 2019 update, because the patch was submitted in 2018, but
only really pushed in 2019.
Pushed: https://www.sourceware.org/ml/gdb-patches/2019-02/msg00109.html
Submitted: https://www.sourceware.org/ml/gdb-patches/2018-12/msg00444.html
We normally are pretty good at remembering those little things,
but this one fell through the cracks. This commit fixes this,
by re-running the copyright.py script and checking in the changes
made by that script.
gdb/testsuite/ChangeLog:
* gdb.ada/mi_ref_changeable.exp: Update copyright year range.
* gdb.ada/mi_ref_changeable/foo_rb20_056.adb: Likewise.
* gdb.ada/mi_ref_changeable/pck.adb: Likewise.
* gdb.ada/mi_ref_changeable/pck.ads: Likewise.
* gdb.dwarf2/inlined_subroutine-inheritance.exp: Likewise.
|
|
This patch is an attempt to deal with a variety of bugs reported where
GDB segfaults attempting to access a dwarf2_cu's builder. In certain
circumstances, this builder can be NULL. This is especially common
when inheriting DIEs via inlined subroutines in other CUs. The test
case demonstrates one such situation reported by users. See gdb/23773,
rhbz1638798, and dups for other concrete examples.
The approach taken here is to save the ancestor CU into the dwarf2_cu of
all CUs with DIEs that are "imported." This can happen whenever
follow_die_offset and friends are called. This essentially introduces a
chain of CUs that caused the importation of a DIE from a CU. Whenever
a builder is requested of a CU that has none, the ancestors are searched
for the first one with a builder.
A design side effect of this is that the builder can now only be
accessed by getter and setter methods because the builder itself
is private.
The bulk of the patch is relatively mindless text conversion from
"cu->builder" to "cu->get_builder ()". I've included one test which
was derived from one (of the many) bugs reported on the issue in both
sourceware and Fedora bugzillas.
gdb/ChangeLog:
PR gdb/23773
* dwarf2read.c (dwarf2_cu) <ancestor>: New field.
<builder>: Rename to ..
<m_builder>: ... this and make private.
(dwarf2_cu::get_builder): New method. Change all users of
`builder' to use this method.
(dwarf2_start_symtab): Move to ...
(dwarf2_cu::start_symtab): ... here. Update all callers
(setup_type_unit_groups): Move to ...
(dwarf2_cu::setup_type_unit_groups): ... here. Update all
callers.
(dwarf2_cu::reset_builder): New method.
(process_full_compunit, process_full_type_unit): Use
dwarf2_cu::reset_builder.
(follow_die_offset): Record the ancestor CU if it is different
from the followed DIE's CU.
(follow_die_sig_1): Likewise.
gdb/testsuite/ChangeLog:
PR gdb/23773
* gdb.dwarf2/inlined_subroutine-inheritance.exp: New file.
|
|
This is a test derived from one of the reproducers in symtab/23010.
The DIE tree used here is typical of compilations with LTO, where an
artificial parent DIE of language C99 imports DIEs of other languages.
gdb/testsuite/ChangeLog:
PR gdb/23712
PR symtab/23010
* gdb.dwarf2/multidictionary.exp: New file.
|
|
PR gdb/28155 notes a crash in "finish" that occurs with a particular
source file compiled by clang.
The bug is the typical gdb problem of a missing call to check_typedef.
clang emits a function whose return type is a typedef to void.
get_return_value asserts that the return type is not void, but the
callers were not using check_typedef first.
gdb/ChangeLog
2019-01-06 Tom Tromey <tom@tromey.com>
PR gdb/28155:
* python/py-finishbreakpoint.c (bpfinishpy_init): Use
check_typedef.
* infcmd.c (finish_command_fsm_should_stop): Use check_typedef.
(print_return_value): Likewise.
gdb/testsuite/ChangeLog
2019-01-06 Tom Tromey <tom@tromey.com>
PR gdb/28155:
* gdb.dwarf2/typedef-void-finish.exp: New file.
|
|
This commit applies all changes made after running the gdb/copyright.py
script.
Note that one file was flagged by the script, due to an invalid
copyright header
(gdb/unittests/basic_string_view/element_access/char/empty.cc).
As the file was copied from GCC's libstdc++-v3 testsuite, this commit
leaves this file untouched for the time being; a patch to fix the header
was sent to gcc-patches first.
gdb/ChangeLog:
Update copyright year range in all GDB files.
|
|
The 64-bit RISC-V target currently models the floating point registers
as having the following type:
union riscv_double
{
builtin_type_ieee_single float;
builtin_type_ieee_double double;
}
Notice the choice of names for the fields of this struct, possibly not
ideal choices, as these are not valid field names in C. However, this
type is only ever defined within GDB (or in the target description),
and no restriction seems to exist on the field names in that case.
The problem though is that currently:
(gdb) info registers $ft0
ft0 {float = 0, double = 0} (raw 0x0000000000000000)
(gdb) p $ft0.float
$1 = 0
(gdb) p $ft0.double
A syntax error in expression, near `double'.
We can access the 'float' field, but not the 'double' field. This is
because the string 'double' is handled differently to the string
'float' in c-exp.y.
In both cases the string '$ft0' is parsed as a VARIABLE expression.
In the 'float' case, the string 'float' becomes a generic NAME token
in 'lex_one_token', which then allows the rule "exp '.' name" to match
and the field name lookup to occur.
The 'double' case is different. In order to allow parsing of the type
string 'long double', the 'double' string becomes the token
DOUBLE_KEYWORD. At this point there's no rule to match "exp '.'
DOUBLE_KEYWORD", so we can never lookup the field named 'double'.
We could rename the fields for RISC-V, and maybe that would be the
best solution. However, its not hard to allow for fields named
'double', which is what this patch does.
A new case is added to the 'field_name' rule to match the
DOUBLE_KEYWORD, and create a suitable 'struct stoken'. With this done
the "exp '.' field_name" pattern can now match, and we can lookup the
double field.
With this patch in place I now see this behaviour:
(gdb) info registers $ft0
ft0 {float = 0, double = 0} (raw 0x0000000000000000)
(gdb) p $ft0.float
$1 = 0
(gdb) p $ft0.double
$2 = 0
I've gone ahead and handled INT_KEYWORD, LONG, SHORT, SIGNED_KEYWORD,
and UNSIGNED as well within field_name.
I've added a new test for this functionality.
This change was tested on x86-64 GNU/Linux with no regressions.
gdb/ChangeLog:
* c-exp.y (field_name): Allow DOUBLE_KEYWORD, INT_KEYWORD, LONG,
SHORT, SIGNED_KEYWORD, and UNSIGNED tokens to act as a field
names.
(typename_stoken): New function.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/dw2-unusual-field-names.c: New file.
* gdb.dwarf2/dw2-unusual-field-names.exp: New file.
|
|
Use scoped_switch_to_sym_language_if_auto in treg_matches_sym_type_name to
replace the local logic that was doing the same as the new class
scoped_switch_to_sym_language_if_auto.
Use scoped_switch_to_sym_language_if_auto inside print_symbol_info, so
that symbol information is printed in the symbol language when
language mode is auto.
This modifies the behaviour of the test dw2-case-insensitive.exp,
as the function FUNC_lang is now printed with the Fortran syntax
(as declared in the .S file).
gdb/ChangeLog
2018-11-20 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* symtab.c (treg_matches_sym_type_name): Use
scoped_switch_to_sym_language_if_auto instead of local logic.
(print_symbol_info): Use scoped_switch_to_sym_language_if_auto
to switch to SYM language when language mode is auto.
gdb/testsuite/ChangeLog
2018-11-20 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* gdb.dwarf2/dw2-case-insensitive.exp: Update due to auto switch to
FUNC_lang language syntax.
|
|
In this commit:
commit eb77c9df9f6d2f7aa644a170280fe31ce080f887
Date: Thu Oct 18 14:04:27 2018 +0100
gdb: Handle ICC's unexpected void return type
A potential dereference of a NULL pointer was introduced if a
DW_TAG_base_type is missing a DW_AT_name attribute.
I have taken this opportunity to fix a slight confusion that existed
in the test also added in the above commit, the test had two C
variables, declared like this:
int var_a = 5;
void *var_ptr = &var_a;
However, the fake DWARF in the test script declared them like this:
void var_a = 5;
void *var_ptr = &var_a;
This wasn't a problem as the test never uses 'var_a' directly, this
only exists so 'var_ptr' can be initialised. However, it seemed worth
fixing.
I've also added a test for a DW_TAG_base_type with a missing
DW_AT_name, as clearly there's not test currently that covers this
(the original patch tested cleanly). I can confirm that the new test
causes GDB to crash before this patch, and passes with this patch.
gdb/ChangeLog:
* dwarf2read.c (dwarf2_init_integer_type): Check for name being
NULL before dereferencing it.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/void-type.exp: Rename types, and make var_a an 'int'.
* gdb.dwarf2/missing-type-name.exp: New file.
|
|
I encountered a binary compiled with Intel's C Compiler (ICC) version
14.0.5.212, which seemed to contain some non-standard DWARF.
The DWARF spec (V5 3.3.2) says:
Debugging information entries for C void functions should not have
an attribute for the return type.
However, what I observed in the DWARF from this ICC compiled binary
was this:
...
<0><857>: Abbrev Number: 1 (DW_TAG_compile_unit)
<858> DW_AT_comp_dir : (indirect string, offset: 0x48d): /tmp/
<85c> DW_AT_language : 1 (ANSI C)
<85d> DW_AT_name : (indirect string, offset: 0x77c): filename.c
<861> DW_AT_producer : (indirect string, offset: 0x520): Intel(R) C Intel(R) 64 Compiler ...
<865> DW_AT_low_pc : 0x4378d0
<86d> DW_AT_high_pc : 0x4378f0
<875> DW_AT_stmt_list : 0xa37
...
<1><7ea>: Abbrev Number: 2 (DW_TAG_base_type)
<7eb> DW_AT_byte_size : 0
<7ec> DW_AT_encoding : 5 (signed)
<7ed> DW_AT_name : (indirect string, offset: 0x58f): void
...
<1><7f1>: Abbrev Number: 3 (DW_TAG_subprogram)
<7f2> DW_AT_decl_line : 268
<7f4> DW_AT_decl_column : 30
<7f5> DW_AT_decl_file : 1
<7f6> DW_AT_type : <0x7ea>
<7fa> DW_AT_prototyped : 1
<7fb> DW_AT_name : (indirect string, offset: 0x761): function_foo
<7ff> DW_AT_MIPS_linkage_name: (indirect string, offset: 0x761): function_foo
<803> DW_AT_low_pc : 0x4378a0
<80b> DW_AT_high_pc : 0x4378d0
<813> DW_AT_external : 1
...
So function 'function_foo' has void return type, but still has a
DW_AT_type attribute for a 0 sized type called void.
What was found was that when the 'finish' command was used to leave
'function_foo', GDB would crash.
The problem is that in infcmd.c:print_return_value GDB tries to filter
out void return types, by looking for the TYPE_CODE_VOID, this fails
for the 'void' type as it has code TYPE_CODE_INT and GDB then tries to
print the 'void' type.
This eventually ends in a call to valprint.c:maybe_negate_by_bytes,
however, the len (length) of the value being negated is 0, which is
not detected or expected by this code, and invalid memory accesses
occur, some of which might cause GDB to crash.
The above DWARF was seen on version 14.0.5.212 of ICC.
I have also tested ICC versions 18.0.2.199 and 17.0.7.259, on both of
these versions, the DW_AT_type on the DW_TAG_subprogram has been
removed, bringing ICC inline with the DWARF standard, and with the
DWARF produced by GCC.
I only have limited access to these specific versions of ICC so I am
unable to get more specific details for when the generated DWARF
became non-standard or when it was changed to be more inline with the
DWARF standard.
Further testing revealed additional places where ICC produced 'void'
related DWARF that GDB struggles with. When I compiled code that
contained a function with this signature:
void funcx (void *arg);
on ICC 17/18, I got the following DWARF (notice the void return type
is now gone):
...
<1><32>: Abbrev Number: 2 (DW_TAG_subprogram)
<33> DW_AT_decl_line : 2
<34> DW_AT_decl_file : 1
<35> DW_AT_prototyped : 1
<36> DW_AT_name : (indirect string, offset: 0xc5): funcx
<3a> DW_AT_MIPS_linkage_name: (indirect string, offset: 0xc5): funcx
<3e> DW_AT_low_pc : 0x6dc
<46> DW_AT_high_pc : 0x703
<4e> DW_AT_external : 1
<2><4f>: Abbrev Number: 3 (DW_TAG_formal_parameter)
<50> DW_AT_decl_line : 2
<51> DW_AT_decl_file : 1
<52> DW_AT_type : <0x6a>
<56> DW_AT_name : arg
<5a> DW_AT_location : 2 byte block: 76 70 (DW_OP_breg6 (rbp): -16)
...
<1><6a>: Abbrev Number: 5 (DW_TAG_pointer_type)
<6b> DW_AT_type : <0x6f>
<1><6f>: Abbrev Number: 6 (DW_TAG_base_type)
<70> DW_AT_byte_size : 0
<71> DW_AT_encoding : 5 (signed)
<72> DW_AT_name : (indirect string, offset: 0xcb): void
...
However, the function argument 'arg' does still reference a 'void'
type. This case doesn't seem as obviously non-standard as the
previous one, but I think that the DWARF standard (V5 5.2) does
suggest that the above is not the recommended approach. If we compare
to the DWARF generated by GCC 7.3.1:
...
<1><68>: Abbrev Number: 5 (DW_TAG_subprogram)
<69> DW_AT_external : 1
<69> DW_AT_name : (indirect string, offset: 0x221): funcx
<6d> DW_AT_decl_file : 1
<6e> DW_AT_decl_line : 2
<6f> DW_AT_prototyped : 1
<6f> DW_AT_low_pc : 0x400487
<77> DW_AT_high_pc : 0x22
<7f> DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_cfa)
<81> DW_AT_GNU_all_call_sites: 1
<81> DW_AT_sibling : <0xa0>
<2><85>: Abbrev Number: 6 (DW_TAG_formal_parameter)
<86> DW_AT_name : arg
<8a> DW_AT_decl_file : 1
<8b> DW_AT_decl_line : 2
<8c> DW_AT_type : <0xa0>
<90> DW_AT_location : 2 byte block: 91 58 (DW_OP_fbreg: -40)
...
<1><a0>: Abbrev Number: 7 (DW_TAG_pointer_type)
<a1> DW_AT_byte_size : 8
...
Here we see that the DW_TAG_pointer_type doesn't reference any further
type. This also seems out of line with the DWARF standard (which I
think recommends using a DW_TAG_unspecified_type entry), however GDB
does handle the GCC generated DWARF better.
If we look at how GDB handles the DWARF from GCC, then we see this:
(gdb) print *arg
Attempt to dereference a generic pointer.
While on the current HEAD of master dereferencing arg causes undefined
behaviour which will likely crash GDB (for the same reason as was
described above for the 'finish' case). On earlier versions of GDB
the ICC DWARF would cause this:
(gdb) print *arg
$1 = 0
In this patch both the return type, and general variable/parameter
type handling is fixed by transforming the synthetic void entries in
the DWARF, the ones that look like this:
<1><6f>: Abbrev Number: 6 (DW_TAG_base_type)
<70> DW_AT_byte_size : 0
<71> DW_AT_encoding : 5 (signed)
<72> DW_AT_name : (indirect string, offset: 0xcb): void
into GDB's builtin void type. My criteria for performing the fix are:
1. Binary produced by any version of ICC,
2. We're producing an integer type,
3. The size is 0, and
4. The name is "void".
I ignore the signed / unsigned nature of the integer.
Potentially we could drop the ICC detection too, this should be a
reasonably safe transformation to perform, however, I'm generally
pretty nervous when it comes to modifying how the DWARF is parsed so,
for now, I have restricted this to ICC only.
I also added an assertion to maybe_negate_by_bytes. This is nothing
to do with the actual fix, but should detect incorrect use of this
function in the future, without relying on undefined behaviour to
crash GDB.
I added a new test that makes use the of the testsuite's DWARF
generator. As it is tricky to create target independent tests that
pass function parameters using the DWARF generator (as specifying the
argument location is target specific) I have instead made use of a
global variable void*. This still shows the issue.
We already have a predicate in the DWARF parser to detect versions of
ICC prior to 14, however, this issue was spotted on a later version.
As a result I've added a new predicate that is true for any version of
ICC.
gdb/ChangeLog:
* dwarf2read.c (struct dwarf2_cu): Add producer_is_icc field.
(producer_is_icc): New function.
(check_producer): Set producer_is_icc field on dwarf2_cu.
(dwarf2_init_integer_type): New function.
(read_base_type): Call dwarf2_init_integer_type instead of
init_integer_type in all cases.
(dwarf2_cu::dwarf2_cu): Initialise producer_is_icc field.
* valprint.c (maybe_negate_by_bytes): Add an assertion that the
LEN is greater than 0.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/void-type.c: New file.
* gdb.dwarf2/void-type.exp: New file.
|
|
This removes the SHORT_FIRST_MESSAGE case from complaints, leaving
only a single case. This allows for the removal of the last argument
to clear_complaints, and also simplifies complaint_internal, removing
an extra allocation in the process.
After this, the "./gdb -iex 'set complaint 1' -nx ./gdb" example will
show:
Reading symbols from ./gdb...
During symbol reading: .debug_ranges entry has start address of zero [in module /home/tromey/gdb/build/gdb/gdb]
During symbol reading: DW_AT_low_pc 0x0 is zero for DIE at 0x17116c1 [in module /home/tromey/gdb/build/gdb/gdb]
During symbol reading: .debug_line address at offset 0xa22f5 is 0 [in module /home/tromey/gdb/build/gdb/gdb]
During symbol reading: unsupported tag: 'DW_TAG_unspecified_type'
During symbol reading: const value length mismatch for 'std::ratio<1, 1000000000>::num', got 8, expected 0
This is a bit wordier but, I think, a bit more clear, as the form of
the message no longer depends on precisely when it was emitted. In
particular if you compare to the output from the 'Clean up "Reading
symbols" output' patch, you can see that earlier gdb would switch from
the prefix-less form to the "During symbol reading" form at a point
that is meaningless to the user (specifically, after psymtab reading
is done and gdb tries to expand a CU).
2018-10-04 Tom Tromey <tom@tromey.com>
* symfile.c (syms_from_objfile_1, finish_new_objfile)
(reread_symbols): Update.
* complaints.h (clear_complaints): Remove argument.
* complaints.c (enum complaint_series): Remove.
(series): Remove global.
(complaint_internal): Update.
(clear_complaints): Remove argument.
gdb/testsuite/ChangeLog
2018-10-04 Tom Tromey <tom@tromey.com>
* gdb.cp/maint.exp (test_invalid_name): Update expected output.
* gdb.gdb/complaints.exp (test_short_complaints): Remove.
(test_initial_complaints, test_empty_complaints): Update.
* gdb.dwarf2/dw2-stack-boundary.exp: Update.
|
|
This patch is another attempt to fix PR cli/19551. Unlike my previous
attempt, it doesn't print progress. Instead, it just changes some
messages and adds newlines to make the output a bit nicer.
It also removes the "done." text that was previously emitted. The
idea here is that it is obvious when gdb is done reading debug info,
as it starts then doing something else; and that while this message
did not provide much benefit to users, it did make it harder to make
the output clean.
After this change the output from "./gdb -iex 'set complaint 1' -nx ./gdb"
reads:
Reading symbols from ./gdb...
.debug_ranges entry has start address of zero [in module /home/tromey/gdb/build/gdb/gdb]
DW_AT_low_pc 0x0 is zero for DIE at 0x17116c1 [in module /home/tromey/gdb/build/gdb/gdb]
.debug_line address at offset 0xa22f5 is 0 [in module /home/tromey/gdb/build/gdb/gdb]
During symbol reading, unsupported tag: 'DW_TAG_unspecified_type'.
During symbol reading, const value length mismatch for 'std::ratio<1, 1000000000>::num', got 8, expected 0.
gdb/ChangeLog
2018-10-04 Tom Tromey <tom@tromey.com>
PR cli/19551:
* symfile.c (symbol_file_add_with_addrs): Update output.
* psymtab.c (require_partial_symbols): Update output.
gdb/testsuite/ChangeLog
2018-10-04 Tom Tromey <tom@tromey.com>
PR cli/19551:
* lib/mi-support.exp (mi_gdb_file_cmd): Update.
* lib/gdb.exp (gdb_file_cmd): Update.
* gdb.stabs/weird.exp (print_weird_var): Update.
* gdb.server/solib-list.exp: Update.
* gdb.multi/remove-inferiors.exp (test_remove_inferiors): Update.
* gdb.mi/mi-cli.exp: Update.
* gdb.linespec/linespec.exp: Update.
* gdb.dwarf2/dw2-stack-boundary.exp: Update.
* gdb.dwarf2/dw2-objfile-overlap.exp: Update.
* gdb.cp/cp-relocate.exp: Update.
* gdb.base/sym-file.exp: Update.
* gdb.base/relocate.exp: Update.
* gdb.base/readnever.exp: Update.
* gdb.base/print-symbol-loading.exp (test_load_core): Update.
* gdb.base/kill-detach-inferiors-cmd.exp: Update.
* gdb.base/dbx.exp (gdb_file_cmd): Update.
* gdb.base/code_elim.exp: Update.
* gdb.base/break-unload-file.exp (test_break): Update.
* gdb.base/break-interp.exp (test_attach_gdb): Update.
* gdb.base/break-idempotent.exp (force_breakpoint_re_set):
Update.
* gdb.base/attach.exp (do_attach_tests): Update.
* gdb.base/sepdebug.exp: Update.
* gdb.python/py-section-script.exp: Update.
|
|
Currently complaints are not always printed with a newline. For
example, when I run gdb on itself, I see output like:
(gdb) set complaints 5
(gdb) file ./gdb/gdb
Reading symbols from ./gdb/gdb...DW_AT_low_pc 0x0 is zero for DIE at 0x437dd4 [in module /home/tromey/gdb/build/gdb/gdb]....debug_line address at offset 0x21bf9 is 0 [in module /home/tromey/gdb/build/gdb/gdb]...DW_AT_low_pc 0x0 is zero for DIE at 0x5a85dd [in module /home/tromey/gdb/build/gdb/gdb]....debug_line address at offset 0x2dc2d is 0 [in module /home/tromey/gdb/build/gdb/gdb]...DW_AT_low_pc 0x0 is zero for DIE at 0xab6033 [in module /home/tromey/gdb/build/gdb/gdb]....debug_line address at offset 0x4f683 is 0 [in module /home/tromey/gdb/build/gdb/gdb]...DW_AT_low_pc 0x0 is zero for DIE at 0x10028f0 [in module /home/tromey/gdb/build/gdb/gdb]....debug_line address at offset 0x75edf is 0 [in module /home/tromey/gdb/build/gdb/gdb]...DW_AT_low_pc 0x0 is zero for DIE at 0x1021364 [in module /home/tromey/gdb/build/gdb/gdb]....debug_line address at offset 0x76f62 is 0 [in module /home/tromey/gdb/build/gdb/gdb]...done.
That's one very long line. I find it quite difficult to read that,
and I thought it would be better with some newlines, which is what
this patch does. Now the output looks like:
(gdb) file ./gdb
Reading symbols from ./gdb...
DW_AT_low_pc 0x0 is zero for DIE at 0x437dd4 [in module /home/tromey/gdb/build/gdb/gdb]
.debug_line address at offset 0x21bf9 is 0 [in module /home/tromey/gdb/build/gdb/gdb]
DW_AT_low_pc 0x0 is zero for DIE at 0x5a85dd [in module /home/tromey/gdb/build/gdb/gdb]
.debug_line address at offset 0x2dc2d is 0 [in module /home/tromey/gdb/build/gdb/gdb]
done.
gdb/ChangeLog
2018-10-04 Tom Tromey <tom@tromey.com>
PR cli/22234:
* complaints.c: Emit \n.
gdb/testsuite/ChangeLog
2018-10-04 Tom Tromey <tom@tromey.com>
PR cli/22234:
* gdb.dwarf2/dw2-stack-boundary.exp: Update expected output.
* gdb.gdb/complaints.exp (test_short_complaints): Update expected
output.
|
|
Consider a vla variable 'a' in function f1:
...
<2><1a7>: Abbrev Number: 11 (DW_TAG_variable)
<1a8> DW_AT_description : a
<1aa> DW_AT_abstract_origin: <0x311>
...
with abstract origin 'a':
...
<2><311>: Abbrev Number: 3 (DW_TAG_variable)
<312> DW_AT_name : a
<317> DW_AT_type : <0x325>
...
and inherited abstract vla type:
...
<1><325>: Abbrev Number: 9 (DW_TAG_array_type)
<326> DW_AT_type : <0x33a>
<2><32e>: Abbrev Number: 10 (DW_TAG_subrange_type)
<32f> DW_AT_type : <0x2ea>
<333> DW_AT_upper_bound : 5 byte block: fd 1b 3 0 0
(DW_OP_GNU_variable_value: <0x31b>)
...
where the upper bound refers to this artificial variable D.1922 without location
attribute:
...
<2><31b>: Abbrev Number: 8 (DW_TAG_variable)
<31c> DW_AT_description : (indirect string, offset: 0x39a): D.1922
<320> DW_AT_type : <0x2ea>
<324> DW_AT_artificial : 1
...
Currently, when we execute "p sizeof (a)" in f1, the upper bound is calculated
by evaluating the DW_OP_GNU_variable_value expression referring to D.1922, but
since that die doesn't have a location attribute, we get:
...
value has been optimized out
...
However, there's also artificial variable D.4283 that is sibling of vla
variable 'a', has artificial variable D.1922 as abstract origin, and has a
location attribute:
...
<2><1ae>: Abbrev Number: 12 (DW_TAG_variable)
<1af> DW_AT_description : (indirect string, offset: 0x1f8): D.4283
<1b3> DW_AT_abstract_origin: <0x31b>
<1b7> DW_AT_location : 11 byte block: 75 1 8 20 24 8 20 26 31 1c 9f
(DW_OP_breg5 (rdi):1; DW_OP_const1u: 32;
DW_OP_shl; DW_OP_const1u: 32; DW_OP_shra;
DW_OP_lit1; DW_OP_minus; DW_OP_stack_value)
...
The intended behaviour for DW_OP_GNU_variable_value is to find a die that
refers to D.1922 as abstract origin, has a location attribute and is
'in scope', so the expected behaviour is:
...
$1 = 6
...
The 'in scope' concept can be thought of as variable D.1922 having name
attribute "D.1922", and variable D.4283 inheriting that attribute, resulting
in D.4283 being declared with name "D.1922" alongside vla a in f1, and when we
lookup "DW_OP_GNU_variable_value D.1922", it should work as if we try to find
the value of a variable named "D.1922" on the gdb command line using
"p D.1922", and we should return the value of D.4283.
This patch fixes the case described above, by:
- adding a field abstract_to_concrete to struct dwarf2_per_objfile,
- using that field to keep track of which concrete dies are instances of an
abstract die, and
- using that information when getting the value DW_OP_GNU_variable_value.
Build and reg-tested on x86_64-linux.
2018-09-05 Tom de Vries <tdevries@suse.de>
* dwarf2loc.c (sect_variable_value): Call indirect_synthetic_pointer
with resolve_abstract_p == true.
(indirect_synthetic_pointer): Add resolve_abstract_p parameter,
defaulting to false. Propagate resolve_abstract_p to
dwarf2_fetch_die_loc_sect_off.
* dwarf2loc.h (dwarf2_fetch_die_loc_sect_off): Add resolve_abstract_p
parameter, defaulting to false.
* dwarf2read.c (read_variable): Add variable to abstract_to_concrete.
(dwarf2_fetch_die_loc_sect_off): Add and handle resolve_abstract_p
parameter.
* dwarf2read.h (struct die_info): Forward-declare.
(die_info_ptr): New typedef.
(struct dwarf2_per_objfile): Add abstract_to_concrete field.
* gdb.dwarf2/varval.exp: Add test.
|
|
See comments in the new files for what this is about - I tried to
explain it all there.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/dw2-ranges-func.c: New file.
* gdb.dwarf2/dw2-ranges-func.exp: New file.
|
|
gdb/testsuite/ChangeLog:
* gdb.dwarf2/varval.c: New file.
* gdb.dwarf2/varval.exp: New file.
|
|
The version check of the dwarf compilation unit header in
error_check_comp_unit_head is done too late, and consequently dwarf code with
an unsupported version in the compilation unit header is interpreted as dwarf5
code in read_comp_unit_head.
Fixed by moving the check earlier.
Build and reg-tested on x86_64-linux.
2018-07-04 Tom de Vries <tdevries@suse.de>
* dwarf2read.c (error_check_comp_unit_head): Move dwarf version
check ...
(read_comp_unit_head): ... here.
* gdb.dwarf2/dw2-error.exp: Update expected error message.
|
|
TYPE_TAG_NAME has been an occasional source of confusion and bugs. It
seems to me that it is only useful for C and C++ -- but even there,
not so much, because at least with DWARF there doesn't seem to be any
way to wind up with a type where the name and the tag name are both
non-NULL and different.
So, this patch removes TYPE_TAG_NAME entirely. This should save a
little memory, but more importantly, it simplifies this part of gdb.
A few minor test suite adjustments were needed. In some situations
the new code does not yield identical output to the old code.
gdb/ChangeLog
2018-06-01 Tom Tromey <tom@tromey.com>
* valops.c (enum_constant_from_type, value_namespace_elt)
(value_maybe_namespace_elt): Update.
* valarith.c (find_size_for_pointer_math): Update.
* target-descriptions.c (make_gdb_type): Update.
* symmisc.c (print_symbol): Update.
* stabsread.c (define_symbol, read_type)
(complain_about_struct_wipeout, add_undefined_type)
(cleanup_undefined_types_1): Update.
* rust-lang.c (rust_tuple_type_p, rust_slice_type_p)
(rust_range_type_p, val_print_struct, rust_print_struct_def)
(rust_internal_print_type, rust_composite_type)
(rust_evaluate_funcall, rust_evaluate_subexp)
(rust_inclusive_range_type_p): Update.
* python/py-type.c (typy_get_tag): Update.
* p-typeprint.c (pascal_type_print_base): Update.
* mdebugread.c (parse_symbol, parse_type): Update.
* m2-typeprint.c (m2_long_set, m2_record_fields, m2_enum):
Update.
* guile/scm-type.c (gdbscm_type_tag): Update.
* go-lang.c (sixg_string_p): Update.
* gnu-v3-abi.c (build_gdb_vtable_type, build_std_type_info_type):
Update.
* gdbtypes.h (struct main_type) <tag_name>: Remove.
(TYPE_TAG_NAME): Remove.
* gdbtypes.c (type_name_no_tag): Simplify.
(check_typedef, check_types_equal, recursive_dump_type)
(copy_type_recursive, arch_composite_type): Update.
* f-typeprint.c (f_type_print_base): Update. Print "Type" prefix
in summary mode when needed.
* eval.c (evaluate_funcall): Update.
* dwarf2read.c (fixup_go_packaging, read_structure_type)
(process_structure_scope, read_enumeration_type)
(read_namespace_type, read_module_type, determine_prefix): Update.
* cp-support.c (inspect_type): Update.
* coffread.c (process_coff_symbol, decode_base_type): Update.
* c-varobj.c (c_is_path_expr_parent): Update.
* c-typeprint.c (c_type_print_base_struct_union): Update.
(c_type_print_base_1): Update. Print struct/class/union/enum in
summary when using C language.
* ax-gdb.c (gen_struct_ref, gen_namespace_elt)
(gen_maybe_namespace_elt): Update.
* ada-lang.c (ada_type_name): Simplify.
(empty_record, ada_template_to_fixed_record_type_1)
(template_to_static_fixed_type)
(to_record_with_fixed_variant_part, ada_check_typedef): Update.
gdb/testsuite/ChangeLog
2018-06-01 Tom Tromey <tom@tromey.com>
* gdb.xml/tdesc-regs.exp (load_description): Update expected
results.
* gdb.dwarf2/method-ptr.exp: Set language to C++.
* gdb.dwarf2/member-ptr-forwardref.exp: Set language to C++.
* gdb.cp/typeid.exp (do_typeid_tests): Update type_re.
* gdb.base/maint.exp (maint_pass_if): Update.
|
|
This patch essentially causes GDB to treat inlined frames like "normal"
frames from the user's perspective. This means, for example, that when a
user sets a breakpoint in an inlined function, GDB will now actually stop
"in" that function.
Using the test case from breakpoints/17534,
3 static inline void NVIC_EnableIRQ(int IRQn)
4 {
5 volatile int y;
6 y = IRQn;
7 }
8
9 __attribute__( ( always_inline ) ) static inline void __WFI(void)
10 {
11 __asm volatile ("nop");
12 }
13
14 int main(void) {
15
16 x= 42;
17
18 if (x)
19 NVIC_EnableIRQ(16);
20 else
21 NVIC_EnableIRQ(18);
(gdb) b NVIC_EnableIRQ
Breakpoint 1 at 0x4003e4: NVIC_EnableIRQ. (2 locations)
(gdb) r
Starting program: 17534
Breakpoint 1, main () at 17534.c:19
19 NVIC_EnableIRQ(16);
Because skip_inline_frames currently skips every inlined frame, GDB "stops"
in the caller. This patch adds a new parameter to skip_inline_frames
that allows us to pass in a bpstat stop chain. The breakpoint locations
on the stop chain can be used to determine if we've stopped inside an inline
function (due to a user breakpoint). If we have, we do not elide the frame.
With this patch, GDB now reports that the inferior has stopped inside the
inlined function:
(gdb) r
Starting program: 17534
Breakpoint 1, NVIC_EnableIRQ (IRQn=16) at 17534.c:6
6 y = IRQn;
Many thanks to Jan and Pedro for guidance on this.
gdb/ChangeLog:
* breakpoint.c (build_bpstat_chain): New function, moved from
bpstat_stop_status.
(bpstat_stop_status): Add optional parameter, `stop_chain'.
If no stop chain is passed, call build_bpstat_chain to build it.
* breakpoint.h (build_bpstat_chain): Declare.
(bpstat_stop_status): Move documentation here from breakpoint.c.
* infrun.c (handle_signal_stop): Before eliding inlined frames,
build the stop chain and pass it to skip_inline_frames.
Pass this stop chain to bpstat_stop_status.
* inline-frame.c: Include breakpoint.h.
(stopped_by_user_bp_inline_frame): New function.
(skip_inline_frames): Add parameter `stop_chain'.
Move documention to inline-frame.h.
If non-NULL, use stopped_by_user_bp_inline_frame to determine
whether the frame should be elided.
* inline-frame.h (skip_inline_frames): Add parameter `stop_chain'.
Add moved documentation and update for new parameter.
gdb/testsuite/ChangeLog:
* gdb.ada/bp_inlined_func.exp: Update inlined frame locations
in expected breakpoint stop locations.
* gdb.dwarf2/implptr.exp (implptr_test_baz): Use up/down to
move to proper scope to test variable values.
* gdb.opt/inline-break.c (inline_func1, not_inline_func1)
(inline_func2, not_inline_func2, inline_func3, not_inline_func3):
New functions.
(main): Call not_inline_func3.
* gdb.opt/inline-break.exp: Start inferior and set breakpoints at
inline_func1, inline_func2, and inline_func3. Test that when each
breakpoint is hit, GDB properly reports both the stop location
and the backtrace. Repeat tests for temporary breakpoints.
|
|
This adds alignof and _Alignof to the C/C++ expression parser, and
adds new tests to test the features. The tests are written to try to
ensure that gdb's knowledge of alignment rules stays in sync with the
compiler's.
2018-04-30 Tom Tromey <tom@tromey.com>
PR exp/17095:
* NEWS: Update.
* std-operator.def (UNOP_ALIGNOF): New operator.
* expprint.c (dump_subexp_body_standard) <case UNOP_ALIGNOF>:
New.
* eval.c (evaluate_subexp_standard) <case UNOP_ALIGNOF>: New.
* c-lang.c (c_op_print_tab): Add alignof.
* c-exp.y (ALIGNOF): New token.
(exp): Add "ALIGNOF" production.
(ident_tokens): Add _Alignof and alignof.
2018-04-30 Tom Tromey <tom@tromey.com>
PR exp/17095:
* gdb.dwarf2/dw2-align.exp: New file.
* gdb.cp/align.exp: New file.
* gdb.base/align.exp: New file.
* lib/gdb.exp (gdb_int128_helper): New proc.
(has_int128_c, has_int128_cxx): New caching procs.
|
|
The GDB commands "info variables", "info functions", and "info types" show
the appropriate list of definitions matching the given pattern. They also
group them by source files. But no line numbers within these source files
are shown.
The line number information is particularly useful to the user when a
simple "grep" doesn't readily point to a definition. This is often the
case when the definition involves a macro, occurs within a namespace, or
when the identifier appears very frequently in the source file.
This patch enriches the printout of these commands by the line numbers and
adjusts affected test cases to the changed output where necessary. The
new output looks like this:
(gdb) i variables
All defined variables:
File foo.c:
3: const char * const foo;
1: int x;
The line number is followed by a colon and a tab character, which is then
followed by the symbol definition. If no line number is available, the
tab is printed out anyhow, so definitions line up.
gdb/ChangeLog:
* symtab.c (print_symbol_info): Precede the symbol definition by
the line number when available.
* NEWS: Advertise this enhancement.
gdb/doc/ChangeLog:
* gdb.texinfo (Symbols): Mention the fact that "info
variables/functions/types" show source files and line numbers.
gdb/testsuite/ChangeLog:
* gdb.ada/info_types.exp: Adjust expected output to the line
numbers now printed by "info var/func/type".
* gdb.base/completion.exp: Likewise.
* gdb.base/included.exp: Likewise.
* gdb.cp/cp-relocate.exp: Likewise.
* gdb.cp/cplusfuncs.exp: Likewise.
* gdb.cp/namespace.exp: Likewise.
* gdb.dwarf2/dw2-case-insensitive.exp: Likewise.
|
|
This changes dwarf2read to understand DW_TAG_variant_part and
DW_TAG_variant.
Note that DW_AT_discr_list is not handled. I did not need this for
Rust. I imagine this should not be too hard to add later, should
someone need it. Meanwhile I have gdb emit a complaint if it is seen.
There is a lurking issue concerning the placement of the discriminant
in the DWARF. For Rust, I ended up following the letter of the
standard and having the discriminant be a child of the
DW_TAG_variant_part. However, GCC's Ada support does not do this.
Pierre-Marie filed this with the DWARF committee:
http://dwarfstd.org/ShowIssue.php?issue=180123.1
However as that is read-only, if you have comments you might consider
adding them to the GCC bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83935
Finally, there is a DWARF extension lurking in here. In Rust, a
univariant enum will not have a discriminant. However, in order to
unify the representation of all data-carrying enums, I've made LLVM
(and my forthcoming rustc patch) emit a univariant enum using a
DW_TAG_variant with a single variant part and without DW_AT_discr.
The lack of this DW_AT_discr is the extension. I will submit an issue
on dwarfstd.org about this.
2018-02-26 Tom Tromey <tom@tromey.com>
* dwarf2read.c (struct variant_field): New.
(struct nextfield) <variant>: New field.
(dwarf2_add_field): Handle DW_TAG_variant_part.
(dwarf2_attach_fields_to_type): Attach a discriminant_info to a
discriminated union.
(read_structure_type): Handle DW_TAG_variant_part.
(handle_struct_member_die): New function, extracted from
process_structure_scope. Handle DW_TAG_variant.
(process_structure_scope): Handle discriminated unions. Call
handle_struct_member_die.
2018-02-26 Tom Tromey <tom@tromey.com>
* gdb.dwarf2/variant.c: New file.
* gdb.dwarf2/variant.exp: New file.
|
|
gdb/ChangeLog:
Update copyright year range in all GDB files
|
|
Consider the following Ada code defining a global variable whose
type is an array of static bounds (1 .. 2), but where its elements
are a variant record whose size is not statically known:
type Ints is array (Natural range <>) of Integer;
type Bounded_Ints (Max_Size : Natural) is record
Length : Natural := 0;
Objs : Ints (1 .. Max_Size);
end record;
type Ints_Doubled is array (1 .. 2) of Bounded_Ints (Idem (0));
Global : Ints_Doubled;
When compiling this program at -O2 using a GCC-6.4-based compiler
on x86_64-linux, trying to print the value of that global variable
yields:
(gdb) p global
$1 =
Let's look at the debugging info, which starts with the global
variable itself...
.uleb128 0x19 # (DIE (0x25e) DW_TAG_variable)
.long .LASF32 # DW_AT_name: "fd__global"
.long 0x273 # DW_AT_type
... its type is a reference to a typedef ...
.uleb128 0x14 # (DIE (0x273) DW_TAG_reference_type)
.byte 0x8 # DW_AT_byte_size
.long 0x202 # DW_AT_type
[...]
.uleb128 0x15 # (DIE (0x202) DW_TAG_typedef)
.long .LASF19 # DW_AT_name: "fd__ints_doubled"
.long 0x20d # DW_AT_type
... of an array (1..2) ...
.uleb128 0x2 # (DIE (0x20d) DW_TAG_array_type)
.long .LASF19 # DW_AT_name: "fd__ints_doubled"
.long 0x15b # DW_AT_type
.long 0x221 # DW_AT_sibling
.uleb128 0x16 # (DIE (0x21a) DW_TAG_subrange_type)
.long 0x40 # DW_AT_type
.sleb128 2 # DW_AT_upper_bound
.byte 0 # end of children of DIE 0x20d
... of a struct whose name is fd__Tints_doubledC:
.uleb128 0x10 # (DIE (0x15b) DW_TAG_structure_type)
.long .LASF11 # DW_AT_name: "fd__Tints_doubledC"
.long 0x1e4 # DW_AT_GNAT_descriptive_type
# DW_AT_artificial
.long 0x1e4 # DW_AT_sibling
.uleb128 0x7 # (DIE (0x16a) DW_TAG_member)
.long .LASF4 # DW_AT_name: "max_size"
[snip]
The error occurs while Ada evaluator is trying to "fix"
the element type inside the array, so as to determine its actual
size. For that, it searches for a parallel "XVZ" variable,
which, when found, contains the object's actual size.
Unfortunately in our case, the variable exists but has been
optimized out, as seen by the presence of a variable DIE in
the debugging info, but with no address attribute:
.uleb128 0x18 # (DIE (0x24e) DW_TAG_variable)
.long .LASF31 # DW_AT_name: "fd__Tints_doubledC___XVZ"
.long 0x257 # DW_AT_type
# DW_AT_artificial
Discussing this with some members of AdaCore's compiler team,
it is expected that the optimizer can get rid of this variable,
and we don't want to pessimize the code just to improve debuggability,
since -O2 is about performance. So, the idea of this patch is
not to make it work, but provide a bit more information to help
users understand what kind of error is preventing GDB from being
able to print the variable's value.
The first hurdle we had to clear was the fact that ada_val_print
traps all exceptions (including QUIT ones!), and does so completly
silently. So, the fix was to add a trace of the exception being
generated. While doing so, we fix an old XXX/FIXME by only catching
errors, letting QUIT exceptions go through.
Once this is done, we now get an error message, which gives a first
clue as to what was happening:
(gdb) p fd.global
$1 = <error reading variable: value has been optimized out>
However, it would be more useful to know which value it was
that was optimized out. For that purpose, we enhanced
ada-lang.c::ada_to_fixed_type_1 so as to re-throw the error
with a message which indicates which variable we failed to read.
With those changes, the new output is now:
(gdb) p fd.global
$1 = <error reading variable: unable to read value of fd__Tints_doubledC___XVZ (value has been optimized out)>
gdb/ChangeLog:
* ada-lang.c (ada_to_fixed_type_1): Rethrow errors with
a more detailed exception message when getting an exception
while trying to read the value of an XVZ variable.
* ada-valprint.c (ada_val_print): Only catch RETURN_MASK_ERROR
exceptions. Print an error message when an exception is caught.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/ada-valprint-error.c: New file.
* gdb.dwarf2/ada-valprint-error.exp: New file.
Tested on x86_64-linux
|
|
Some testcases needed to be updated as they were missing
.debug_aranges. While that does not matter for no-index (as GDB
builds the mapping internally during dwarf2_build_psymtabs_hard) and
neither for .gdb_index (as GDB uses that internally built mapping
which it stores into .gdb_index) it does matter for .debug_names as
that simply assumes existing .debug_aranges from GCC.
gdb/ChangeLog:
2017-12-08 Jan Kratochvil <jan.kratochvil@redhat.com>
Pedro Alves <palves@redhat.com>
* defs.h (elf_sym_fns_debug_names): New declaration.
* dwarf2read.c: Include "hash_enum.h".
(mapped_debug_names): New.
(struct dwarf2_per_objfile): Add debug_names, debug_aranges and
debug_names_table.
(dwarf2_elf_names): Add ".debug_names" and ".debug_aranges".
(struct dwz_file): Add debug_names.
(dwarf2_per_objfile::locate_sections): Handle debug_names and
debug_aranges.
(locate_dwz_sections): Handle debug_names.
(create_signatured_type_table_from_debug_names)
(create_addrmap_from_aranges): New.
(dwarf2_read_index): Update function comment.
(dwarf5_augmentation): Moved up.
(read_debug_names_from_section, create_cus_from_debug_names_list)
(create_cus_from_debug_names, dwarf2_read_debug_names): New.
(dwarf5_djb_hash): Moved up.
(dw2_debug_names_iterator): New.
(read_indirect_string_at_offset): New declaration.
(mapped_debug_names::namei_to_name)
(dw2_debug_names_iterator::find_vec_in_debug_names)
(dw2_debug_names_iterator::next, dw2_debug_names_lookup_symbol)
(dw2_debug_names_dump, dw2_debug_names_expand_symtabs_for_function)
(dw2_debug_names_expand_symtabs_matching, dwarf2_debug_names_functions):
New.
(dwarf2_initialize_objfile): Return also elf_sym_fns_debug_names.
(debug_names::djb_hash): Rename it to dwarf5_djb_hash.
(debug_names::build): Update djb_hash caller.
(write_debug_names): Move out and rename augmentation to
dwarf5_augmentation.
* elfread.c (elf_sym_fns_debug_names): New.
* psymtab.h (dwarf2_debug_names_functions): New declaration.
* symfile.h (struct dwarf2_debug_sections): Add debug_names and
debug_aranges.
* xcoffread.c (dwarf2_xcoff_names): Add debug_names and debug_aranges.
gdb/testsuite/ChangeLog:
2017-12-08 Jan Kratochvil <jan.kratochvil@redhat.com>
Pedro Alves <palves@redhat.com>
* gdb.base/maint.exp (check for .gdb_index): Check also for
.debug_names.
* gdb.dlang/watch-loc.c (.debug_aranges): New.
* gdb.dwarf2/dw2-case-insensitive-debug.S: Likewise.
* gdb.dwarf2/gdb-index.exp (check if index present, .gdb_index used)
(.gdb_index used after symbol reloading): Support also .debug_names.
* gdb.mi/dw2-ref-missing-frame-func.c (.debug_aranges): New.
|
|
Currently, optimized out variables are not shown when doing "info
locals". Some users found that confusing, thinking GDB forgot to print
their variable. This patch adds them to the "info locals" output. I
added a test in gdb.dwarf2 to test for that behavior. I think doing a
synthetic DWARF test is the easiest way to have an optimized out local
variable for sure.
However, this change reveals what I think is a bug in GDB, see:
http://lists.dwarfstd.org/pipermail/dwarf-discuss-dwarfstd.org/2017-September/004394.html
This patch marks the tests in inline-locals.exp that start failing as
KFAIL. I'd like to tackle this bug eventually, but I don't have the
time right now. I think it's still better to show an extra erroneous
entry than to not show the optimized out variables at all. I haven't
created a bug in bugzilla yet, but if we agree it's indeed a bug, I'll
create one and update the setup_kfail lines with the actual bug number
before pushing.
gdb/ChangeLog:
* stack.c (iterate_over_block_locals): Add LOC_OPTIMIZED_OUT
case in switch.
gdb/testsuite/ChangeLog:
* gdb.opt/inline-locals.exp: Mark tests as KFAIL.
* gdb.dwarf2/info-locals-optimized-out.exp: New file.
* gdb.dwarf2/info-locals-optimized-out.c: New file.
|
|
gdb.dwarf2/pr10770.exp can be used for non-gcc compiler, at least clang.
This patch removes the restriction to only use gcc. If other compilers,
like xlc or icc, can't compile the .c file, test result is not changed.
gdb/testsuite:
2017-11-22 Yao Qi <yao.qi@linaro.org>
* gdb.dwarf2/pr10770.exp: Remove code skipping non-gcc
compiler.
|
|
An earlier commit made GDB no longer assume no-debug-info functions
return int. This commit gives the same treatment to variables.
Currently, you can end misled by GDB over output like this:
(gdb) p var
$1 = -1
(gdb) p /x var
$2 = 0xffffffff
until you realize that GDB is assuming that the variable is an "int",
because:
(gdb) ptype var
type = <data variable, no debug info>
You may try to fix it by casting, but that doesn't really help:
(gdb) p /x (unsigned long long) var
$3 = 0xffffffffffffffff # incorrect
^^
That's incorrect output, because the variable was defined like this:
uint64_t var = 0x7fffffffffffffff;
^^
What happened is that with the cast, GDB did an int -> 'unsigned long
long' conversion instead of reinterpreting the variable as the cast-to
type. To get at the variable properly you have to reinterpret the
variable's address manually instead, with either:
(gdb) p /x *(unsigned long long *) &var
$4 = 0x7fffffffffffffff
(gdb) p /x {unsigned long long} &var
$5 = 0x7fffffffffffffff
After this commit GDB does it for you. This is what you'll get
instead:
(gdb) p var
'var' has unknown type; cast it to its declared type
(gdb) p /x (unsigned long long) var
$1 = 0x7fffffffffffffff
As in the functions patch, the "compile" machinery doesn't currently
have the cast-to type handy, so it continues assuming no-debug
variables have int type, though now at least it warns.
The change to gdb.cp/m-static.exp deserves an explanation:
- gdb_test "print 'gnu_obj_1::method()::sintvar'" "\\$\[0-9\]+ = 4" \
+ gdb_test "print (int) 'gnu_obj_1::method()::sintvar'" "\\$\[0-9\]+ = 4" \
That's printing the "sintvar" function local static of the
"gnu_obj_1::method()" method.
The problem with that test is that that "'S::method()::static_var'"
syntax doesn't really work in C++ as you'd expect. The way to make it
work correctly currently is to quote the method part, not the whole
expression, like:
(gdb) print 'gnu_obj_1::method()'::sintvar
If you wrap the whole expression in quotes, like in m-static.exp, what
really happens is that the parser considers the whole string as a
symbol name, but there's no debug symbol with that name. However,
local statics have linkage and are given a mangled name that demangles
to the same string as the full expression, so that's what GDB prints.
After this commit, and without the cast, the print in m-static.exp
would error out saying that the variable has unknown type:
(gdb) p 'gnu_obj_1::method()::sintvar'
'gnu_obj_1::method()::sintvar' has unknown type; cast it to its declared type
TBC, if currently (even before this series) you try to print any
function local static variable of type other than int, you'll get
bogus results. You can see that with m-static.cc as is, even.
Printing the "svar" local, which is a boolean (1 byte) still prints as
"int" (4 bytes):
(gdb) p 'gnu_obj_1::method()::svar'
$1 = 1
(gdb) ptype 'gnu_obj_1::method()::svar'
type = <data variable, no debug info>
This probably prints some random bogus value on big endian machines.
If 'svar' was of some aggregate type (etc.) we'd still print it as
int, so the problem would have been more obvious... After this
commit, you'll get instead:
(gdb) p 'gnu_obj_1::method()::svar'
'gnu_obj_1::method()::svar' has unknown type; cast it to its declared type
... so at least GDB is no longer misleading. Making GDB find the real
local static debug symbol is the subject of the following patches. In
the end, it'll all "Just Work".
gdb/ChangeLog:
2017-09-04 Pedro Alves <palves@redhat.com>
* ax-gdb.c: Include "typeprint.h".
(gen_expr_for_cast): New function.
(gen_expr) <OP_CAST, OP_CAST_TYPE>: Use it.
<OP_VAR_VALUE, OP_MSYM_VAR_VALUE>: Error out if the variable's
type is unknown.
* dwarf2read.c (new_symbol_full): Fallback to int instead of
nodebug_data_symbol.
* eval.c: Include "typeprint.h".
(evaluate_subexp_standard) <OP_VAR_VALUE, OP_VAR_MSYM_VALUE>:
Error out if symbol has unknown type.
<UNOP_CAST, UNOP_CAST_TYPE>: Common bits factored out to
evaluate_subexp_for_cast.
(evaluate_subexp_for_address, evaluate_subexp_for_sizeof): Handle
OP_VAR_MSYM_VALUE.
(evaluate_subexp_for_cast): New function.
* gdbtypes.c (init_nodebug_var_type): New function.
(objfile_type): Use it to initialize types of variables with no
debug info.
* typeprint.c (error_unknown_type): New.
* typeprint.h (error_unknown_type): New declaration.
* compile/compile-c-types.c (convert_type_basic): Handle
TYPE_CODE_ERROR; warn and fallback to int for variables with
unknown type.
gdb/testsuite/ChangeLog:
2017-09-04 Pedro Alves <palves@redhat.com>
* gdb.asm/asm-source.exp: Add casts to int.
* gdb.base/nodebug.c (dataglobal8, dataglobal32_1, dataglobal32_2)
(dataglobal64_1, dataglobal64_2): New globals.
* gdb.base/nodebug.exp: Test different expressions involving the
new globals, with print, whatis and ptype. Add casts to int.
* gdb.base/solib-display.exp: Add casts to int.
* gdb.compile/compile-ifunc.exp: Expect warning. Add cast to int.
* gdb.cp/m-static.exp: Add cast to int.
* gdb.dwarf2/dw2-skip-prologue.exp: Add cast to int.
* gdb.threads/tls-nodebug.exp: Check that gdb errors out printing
tls variable with no debug info without a cast. Test with a cast
to int too.
* gdb.trace/entry-values.exp: Add casts.
|
|
PR gdb/21675 points out a few regressions in scalar printing.
One type of regression is due to not carrying over the old handling of
floating point printing -- where a format like "/d" causes a floating
point number to first be cast to a signed integer. This patch restores
this behavior.
The other regression is a longstanding bug in print_octal_chars: one of
the constants was wrong. This patch fixes the constant and adds static
asserts to help catch this sort of error.
ChangeLog
2017-08-14 Tom Tromey <tom@tromey.com>
PR gdb/21675
* valprint.c (LOW_ZERO): Change value to 034.
(print_octal_chars): Add static_asserts for octal constants.
* printcmd.c (print_scalar_formatted): Add 'd' case.
testsuite/ChangeLog
2017-08-14 Tom Tromey <tom@tromey.com>
PR gdb/21675:
* gdb.base/printcmds.exp (test_radices): New function.
* gdb.dwarf2/var-access.exp: Use p/u, not p/d.
* gdb.base/sizeof.exp (check_valueof): Use p/d.
* lib/gdb.exp (get_integer_valueof): Use p/d.
|
|
This Rust bug report:
https://github.com/rust-lang/rust/issues/41970
noted an error from gdb. What is happening here (for me, the original
report had a different error) is that a pieced DWARF expression is not
writing to every byte in the resulting value. GDB errors in this
case. However, it seems to me that it is always valid to write fewer
bytes; the issue comes from writing too many -- that is, the test is
reversed. The test was also checking the sub-object, but this also
seems incorrect, as it's expected for the expression to write the
entirety of the enclosing object. So, this patch reverses the test
and applies it to the outer type, not the subobject type.
Regtested on the buildbot.
gdb/ChangeLog
2017-07-09 Tom Tromey <tom@tromey.com>
* dwarf2loc.c (dwarf2_evaluate_loc_desc_full): Reverse size
check and apply to outer type.
gdb/testsuite/ChangeLog
2017-07-09 Tom Tromey <tom@tromey.com>
* gdb.dwarf2/shortpiece.exp: New file.
|
|
In some cases a compiler may produce a single object file (& thus single
DWO file) representing multiple source files. The most common example of
this is in whole program optimization (such as LLVM's LTO). Fission may
still be a beneficial feature to use here - to avoid the need to
read/link the debug info with system libraries and the like.
This change adds basic support for multiple CUs in a single DWO file to
support LLVM's output in this situation.
There is still outstanding work to design and implement a solution for
cross-CU references (usually using DW_FORM_ref_addr) in this scenario.
For now LLVM works around this by duplicating DIEs rather than making
cross-CU references in DWO files. This degrades debugger
behavior/quality especially for file-local entities.
2017-07-06 David Blaikie <dblaikie@gmail.com>
* dwarf2read.c (struct dwo_file): Use a htab of dwo_unit* (rather than
a singular dwo_unit*) to support multiple CUs in the same way that
multiple TUs are supported.
(create_cus_hash_table): Replace create_dwo_cu with a function for
parsing multiple CUs from a DWO file.
(open_and_init_dwo_file): Use create_cus_hash_table rather than
create_dwo_cu.
(lookup_dwo_cutu): Lookup CU in the hash table in the dwo_file with
htab_find, rather than comparing the signature to a singleton CU in
the dwo_file.
2017-07-06 David Blaikie <dblaikie@gmail.com>
* gdb.dwarf2/fission-multi-cu.S: Test containing multiple CUs in a DWO,
built from fissiont-multi-cu{1,2}.c.
* gdb.dwarf2/fission-multi-cu.exp: Test similar to fission-base.exp,
except putting 'main' and 'func' in separate CUs in the same DWO file.
* gdb.dwarf2/fission-multi-cu1.c: First CU for the multi-CU-single-DWO
test.
* gdb.dwarf2/fission-multi-cu2.c: Second CU in the multi-CU-single-DWO
test.
|
|
The new test var-access.exp causes FAILs on i686. This is because the
test chooses the wrong name for DWARF register number 1: It uses
"edx" (which corresponds to DWARF register number 2), but should have used
"ecx" instead.
Also, the current logic in var-access.exp does not correctly distinguish
between a 64-bit and a 32-bit program on an x86-64 target. It uses the
64-bit register names for both.
These problems are fixed. In order to address the latter, the convenience
macros is_*_target are exploited where appropriate.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/var-access.exp: Use register name ecx instead of edx
on 32-bit x86 targets. Exploit is_*_target macros where
appropriate.
|
|
So far GDB ignores the piece offset of all kinds of DWARF bit
pieces (DW_OP_bit_piece) and treats such pieces as if the offset was zero.
This is fixed, and an appropriate test is added.
gdb/ChangeLog:
* dwarf2loc.c (read_pieced_value): Respect the piece offset, as
given by DW_OP_bit_piece.
(write_pieced_value): Likewise.
Andreas Arnez <arnez@linux.vnet.ibm.com>
* gdb.dwarf2/var-access.exp: Add test for composite location with
nonzero piece offsets.
|
|
For big-endian targets the logic in read/write_pieced_value tries to take
a register piece from the LSB end. This requires offsets and sizes to be
adjusted accordingly, and that's where the current implementation has some
issues:
* The formulas for recalculating the bit- and byte-offsets into the
register are wrong. They just happen to yield correct results if
everything is byte-aligned and the piece's last byte belongs to the
given value.
* After recalculating the bit offset into the register, the number of
bytes to be copied from the register is not recalculated. Of course
this does not matter if everything (particularly the piece size) is
byte-aligned.
These issues are fixed. The size calculation is performed with a new
helper function bits_to_bytes().
gdb/ChangeLog:
* dwarf2loc.c (bits_to_bytes): New function.
(read_pieced_value): Fix offset calculations for register pieces
on big-endian targets.
(write_pieced_value): Likewise.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/var-access.exp: Add test for non-byte-aligned
register pieces.
|
|
This verifies some of the previous fixes to the logic in
write_pieced_value when accessing bit-fields.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/var-access.exp: Add tests for accessing bit-fields
located in one or more DWARF pieces.
|
