When building gdb on s390x with -m31, we run into this error:
...
gdb/gdbserver/linux-s390-ipa.c: \
In function 'const target_desc* get_ipa_tdesc(int)':
gdb/gdbserver/linux-s390-ipa.c:371:18: error: 's390_te_ft_collect_regmap' \
was not declared in this scope
SET_REGMAP(s390_te_ft_collect_regmap, 0);
The offending line is part of this code snippet:
...
case S390_TDESC_GS:
SET_REGMAP(s390_te_ft_collect_regmap, 0);
return tdesc_s390_gs_linux64;
...
introduced in commit ce29f8439f "S390: Make IPA recognize tdescs with guarded
storage".
The snippet is part of an #ifdef __s390x__ construct, in the false branch, and
in the true branch we find a snippet introduced by the same commit:
...
case S390_TDESC_GS:
SET_REGMAP(s390x_te_ft_collect_regmap, 0);
return tdesc_s390x_gs_linux64;
...
which is paired with a comment update for s390x_te_ft_collect_regmap:
...
-/* Used for s390x-te-linux64, s390x-tevx-linux64. */
+/* Used for s390x-te-linux64, s390x-tevx-linux64, and
+ s390x-gs-linux64. */
static const int s390x_te_ft_collect_regmap[] = {
...
A similar comment update is added in the same commit for
s390_te_linux64_ft_collect_regmap:
...
-/* Used for s390-te-linux64, s390-tevx-linux64. */
+/* Used for s390-te-linux64, s390-tevx-linux64, and s390-gs-linux64. */
static const int s390_te_linux64_ft_collect_regmap[] = {
...
but not paired with any update.
Fix the build breaker by making the offending SET_REGMAP use the regmap
indicated by the comment.
...
- SET_REGMAP(s390_te_ft_collect_regmap, 0);
+ SET_REGMAP(s390_te_linux64_ft_collect_regmap, 0);
...
Build on s390x-linux with -m31.
gdb/gdbserver/ChangeLog:
2019-06-20 Tom de Vries <tdevries@suse.de>
* linux-s390-ipa.c (get_ipa_tdesc)[!__s390x__]: Use
s390_te_linux64_ft_collect_regmap for S390_TDESC_GS.
I noticed that tui_init_content_element is declared but never defined.
This removes the declaration. Tested by rebuilding. (I should have
merged this with the previous patch but I had forgotten that I found
two of these.)
gdb/ChangeLog
2019-06-19 Tom Tromey <tom@tromey.com>
* tui/tui-data.h (tui_init_content_element): Don't declare.
I noticed that tui_init_win_info is declared but never defined. This
removes the declaration. Tested by rebuilding.
gdb/ChangeLog
2019-06-19 Tom Tromey <tom@tromey.com>
* tui/tui-data.h (tui_init_win_info): Don't declare.
Building gdb with clang, I run into:
...
src/gdb/gdbserver/linux-low.c:6190:41: error: comparison of unsigned \
expression < 0 is always false [-Werror,-Wtautological-compare]
if (debug_write ("sigchld_handler\n",
sizeof ("sigchld_handler\n") - 1) < 0)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ ~
...
This regression is introduced by commit a7e559cc08 "gdbserver: Ensure all
debug output uses debug functions", which replaces calls to write with result
type ssize_t with calls to debug_write with result type size_t.
Fix this by making debug_write return ssize_t.
Build and reg-tested on x86_64-linux.
gdb/gdbserver/ChangeLog:
2019-06-19 Tom de Vries <tdevries@suse.de>
* debug.h (debug_write): Change return type to ssize_t.
* debug.c (debug_write): Same.
When compiling with gcc 4.8, we run into:
...
/usr/include/c++/4.8/bits/unordered_map.h💯18: required from \
‘class std::unordered_map<sect_offset, std::vector<sect_offset> >’
src/gdb/dwarf2read.h:260:5: required from here
/usr/include/c++/4.8/bits/hashtable_policy.h:1070:12: error: invalid use of \
incomplete type ‘struct std::hash<sect_offset>’
...
Fix this by setting the Hash template parameter of the unordered_map to
gdb::hash_enum<sect_offset>, rather than using the default
std::hash<sect_offset>.
Build and reg-tested on x86_64-linux with gcc 4.8.
gdb/ChangeLog:
2019-06-19 Tom de Vries <tdevries@suse.de>
* dwarf2read.h (abstract_to_concrete): Change type to
std::unordered_map<sect_offset, std::vector<sect_offset>,
gdb::hash_enum<sect_offset>>.
Pedro pointed out that the new length_cond.exp test did not have an
intro comment. This adds one.
gdb/testsuite/ChangeLog
2019-06-19 Tom Tromey <tromey@adacore.com>
* gdb.ada/length_cond.exp: Add intro comment.
gdb could crash when setting a breakpoint condition on a breakpoint
when using the Ada language. The problem occurred because the
ada_evaluate_subexp would try to evaluate the array to compute its
attributes, but evaluating can't really be done at this time.
This patch fixes the problem by arranging not to try to evaluate in
EVAL_AVOID_SIDE_EFFECTS mode when computing an attribute.
Tested on x86-64 Fedora 29. Because this is Ada-specific, and because
Joel approved it internally, I am checking it in.
gdb/ChangeLog
2019-06-19 Tom Tromey <tromey@adacore.com>
* ada-lang.c (ada_evaluate_subexp) <case OP_ATR_FIRST>: Handle
EVAL_AVOID_SIDE_EFFECTS specially.
gdb/testsuite/ChangeLog
2019-06-19 Tom Tromey <tromey@adacore.com>
* gdb.ada/length_cond.exp: New file.
* gdb.ada/length_cond/length_cond.adb: New file.
* gdb.ada/length_cond/pck.adb: New file.
* gdb.ada/length_cond/pck.ads: New file.
It occurred to me that there's no reason to make a new source
highlighter each time gdb needs to highlight some source code.
Instead, a single one can be created and then simply reused each time.
This patch implements this idea. Tested on x86-64 Fedora 29.
gdb/ChangeLog
2019-06-19 Tom Tromey <tromey@adacore.com>
* source-cache.c (highlighter): New global.
(source_cache::get_source_lines): Create a highlighter on demand.
Calls from functions that don't have a valid toc pointer in r2 (these
calls are marked with _NOTOC relocs) to functions that require r2
valid must go via the callee global entry point. This patch corrects
the condition the linker was using to detect functions that require r2
to be valid. Values of both zero and one in st_other local entry bits
mean a function doesn't care about r2.
* elf64-ppc.c (ppc64_elf_inline_plt): Correct st_other test for
functions that require r2 valid to use local entry.
(ppc64_elf_size_stubs, ppc64_elf_relocate_section): Likewise.
The deprecated_interactive_hook is not used within GDB. It is used in
gdbtk, however this patch removes that use:
https://sourceware.org/ml/insight/2019-q2/msg00001.html
So I think there is no longer a reason to keep this hook around.
This patch removes it. There should be no user visible changes after
this commit.
gdb/ChangeLog:
* defs.h (deprecated_interactive_hook): Delete declaration.
* interps.c (clear_interpreter_hooks): Remove use of
deprecated_interactive_hook.
* top.c (deprecated_interactive_hook): Delete definition.
* utils.c (maybe_quit): Remove use of deprecated_interactive_hook.
The target board fission.exp requires the gold linker (because it supports
--gdb-index).
When running the target board on a system where the default linker is not
gold, most tests will fail to compile.
Fix this by adding "-fuse-ld=gold" ( supported in gcc since version 4.8).
gdb/testsuite/ChangeLog:
2019-06-18 Tom de Vries <tdevries@suse.de>
* boards/fission.exp (debug_flags): Add "-fuse-ld=gold".
The test-case varval.exp fails here:
...
FAIL: gdb.dwarf2/varval.exp: print varval2
...
with boards readnow/cc-with-gdb-index/cc-with-debug-names, as well as if gdb
is build with -fsanitize=address -lasan.
The problem is that the abstract_to_concrete map in which we track the
association of abstract to concrete DIEs (for DW_OP_GNU_variable_value
support) has type std::unordered_map<die_info_ptr, std::vector<die_info_ptr>>,
and the die_info_ptrs that we register in the map may be invalid by the time
that we start to lookup DIEs in the map.
Fix this by using the sect_offset instead to identify the DIEs in the map.
Build and tested on x86_64-linux.
gdb/ChangeLog:
2019-06-18 Tom de Vries <tdevries@suse.de>
PR gdb/24515
* dwarf2read.h (abstract_to_concrete): Change type from
std::unordered_map<die_info_ptr, std::vector<die_info_ptr>> to
std::unordered_map<sect_offset, std::vector<sect_offset>>.
* dwarf2read.c (read_variable): Update.
(dwarf2_fetch_die_loc_sect_off): Update.
Section "Invoking GDB" of the manual states that if you try to launch
gdb with:
gdb program 1234
it will try to attach to the process with id 1234, unless there is a
file named 1234 in the current working directory, in which case it will
try to open that file as a core. In fact, when the second argument
starts with a digit, GDB tries to attach to process 1234 first, before
trying to open file 1234 as a core. So that last remark is not true and
therefore this patch removes it.
The same remark is present in the man page, so it is removed there too.
Section "Choosing Files" correctly states:
If the second argument begins with a decimal digit, GDB will first
attempt to attach to it as a process, and if that fails, attempt to
open it as a corefile.
so it is unchanged.
Finally, the man page has an additional detail compared to section
"Invoking GDB", regarding the use of the -p switch, so I added the same
detail to the "Invoking GDB" section.
gdb/doc/ChangeLog:
* gdb.texinfo (Invoking GDB): Remove sentence about how GDB
deals with a file that has the same name as the specified pid to
attach to. Add example using -p option.
(gdb man): Remove same sentence as in previous item.
Pedro suggested adding a comment to list0.h to explain the control
character.
Tested on x86-64 Fedora 29.
gdb/testsuite/ChangeLog
2019-06-18 Tom Tromey <tromey@adacore.com>
* gdb.base/list0.h: Add comment explaining control character.
When compiling gdb with '-lasan -fsanitizer=address' and running tests with:
- export ASAN_OPTIONS="detect_leaks=0:alloc_dealloc_mismatch=0", and
- a target board using local-board.exp, which sets sysroot to ""
we run into a heap-buffer-overflow in child_path for f.i. gdb.arch/amd64-byte:
...
==3997==ERROR: AddressSanitizer: heap-buffer-overflow on address \
0x60200002abcf at pc 0x5602acdf6872 bp 0x7ffe5237a090 sp 0x7ffe5237a080
READ of size 1 at 0x60200002abcf thread T0
#0 0x5602acdf6871 in child_path(char const*, char const*) \
gdb/common/pathstuff.c:161
#1 0x5602adb06587 in find_separate_debug_file gdb/symfile.c:1483
#2 0x5602adb06f2f in find_separate_debug_file_by_debuglink[abi:cxx11](...) \
gdb/symfile.c:1563
#3 0x5602ad13b743 in elf_symfile_read gdb/elfread.c:1293
#4 0x5602adb01cfa in read_symbols gdb/symfile.c:798
#5 0x5602adb03769 in syms_from_objfile_1 gdb/symfile.c:1000
#6 0x5602adb039d0 in syms_from_objfile gdb/symfile.c:1017
#7 0x5602adb04551 in symbol_file_add_with_addrs gdb/symfile.c:1124
#8 0x5602adb04ebf in symbol_file_add_from_bfd(...) gdb/symfile.c:1204
#9 0x5602ada5a78d in solib_read_symbols(...) gdb/solib.c:695
#10 0x5602ada5bdae in solib_add(char const*, int, int) gdb/solib.c:1004
#11 0x5602ada49bcd in enable_break gdb/solib-svr4.c:2394
#12 0x5602ada4dae9 in svr4_solib_create_inferior_hook gdb/solib-svr4.c:3028
#13 0x5602ada5d4f1 in solib_create_inferior_hook(int) gdb/solib.c:1215
#14 0x5602ad347f66 in post_create_inferior(target_ops*, int) \
gdb/infcmd.c:467
#15 0x5602ad348b3c in run_command_1 gdb/infcmd.c:663
#16 0x5602ad348e55 in run_command gdb/infcmd.c:686
#17 0x5602acd7d32b in do_const_cfunc gdb/cli/cli-decode.c:106
#18 0x5602acd84bfe in cmd_func(cmd_list_element*, char const*, int) \
gdb/cli/cli-decode.c:1892
#19 0x5602adc62a90 in execute_command(char const*, int) gdb/top.c:630
#20 0x5602ad5053e6 in catch_command_errors gdb/main.c:372
#21 0x5602ad507eb1 in captured_main_1 gdb/main.c:1138
#22 0x5602ad5081ec in captured_main gdb/main.c:1163
#23 0x5602ad508281 in gdb_main(captured_main_args*) gdb/main.c:1188
#24 0x5602ac9ddc3a in main gdb/gdb.c:32
#25 0x7f582b56eb96 in __libc_start_main \
(/lib/x86_64-linux-gnu/libc.so.6+0x21b96)
#26 0x5602ac9dda09 in _start \
(/home/smarchi/build/binutils-gdb/gdb/gdb+0x19a2a09)
0x60200002abcf is located 1 bytes to the left of 1-byte region \
[0x60200002abd0,0x60200002abd1)
allocated by thread T0 here:
#0 0x7f582e0e4b50 in __interceptor_malloc \
(/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb50)
#1 0x5602acdd3656 in xmalloc gdb/common/common-utils.c:44
#2 0x5602aefe17d1 in xstrdup libiberty/xstrdup.c:34
#3 0x5602acdf61f6 in gdb_realpath(char const*) gdb/common/pathstuff.c:80
#4 0x5602adb06278 in find_separate_debug_file gdb/symfile.c:1444
#5 0x5602adb06f2f in find_separate_debug_file_by_debuglink[abi:cxx11](...) \
gdb/symfile.c:1563
#6 0x5602ad13b743 in elf_symfile_read gdb/elfread.c:1293
#7 0x5602adb01cfa in read_symbols gdb/symfile.c:798
#8 0x5602adb03769 in syms_from_objfile_1 gdb/symfile.c:1000
#9 0x5602adb039d0 in syms_from_objfile gdb/symfile.c:1017
#10 0x5602adb04551 in symbol_file_add_with_addrs gdb/symfile.c:1124
#11 0x5602adb04ebf in symbol_file_add_from_bfd(...) gdb/solib.c:695
#13 0x5602ada5bdae in solib_add(char const*, int, int) gdb/solib.c:1004
#14 0x5602ada49bcd in enable_break gdb/solib-svr4.c:2394
#15 0x5602ada4dae9 in svr4_solib_create_inferior_hook gdb/solib-svr4.c:3028
#16 0x5602ada5d4f1 in solib_create_inferior_hook(int) gdb/solib.c:1215
#17 0x5602ad347f66 in post_create_inferior(target_ops*, int) \
gdb/infcmd.c:467
#18 0x5602ad348b3c in run_command_1 gdb/infcmd.c:663
#19 0x5602ad348e55 in run_command gdb/infcmd.c:686
#20 0x5602acd7d32b in do_const_cfunc gdb/cli/cli-decode.c:106
#21 0x5602acd84bfe in cmd_func(cmd_list_element*, char const*, int) \
gdb/cli/cli-decode.c:1892
#22 0x5602adc62a90 in execute_command(char const*, int) gdb/top.c:630
#23 0x5602ad5053e6 in catch_command_errors gdb/main.c:372
#24 0x5602ad507eb1 in captured_main_1 gdb/main.c:1138
#25 0x5602ad5081ec in captured_main gdb/main.c:1163
#26 0x5602ad508281 in gdb_main(captured_main_args*) gdb/main.c:1188
#27 0x5602ac9ddc3a in main gdb/gdb.c:32
#28 0x7f582b56eb96 in __libc_start_main \
(/lib/x86_64-linux-gnu/libc.so.6+0x21b96)
SUMMARY: AddressSanitizer: heap-buffer-overflow gdb/common/pathstuff.c:161 \
in child_path(char const*, char const*)
Shadow bytes around the buggy address:
0x0c047fffd520: fa fa fd fd fa fa fd fd fa fa fd fa fa fa fd fa
0x0c047fffd530: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa
0x0c047fffd540: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa
0x0c047fffd550: fa fa fd fd fa fa fd fd fa fa fd fd fa fa fd fa
0x0c047fffd560: fa fa fd fa fa fa fd fa fa fa fd fa fa fa 00 00
=>0x0c047fffd570: fa fa 07 fa fa fa 00 fa fa[fa]01 fa fa fa fa fa
0x0c047fffd580: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c047fffd590: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c047fffd5a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c047fffd5b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c047fffd5c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
==3997==ABORTING
...
The direct cause is that child_path gets called with parent == "", so this
test:
...
if (IS_DIR_SEPARATOR (parent[parent_len - 1]))
...
accesses parent[-1].
[ There is an open discussion (1) about whether an empty sysroot should indeed
be represented internally as "". But this patch focuses on fixing the
heap-buffer-overflow without any redesign. ]
Fix this by guarding the test with 'parent_len > 0'.
Note that the fix makes child_path behave the same for:
- parent == "/" && child == "/foo" (returns "foo")
- parent == "" and child == "/foo" (returns "foo").
Build and reg-tested on x86_64-linux.
(1) https://sourceware.org/ml/gdb-patches/2019-05/msg00193.html
gdb/ChangeLog:
2019-06-17 Tom de Vries <tdevries@suse.de>
PR gdb/24617
* common/pathstuff.c (child_path): Make sure parent_len > 0 before
accessing parent[parent_len - 1].
The loc_hash_table should only contain local ifunc symbols. The current
code already aborts if there is anything else and for defined ifunc
symbols elfNN_aarch64_allocate_dynrelocs is a no-op.
bfd/ChangeLog:
* elfnn-aarch64.c (elfNN_aarch64_allocate_local_dynrelocs): Remove.
(elfNN_aarch64_size_dynamic_sections): Remove loc_hash_table traversal
with elfNN_aarch64_allocate_local_dynrelocs.
Atm gdb-add-index.exp fails with target board cc-with-dwz-m.
Fix this by updating gdb/contrib/gdb-add-index.sh to handle a dwz-m-ed
executable.
Tested on x86_64-linux.
gdb/ChangeLog:
2019-06-16 Tom de Vries <tdevries@suse.de>
PR gdb/24445
* contrib/gdb-add-index.sh: Update to handle dwz-m-ed executable.
I found a few spots that directly cast a tui_win_info to a
tui_gen_win_info. However, I think it's a bit better here to take the
address of the "generic" member. As far as I know, nothing relies on
being able to downcast here, so this gives us the freedom to rearrange
the structure.
gdb/ChangeLog
2019-06-16 Tom Tromey <tom@tromey.com>
* tui/tui-wingeneral.c (tui_unhighlight_win, tui_highlight_win)
(make_all_visible): Use address of member.
I found a few more spots that unnecessarily cast NULL to a pointer
type. My earlier search included a "*" in the cast, but these use a
typedef to a pointer type instead. This patch removes these casts.
gdb/ChangeLog
2019-06-16 Tom Tromey <tom@tromey.com>
* tui/tui-data.c (tui_clear_win_detail, init_win_info)
(tui_free_window, free_content, free_content_elements): Remove
unnecessary cast.
* tui/tui-windata.c (tui_display_all_data): Remove unnecessary
cast.
* tui/tui-regs.c (tui_show_register_group)
(tui_display_registers_from, tui_display_reg_element_at_line):
Remove unnecessary cast.
In the following commit:
commit 7feb7d068a
Date: Mon May 11 12:08:03 2009 +0000
The last useful uses of normal_mask in linux-nat.c were removed, since
then this variable has sat around being initialised, but never used.
There should be no user visible changes after this commit.
gdb/ChangeLog:
* linux-nat.c (normal_mask): Delete.
(_initialize_linux_nat): Don't initialise normal_mask.
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.
I noticed a couple of spots using concat that could use xstrdup
instead. This patch fixes these.
gdb/ChangeLog
2019-06-16 Tom Tromey <tom@tromey.com>
* coffread.c (process_coff_symbol): Use xstrdup.
* value.c (create_internalvar): Use xstrdup.
In bug gdb/24686 a testsuite failure was reported, this failure was
actually just another instance of bug gdb/24541, however, due to the
non-deterministic nature of bug gdb/24541 the testsuite pattern that
was intended to catch this bug failed.
This commit adds a second pattern to help detect gdb/24541, which
should change the FAIL reported in gdb/24686 into a KFAIL.
gdb/testsuite/ChangeLog:
PR gdb/24686
* gdb.mi/mi-catch-cpp-exceptions.exp: Add an extra pattern to
improve detection of bug gdb/24541.
I found a few spots in the TUI that were NULL-checking the result of
XNEW. This cannot return NULL, so this patch removes the checks.
gdb/ChangeLog
2019-06-16 Tom Tromey <tom@tromey.com>
* tui/tui-data.c (tui_alloc_generic_win_info)
(tui_alloc_win_info, tui_add_content_elements): Remove NULL
checks.
The gdb.base/index-cache.exp test fails with the readnow board:
$ make check TESTS="gdb.base/index-cache.exp" RUNTESTFLAGS="--target_board=readnow"
FAIL: gdb.base/index-cache.exp: test_cache_enabled_miss: at least one file was created
FAIL: gdb.base/index-cache.exp: test_cache_enabled_miss: expected file is there
FAIL: gdb.base/index-cache.exp: test_cache_enabled_miss: check index-cache stats
FAIL: gdb.base/index-cache.exp: test_cache_enabled_hit: check index-cache stats
The problem is similar to what was fixed in
5a56d6a65f ("[gdb/testsuite] Fix index-cache.exp with cc-with-{gdb-index,debug-names}")
In that commit, gdb.base/index-cache.exp was modified to account for the
fact that the index cache is not used when the binary already has an
embedded index.
The same situation happens when GDB is started with the -readnow flag:
it bypasses indices and partial symbols. So this patch updates the test
to also expect the index cache not to be used if -readnow is present in
$GDBFLAGS,
gdb/testsuite/ChangeLog:
PR gdb/24669
* gdb.base/index-cache.exp (uses_readnow,
expecting_index_cache_use): Define global variable.
(test_cache_enabled_miss, test_cache_enabled_hit): Use
expecting_index_cache_use.
Show the type of not-allocated and/or not-associated types. For array
types and pointer to array types we are going to print the number of
ranks.
Consider this Fortran program:
program test
integer, allocatable :: vla (:)
logical l
allocate (vla(5:12))
l = allocated (vla)
end program test
And this GDB session with current HEAD:
(gdb) start
...
2 integer, allocatable :: vla (:)
(gdb) n
4 allocate (vla(5:12))
(gdb) ptype vla
type = <not allocated>
(gdb) p vla
$1 = <not allocated>
(gdb)
And the same session with this patch applied:
(gdb) start
...
2 integer, allocatable :: vla (:)
(gdb) n
4 allocate (vla(5:12))
(gdb) ptype vla
type = integer(kind=4), allocatable (:)
(gdb) p vla
$1 = <not allocated>
(gdb)
The type of 'vla' is now printed correctly, while the value itself
still shows as '<not allocated>'. How GDB prints the type of
associated pointers has changed in a similar way.
gdb/ChangeLog:
* f-typeprint.c (f_print_type): Don't return early for not
associated or not allocated types.
(f_type_print_varspec_suffix): Add print_rank parameter and print
ranks of array types in case they dangling.
(f_type_print_base): Add print_rank parameter.
gdb/testsuite/ChangeLog:
* gdb.fortran/pointers.f90: New file.
* gdb.fortran/print_type.exp: New file.
* gdb.fortran/vla-ptype.exp: Adapt expected results.
* gdb.fortran/vla-type.exp: Likewise.
* gdb.fortran/vla-value.exp: Likewise.
* gdb.mi/mi-vla-fortran.exp: Likewise.
Adds some MI commands to catch C++ exceptions. The new commands are
-catch-throw, -catch-rethrow, and -catch-catch, these all correspond
to the CLI commands 'catch throw', 'catch rethrow', and 'catch catch'.
Each MI command takes two optional arguments, '-t' has the effect of
calling 'tcatch' instead of 'catch', for example:
(gdb)
-catch-throw -t
Is the same as:
(gdb) tcatch throw
There is also a '-r REGEXP' argument that can supply a regexp to match
against the exception type, so:
(gdb)
-catch-catch -r PATTERN
Is the same as:
(gdb) catch catch PATTERN
The change in print_mention_exception_catchpoint might seem a little
strange; changing the output from using ui_out::field_int and
ui_out::text to using ui_out::message.
The print_mention_exception_catchpoint is used as the 'print_mention'
method for the exception catchpoint breakpoint object. Most of the
other 'print_mention' methods (see breakpoint.c) use either
printf_filtered, of ui_out::message. Using field_int was causing an
unexpected field to be added to the MI output. Here's the output
without the change in print_mention_exception_catchpoint:
(gdb)
-catch-throw
^done,bkptno="1",bkpt={number="1",type="breakpoint",disp="keep",
enabled="y",addr="0x00000000004006c0",
what="exception throw",catch-type="throw",
thread-groups=["i1"],times="0"}
Notice the breakpoint number appears in both the 'bkptno' field, and
the 'number' field within the 'bkpt' tuple. Here's the output with
the change in print_mention_exception_catchpoint:
(gdb)
-catch-throw
^done,bkpt={number="1",type="breakpoint",disp="keep",
enabled="y",addr="0x00000000004006c0",
what="exception throw",catch-type="throw",
thread-groups=["i1"],times="0"}
gdb/ChangeLog:
* NEWS: Mention new MI commands.
* break-catch-throw.c (enum exception_event_kind): Move to
breakpoint.h.
(print_mention_exception_catchpoint): Output text as a single
message.
(catch_exception_command_1): Rename to...
(catch_exception_event): ...this, make non-static, update header
command, and change some parameter types.
(catch_catch_command): Update for changes to
catch_exception_command_1.
(catch_throw_command): Likewise.
(catch_rethrow_command): Likewise.
* breakpoint.c (enum exception_event_kind): Delete.
* breakpoint.h (enum exception_event_kind): Moved here from
break-catch-throw.c.
(catch_exception_event): Declare.
* mi/mi-cmd-catch.c (mi_cmd_catch_exception_event): New function.
(mi_cmd_catch_throw): New function.
(mi_cmd_catch_rethrow): New function.
(mi_cmd_catch_catch): New function.
* mi/mi-cmds.c (mi_cmds): Add 'catch-throw', 'catch-rethrow', and
'catch-catch' entries.
* mi/mi-cmds.h (mi_cmd_catch_throw): Declare.
(mi_cmd_catch_rethrow): Declare.
(mi_cmd_catch_catch): Declare.
gdb/doc/ChangeLog:
* gdb.texinfo (GDB/MI Catchpoint Commands): Add menu entry to new
node.
(C++ Exception GDB/MI Catchpoint Commands): New node to describe
new MI commands.
gdb/testsuite/ChangeLog:
* gdb.mi/mi-catch-cpp-exceptions.cc: New file.
* gdb.mi/mi-catch-cpp-exceptions.exp: New file.
* lib/mi-support.exp (mi_expect_stop): Handle 'exception-caught'
as a stop reason.
The annotations should be additional information printed by GDB to be
consumed by users (GUIs), but GDB shouldn't reduce what it prints
based on whether annotations are on or not. However, this is what
happens for annotate_source_line.
This commit makes annotate_source_line a void function that simply
outputs the annotation information, GDB will then print the contents
of the source line to the terminal in the normal way.
Some tests needed to be updated after this commit.
gdb/ChangeLog:
* annotate.c (annotate_source_line): Change return type to void,
update implementation to match.
* annotate.h (annotate_source_line): Change return type to void,
update header comment.
* stack.c (print_frame_info): Don't change what frame information
is printed based on whether annotations are on or not.
gdb/testsuite/ChangeLog:
* gdb.base/annota1.exp: Update expected results.
* gdb.cp/annota2.exp: Likewise.
* gdb.cp/annota3.exp: Likewise.
While reviewing some of the annotation code I noticed that
identify_source_line (in source.c) sets current_source_line,
current_source_symtab, and also calls clear_lines_listed_range. This
seems a little strange, identify_source_line is really a wrapper
around annotate_source, and is only called when annotation_level is
greater than 0 (so annotations are turned on).
It seems weird (to me) that when annotations are on we update GDB's
idea of the "current" line/symtab, but when they are off we don't,
given that annotations are really about communicating GDB's state to a
user (GUI) and surely shouldn't be changing GDB's behaviour.
This commit removes from identify_source_line all of the setting of
current line/symtab and the call to clear_lines_listed_range, after
doing this GDB still passes all tests, so I don't believe these lines
were actually required.
With this code removed identify_source_line is only a wrapper around
annotate_source, so I moved identify_source_line to annotate.c and
renamed it to annotate_source_line.
gdb/ChangeLog:
* annotate.c: Add 'source.h' and 'objfiles.h' includes.
(annotate_source): Make static.
(annotate_source_line): Moved from source.c and renamed from
identify_source_line. Update the return type.
* annotate.h (annotate_source): Delete declaration.
(annotate_source_line): Declaration moved from source.h, and
renamed from identify_source_line. Return type updated.
* source.c (identify_source_line): Moved to annotate.c and renamed
to annotate_source_line.
(info_line_command): Remove check of annotation_level.
* source.h (identify_source_line): Move declaration to annotate.h
and rename to annotate_source_line.
* stack.c: Add 'annotate.h' include.
(print_frame_info): Remove check of annotation_level before
calling annotate_source_line.
Every place that a symtab's line_charpos data is loaded always follows
the same pattern, so create a new function to contain this logic and
make use of it throughout GDB.
There should be no user visible changes after this commit.
gdb/ChangeLog:
* source-cache.c (source_cache::get_plain_source_lines): Use
open_source_file_with_line_charpos instead of just
open_source_file, remove call to find_source_lines.
(source_cache::get_source_lines): Likewise.
* source.c (find_source_lines): Make static.
(get_filename_and_charpos): Renamed into...
(open_source_file_with_line_charpos): ..this along with changes to
return a scoped_fd, and some other minor clean ups.
(identify_source_line): Use open_source_file_with_line_charpos.
(search_command_helper): Use open_source_file_with_line_charpos
instead of just open_source_file, remove call to
find_source_lines.
* source.h (open_source_file_with_line_charpos): Declare new
function.
(find_source_lines): Delete declaration.
The parameter 'fullname' is always passed as NULL to the function
get_filename_and_charpos in source.c, so lets remove the parameter.
There should be no user visible changes after this commit.
gdb/ChangeLog:
* source.c (get_filename_and_charpos): Remove fullname
parameter.
(identify_source_line): Update call to get_filename_and_charpos.
Having paths in test names makes comparing sum files difficult, rename
a test to avoid paths in test names.
gdb/testsuite/ChangeLog:
* gdb.base/style-logging.exp: Remove path from test name.
PR gdb/24502 requests that the "set logging" log file not contain
style escape sequences emitted by gdb.
This seemed like a reasonable request to me, so this patch implements
filtering for the log file.
This also updates a comment in ui-style.h that I noticed while writing
the patch.
Tested on x86-64 Fedora 29.
gdb/ChangeLog
2019-06-14 Tom Tromey <tromey@adacore.com>
PR gdb/24502:
* ui-style.h (skip_ansi_escape): Update comment.
* ui-file.h (class no_terminal_escape_file): New class.
* ui-file.c (no_terminal_escape_file::write)
(no_terminal_escape_file::puts): New methods.
* cli/cli-logging.c (handle_redirections): Use
no_terminal_escape_file.
gdb/testsuite/ChangeLog
2019-06-14 Tom Tromey <tromey@adacore.com>
PR gdb/24502:
* gdb.base/style-logging.exp: New file.
I noticed that a NEWS item about Python scripting changes appeared
between an item about a convenience function and an item about a
convenience variable. I think it's better for the latter to be next
to each other.
gdb/ChangeLog
2019-06-14 Tom Tromey <tromey@adacore.com>
* NEWS: Move convenience variable news above Python news.
This patch moves the gdb/gnulib subdirectory to the top level.
It adjusts the top-level build system to build gnulib when necessary,
and changes gdb to use this. However, gdbserver still builds its own
copy of gnulib, just from the new source location.
A small hack was needed to ensure that gnulib is only built when gdb
is enabled. The Makefile only provides an ordering -- the directory
must be mentioned in configdirs to actually be compiled at all.
Most of the patch is just a "git mv" of gnulib, though a few minor
path adjustments were needed in some files there.
Tested by the buildbot.
ChangeLog
2019-06-14 Tom Tromey <tom@tromey.com>
* MAINTAINERS: Add gnulib.
* gnulib: New directory, move from gdb/gnulib.
* configure.ac (host_libs): Add gnulib.
* configure: Rebuild.
* Makefile.def (host_modules, dependencies): Add gnulib.
* Makefile.in: Rebuild.
gdb/ChangeLog
2019-06-14 Tom Tromey <tom@tromey.com>
* gnulib: Move directory to top-level.
* configure.ac: Don't configure gnulib.
* configure: Rebuild.
* common/common-defs.h: Use new path to gnulib.
* Makefile.in (GNULIB_BUILDDIR): Now ../gnulib.
(GNULIB_H): Remove.
(INCGNU): Look in new gnulib location.
(HFILES_NO_SRCDIR): Remove gnulib files.
(SUBDIR, REQUIRED_SUBDIRS): Remove gnulib.
(generated_files): Remove GNULIB_H.
($(LIBGNU), all-lib): Remove targets.
(distclean): Don't mention GNULIB_BUILDDIR.
($(GNULIB_BUILDDIR)/Makefile): Remove target.
gdb/gdbserver/ChangeLog
2019-06-14 Tom Tromey <tom@tromey.com>
* configure.ac: Use new path to gnulib.
* configure: Rebuild.
* Makefile.in (INCGNU, $(GNULIB_BUILDDIR)/Makefile): Use new path
to gnulib.
gnulib/ChangeLog
2019-06-14 Tom Tromey <tom@tromey.com>
* update-gnulib.sh: Adjust paths.
* Makefile.in: Adjust paths.
* configure.ac: Adjust paths. Use ACX_LARGEFILE.
* configure: Rebuild.
A user suggested that add-symbol-file ought to warn if the file does
not in fact provide any symbols. This seemed like a decent idea, so
this patch implements this idea.
Tested on x86-64 Fedora 29.
gdb/ChangeLog
2019-06-14 Tom Tromey <tromey@adacore.com>
* symfile.c (add_symbol_file_command): Remove obsolete comment.
Warn if symbol file does not provide any symbols.
gdb/testsuite/ChangeLog
2019-06-14 Tom Tromey <tromey@adacore.com>
* gdb.base/symfile-warn.exp: New file.
* gdb.base/symfile-warn.c: New file.
