platform/upstream/binutils.git
5 years agoPR24520, gprof fails to read compressed debug data
Alan Modra [Tue, 7 May 2019 23:55:25 +0000 (09:25 +0930)]
PR24520, gprof fails to read compressed debug data

PR 24520
* corefile.c (core_init): Set BFD_DECOMPRESS.

5 years agoAutomatic date update in version.in
GDB Administrator [Wed, 8 May 2019 00:00:21 +0000 (00:00 +0000)]
Automatic date update in version.in

5 years agoxfail locview tests on mep that use complex relocs for view numbers
Alexandre Oliva [Tue, 7 May 2019 19:34:19 +0000 (16:34 -0300)]
xfail locview tests on mep that use complex relocs for view numbers

Expressions that compute view numbers that aren't simplified early
enough to a constant end up being selected for representation as
complex relocations, enabled on mep-* targets.

It would be possible to recognize such expressions, that can resolve
to constants, but this problem was hit before, in preexisting tests,
so xfail the new hits similarly.

The new hits were caused by yesterday's patch to dwarf2dbg.c: views in
the beginning of subsections are now computed later, based on the
final views or previous subsections in the same section.

for  gas/ChangeLog

* testsuite/gas/elf/dwarf2-18.d: Xfail mep-*.
* testsuite/gas/elf/dwarf2-19.d: Likewise.

5 years ago[gdb/testsuite] Fix ls_host return in index-cache.exp
Tom de Vries [Tue, 7 May 2019 09:52:17 +0000 (11:52 +0200)]
[gdb/testsuite] Fix ls_host return in index-cache.exp

When adding a debug print here in index-cache.exp:
...
 proc_with_prefix test_cache_disabled { cache_dir } {
     lassign [ls_host $cache_dir] ret files_before
+    puts "before: '$files_before'"
+    exit
...
we have:
...
files_before: ''
...

When further adding:
...
 proc_with_prefix test_cache_disabled { cache_dir } {
+    exec touch $cache_dir/foo.1 $cache_dir/foo.2 $cache_dir/foo.3
...
we have:
...
files_before: 'foo.1'
...
while we're expecting file_before to contain foo.[123].

Fix this by making the return statement in ls_host return a list rather than a
string (in accordance with the ls_host documentation), after which we have:
...
files_before: 'foo.1 foo.2 foo.3'
...

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

2019-05-07  Tom de Vries  <tdevries@suse.de>

* gdb.base/index-cache.exp (ls_host): Fix return statement.

5 years ago[gdb/testsuite] Fix .debug_aranges in watch-loc.c
Tom de Vries [Tue, 7 May 2019 08:58:57 +0000 (10:58 +0200)]
[gdb/testsuite] Fix .debug_aranges in watch-loc.c

When running gdb.dlang/watch-loc.exp with target board cc-with-debug-names, we
run into:
...
FAIL: gdb.dlang/watch-loc.exp: disassemble _Dmain (GDB internal error)
...
in more detail:
...
(gdb) disassemble _Dmain
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 watch-loc.c contains a
debug_info_offset which is set to 0:
...
asm (
  "      .pushsection    .debug_aranges,\"\",%progbits\n"
  "      .4byte  .Laranges_end - .Laranges_start\n"
  ".Laranges_start:\n"
  "      .2byte  0x2\n"
  "      .4byte  0\n"
...
while the compilation unit at offset 0 in the .debug_section in the executable
is in fact not the compilation unit generated from watch-loc-dw.S.

[ Note: this is a non-trivial test-case.  The file watch-loc-dw.S contains a
.debug_info section, but not an .debug_aranges section or any actual code.
The file watch-loc.c contains code and a .debug_aranges section, but no other
debug section.  So, the intent for the .debug_aranges section in watch-loc.c
is to refer to a compilation unit in the .debug_info section in
watch-loc-dw.S. ]

This happens when linked in object files contain dwarf info and are placed in
the .debug_info section before the compilation units generated from
watch-loc.c and watch-loc-dw.S.

Fix this by defining the debug_info_offset field using a label .Lcu1_begin
that defines the start of an empty .debug_section compilation unit:
...
 asm (
+  "      .pushsection    .debug_info,\"\",%progbits\n"
+  ".Lcu1_begin:"
+  "      .popsection\n"
   "      .pushsection    .debug_aranges,\"\",%progbits\n"
   "      .4byte  .Laranges_end - .Laranges_start \n"
   ".Laranges_start:\n"
   "      .2byte  0x2\n"
-  "      .4byte  0\n"
+  "      .4byte  .Lcu1_begin\n"
...
which during linking merges with the start of the .debug_info section of
watch-loc-dw.S.

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.dlang/watch-loc.c: Fix debug_info_offset in .debug_aranges
section.

5 years ago[gdb/testsuite] Fix .debug_aranges in dw2-case-insensitive-debug.S
Tom de Vries [Tue, 7 May 2019 08:58:57 +0000 (10:58 +0200)]
[gdb/testsuite] Fix .debug_aranges in dw2-case-insensitive-debug.S

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.

5 years ago[gdb/testsuite] Fix handling of DW_FORM_ref_addr in dwarf assembler
Tom de Vries [Tue, 7 May 2019 08:38:36 +0000 (10:38 +0200)]
[gdb/testsuite] Fix handling of DW_FORM_ref_addr in dwarf assembler

When running gdb.dwarf2/multidictionary.exp with target board cc-with-dwz and
current dwz, we run into a dwz abort:
...
gdb compile failed, gdb/contrib/cc-with-tweaks.sh: line 188: 11484 Aborted \
  (core dumped) $DWZ "$output_file" > /dev/null 2>&1
UNTESTED: gdb.dwarf2/multidictionary.exp: multidictionary.exp
...
The dwz abort (PR dwz/24169) is caused by an invalid DW_FORM_ref_addr in the
multidictionary binary.

The multidictionary binary is build from multidictionary.S which is generated
using the dwarf assembler, and multidictionary.S contains dwarf for 3
compilation units.

In multidictionary0.o (generated from multidictionary.S), we find a concrete
formal parameter DIE:
...
 <2><dc>: Abbrev Number: 4 (DW_TAG_formal_parameter)
    <dd>   DW_AT_abstract_origin: <0xa6>
...
referring to an abstract formal parameter DIE at 0xa6:
...
 <2><a6>: Abbrev Number: 8 (DW_TAG_formal_parameter)
    <a7>   DW_AT_name        : msg
    <ab>   DW_AT_type        : <0x92>
...
but in the multidictionary binary the concrete formal parameter DIE is still
referring to 0xa6:
...
 <2><1a3>: Abbrev Number: 4 (DW_TAG_formal_parameter)
    <1a4>   DW_AT_abstract_origin: <0xa6>
...
while the abstract formal parameter DIE has moved to 0x16d:
...
 <2><16d>: Abbrev Number: 8 (DW_TAG_formal_parameter)
    <16e>   DW_AT_name        : msg
    <172>   DW_AT_type        : <0x159>
...

The concrete formal parameter DIE is specified in multidictionary.S like this:
...
.Llabel21:
        .uleb128        4
        .4byte        .Llabel17 - .Lcu1_begin
...

The problem is that the .Lcu1_begin label is assumed to mark the start of the
.debug_info section in the executable, but in fact it marks the start of the
first compilation unit from multidictionary.S in the executable.  Usually
these two entities are the same, but they are not when linked in object files
contain dwarf info and are placed in the .debug_info section before the
compilation units generated from multidictionary.S.

Fix this in the dwarf assembler by generating instead the label itself:
...
.Llabel21:
        .uleb128        4
        .4byte        .Llabel17
...
resulting in a relocation in the object file:
...
  Offset          Info           Type           Sym. Value    Sym. Name + Addend
0000000000dd  00040000000a R_X86_64_32       0000000000000000 .debug_info + a6
...
and resulting in the correct offset in the executable:
...
 <2><1a3>: Abbrev Number: 4 (DW_TAG_formal_parameter)
    <1a4>   DW_AT_abstract_origin: <0x16d>
...

Tested on x86_64-linux with native and cc-with-dwz.

gdb/testsuite/ChangeLog:

2019-05-07  Tom de Vries  <tdevries@suse.de>

PR testsuite/24159
* lib/dwarf.exp: Fix handling of DW_FORM_ref_addr.

5 years agoTidy use_complex_relocs_for
Alan Modra [Mon, 6 May 2019 11:53:45 +0000 (21:23 +0930)]
Tidy use_complex_relocs_for

Since I was looking at this I decided to fix the formatting, and
used an old C switch statements trick to factor out common code.

* symbols.c (use_complex_relocs_for): Formatting.  Factor out
X_add_symbol tests.

5 years agoFix scoped_mmap includes
Tom Tromey [Tue, 7 May 2019 01:54:53 +0000 (19:54 -0600)]
Fix scoped_mmap includes

I noticed that scoped_mmap.h included config.h, and that scoped_mmap.c
included defs.h.  This patch fixes both of these problems.

Tested by the buildbot.

gdb/ChangeLog
2019-05-06  Tom Tromey  <tom@tromey.com>

* common/scoped_mmap.c: Include common-defs.h.
* common/scoped_mmap.h: Don't include config.h.

5 years agoAutomatic date update in version.in
GDB Administrator [Tue, 7 May 2019 00:00:24 +0000 (00:00 +0000)]
Automatic date update in version.in

5 years agoFix regression caused by recently added syscall restart code
Kevin Buettner [Mon, 6 May 2019 17:28:44 +0000 (10:28 -0700)]
Fix regression caused by recently added syscall restart code

This line of code...

       *(int64_t *) ptr = *(int32_t *) ptr;

...in linux-x86-low.c is not needed (and does not work correctly)
within a 32-bit executable.  I added an __x86_64__ ifdef (which is
used extensively elsewhere in the file for like purposes) to prevent
this code from being included in 32-bit builds.

It fixes the following regressions when running on native
i686-pc-linux-gnu:

FAIL: gdb.server/abspath.exp: continue to main
FAIL: gdb.server/connect-without-multi-process.exp: multiprocess=auto: continue to main
FAIL: gdb.server/connect-without-multi-process.exp: multiprocess=off: continue to main
FAIL: gdb.server/ext-restart.exp: restart: run to main
FAIL: gdb.server/ext-restart.exp: run to main
FAIL: gdb.server/ext-run.exp: continue to main
FAIL: gdb.server/ext-wrapper.exp: print d
FAIL: gdb.server/ext-wrapper.exp: restart: print d
FAIL: gdb.server/ext-wrapper.exp: restart: run to marker
FAIL: gdb.server/ext-wrapper.exp: run to marker
FAIL: gdb.server/no-thread-db.exp: continue to breakpoint: after tls assignment
FAIL: gdb.server/reconnect-ctrl-c.exp: first: stop with control-c
FAIL: gdb.server/reconnect-ctrl-c.exp: second: stop with control-c
FAIL: gdb.server/run-without-local-binary.exp: run test program until the end
FAIL: gdb.server/server-kill.exp: continue to breakpoint: after server_pid assignment
FAIL: gdb.server/server-kill.exp: tstatus
FAIL: gdb.server/server-run.exp: continue to main

gdb/gdbserver/ChangeLog:

* linux-x86-low.c (x86_fill_gregset): Don't compile 64-bit
sign extension code on 32-bit builds.

5 years agoAdd load-link, store-conditional paired EVA instructions
Faraz Shahbazker [Mon, 29 Apr 2019 01:21:00 +0000 (18:21 -0700)]
Add load-link, store-conditional paired EVA instructions

Add paired load-link and store-conditional instructions to the
EVA ASE for MIPS32R6[1].  These instructions are optional within
the EVA ASE.  Their presence is indicated by the XNP bit in the
Config5 register.

[1] "MIPS Architecture for Programmers Volume II-A: The MIPS32
     Instruction Set Manual", Imagination Technologies Ltd., Document
     Number: MD00086, Revision 6.06, December 15, 2016, Section 3.2
     "Alphabetical List of Instructions", pp. 230-231, pp. 357-360.

gas/
* config/tc-mips.c (mips_set_ase): Handle ASE_EVA_R6.
(macro) <M_LLWPE_AB, M_SCWPE_AB>: New cases.
(mips_after_parse_args): Translate EVA to EVA_R6.
* testsuite/gas/mips/ase-errors-1.s: Add new instructions.
* testsuite/gas/mips/eva.s: Likewise.
* testsuite/gas/mips/ase-errors-1.l: Check errors for
 new instructions.
* testsuite/gas/mips/mipsr6@eva.d: Check new test cases.

include/
* opcode/mips.h (ASE_EVA_R6): New macro.
(M_LLWPE_AB, M_SCWPE_AB): New enum values.

opcodes/
* mips-dis.c (mips_calculate_combination_ases): Add ISA
argument and set ASE_EVA_R6 appropriately.
(set_default_mips_dis_options): Pass ISA to above.
(parse_mips_dis_option): Likewise.
* mips-opc.c (EVAR6): New macro.
(mips_builtin_opcodes): Add llwpe, scwpe.

Derived from patch authored by Andrew Bennett <andrew.bennett@imgtec.com>

5 years agosym->sy_value is not valid for struct local_symbol
Alan Modra [Mon, 6 May 2019 05:08:24 +0000 (14:38 +0930)]
sym->sy_value is not valid for struct local_symbol

Fixes this mep-elf error:
gas/elf/dwarf2-19.s: Error: Unknown expression operator (enum 0)
gas/elf/dwarf2-19.s: Error: cannot convert expression symbol .L2 to complex relocation

* symbols.c (symbol_relc_make_sym): Do not access sym->sy_value
directly.

5 years ago[gdb/testsuite] Fix index-cache.exp with cc-with-{gdb-index,debug-names}
Tom de Vries [Mon, 6 May 2019 06:42:24 +0000 (08:42 +0200)]
[gdb/testsuite] Fix index-cache.exp with cc-with-{gdb-index,debug-names}

In gdb.base/index-cache.exp, handle the case that binfile contains either a
.gdb_index or .debug_names index section.

Tested on x86_64-linux with native, cc-with-gdb-index and cc-with-debug-names.

gdb/testsuite/ChangeLog:

2019-05-06  Tom de Vries  <tdevries@suse.de>

* lib/gdb.exp (exec_has_index_section): New proc.
* gdb.base/index-cache.exp: Handle case that binfile contains an index
section.

5 years agoPicoJava weak undefined symbols
Alan Modra [Sun, 5 May 2019 23:43:53 +0000 (09:13 +0930)]
PicoJava weak undefined symbols

This fixes the recently added ld-elf/pr24511 test failure on pj-elf.
Incidentally, pj-elf has failed its gas "pj" test since 2005-12-22
(git commit 54758c3e39).  I think that makes the target ripe for
obsolescence.

bfd/
* elf32-pj.c (pj_elf_reloc): Don't report undefined weak as an error.
ld/
* testsuite/ld-undefined/weak-undef.exp: Don't xfail pj.

5 years agoPowerPC reloc symbols that shouldn't be adjusted
Alan Modra [Sun, 5 May 2019 23:13:32 +0000 (08:43 +0930)]
PowerPC reloc symbols that shouldn't be adjusted

GOT and PLT relocs shouldn't have their symbols replaced with a
section symbol plus added.  Nor should the HIGHA TLS relocations,
which failed to be caught by the range test in ppc_fix_adjustable.

bfd/
* reloc.c (BFD_RELOC_PPC64_TPREL16_HIGH, BFD_RELOC_PPC64_TPREL16_HIGHA),
(BFD_RELOC_PPC64_DTPREL16_HIGH, BFD_RELOC_PPC64_DTPREL16_HIGHA):
Sort before BFD_RELOC_PPC64_DTPREL16_HIGHESTA entry.
gas/
* config/tc-ppc.c (ppc_fix_adjustable): Exclude all GOT and PLT
relocs, and VLE sdarel relocs.
* testsuite/gas/ppc/power4.d: Adjust.

5 years ago[LVu] base subseg head view on prev subseg's tail
Alexandre Oliva [Mon, 6 May 2019 02:07:20 +0000 (23:07 -0300)]
[LVu] base subseg head view on prev subseg's tail

Location views at borders between subsegments/subsections in the same
segment/section are computed as if each new subsegment/subsection
started with a forced view reset to zero, but the line number program
does not introduce resets that are not explicitly requested, so if a
subsegment ends at the same address another starts, the line number
program will have a continuity of views at the border address, whereas
the initial view number label in the latter subsegment will be
miscomputed as zero.

This patch delays the assignment of view expressions at subsegment
heads to the time of chaining the frags of subsegments into a single
segment, so that they are set based on the view at the end of the
previous subsegment in the same segment.

The line number program created for the test program had an
unnecessary DW_LNS_advance_pc at the end.  This patch also arranges
for us not to emit it.

for  gas/ChangeLog

* dwarf2dbg.c (set_or_check_view): Skip heads when assigning
views of prior locs.
(dwarf2_gen_line_info_1): Skip heads.
(size_inc_line_addr, emit_inc_line_addr): Drop
DW_LNS_advance_pc for zero addr delta.
(dwarf2_finish): Assign views for heads of segments.
* testsuite/gas/elf/dwarf2-19.d: New.
* testsuite/gas/elf/dwarf2-19.s: New.
* testsuite/gas/elf/elf.exp: Test it.

5 years agoAutomatic date update in version.in
GDB Administrator [Mon, 6 May 2019 00:00:14 +0000 (00:00 +0000)]
Automatic date update in version.in

5 years agoAutomatic date update in version.in
GDB Administrator [Sun, 5 May 2019 00:00:56 +0000 (00:00 +0000)]
Automatic date update in version.in

5 years agoRemove a VEC from aarch64-tdep.c
Tom Tromey [Tue, 24 Jul 2018 01:51:58 +0000 (19:51 -0600)]
Remove a VEC from aarch64-tdep.c

This removes a VEC from aarch64-tdep.c, replacing it with a
std::vector.

gdb/ChangeLog
2019-05-04  Tom Tromey  <tom@tromey.com>

* aarch64-tdep.c (stack_item_t): Remove typedef and DEF_VEC.
(struct aarch64_call_info): Add initializers.
<si>: Now a std::vector.
(pass_on_stack, aarch64_push_dummy_call): Update.

5 years agoRemove a VEC from ppc-linux-nat.c
Tom Tromey [Sun, 22 Jul 2018 16:28:23 +0000 (10:28 -0600)]
Remove a VEC from ppc-linux-nat.c

This replaces a VEC in ppc-linux-nat.c with a std::vector.

gdb/ChangeLog
2019-05-04  Simon Marchi  <simon.marchi@efficios.com>
    Tom Tromey  <tom@tromey.com>

* ppc-linux-nat.c (thread_points_p): Remove typedef and DEF_VEC.
(ppc_threads): Now a std::vector.  Now static.
(hwdebug_find_thread_points_by_tid)
(ppc_linux_nat_target::low_new_thread, ppc_linux_thread_exit):
Update.

5 years agoChange arc_tdesc_init to return bool
Tom Tromey [Wed, 24 Apr 2019 22:24:05 +0000 (16:24 -0600)]
Change arc_tdesc_init to return bool

This changes arc_tdesc_init to return bool.

gdb/ChangeLog
2019-05-04  Tom Tromey  <tom@tromey.com>

* arc-tdep.c (arc_tdesc_init): Return bool.

5 years agoUse gdb_assert_not_reached in arm-linux-nat.c
Tom Tromey [Wed, 24 Apr 2019 22:22:57 +0000 (16:22 -0600)]
Use gdb_assert_not_reached in arm-linux-nat.c

This changes arm-linux-nat.c to use gdb_assert_not_reached rather than
an assert of false.

gdb/ChangeLog
2019-05-04  Tom Tromey  <tom@tromey.com>

* arm-linux-nat.c (arm_linux_nat_target::can_use_hw_breakpoint):
Use gdb_assert_not_reached.

5 years agoUse "false" in compile_cplus_convert_enum
Tom Tromey [Wed, 24 Apr 2019 22:19:51 +0000 (16:19 -0600)]
Use "false" in compile_cplus_convert_enum

This changes compile_cplus_convert_enum to use "false".

Note that this variable is never modified, which seems like an error.
I filed PR compile/24473 for this.

gdb/ChangeLog
2019-05-04  Tom Tromey  <tom@tromey.com>

* compile/compile-cplus-types.c (compile_cplus_convert_enum): Use
"false".

5 years agoUse bool, true, and false in arc-tdep.c
Tom Tromey [Wed, 24 Apr 2019 22:18:41 +0000 (16:18 -0600)]
Use bool, true, and false in arc-tdep.c

This changes arc-tdep.c to use bool, true, and false.

gdb/ChangeLog
2019-05-04  Tom Tromey  <tom@tromey.com>

* arc-tdep.c (arc_tdesc_init): Use bool.

5 years agoUse "false" in select_frame_for_mi
Tom Tromey [Mon, 22 Apr 2019 02:24:05 +0000 (20:24 -0600)]
Use "false" in select_frame_for_mi

This changes select_frame_for_mi to use "false" rather than "FALSE".

gdb/ChangeLog
2019-05-04  Tom Tromey  <tom@tromey.com>

* stack.c (select_frame_for_mi): Use "false", not "FALSE".

5 years agoChange valid_command_p to return bool
Tom Tromey [Mon, 22 Apr 2019 02:21:36 +0000 (20:21 -0600)]
Change valid_command_p to return bool

This changes valid_command_p to return bool.

gdb/ChangeLog
2019-05-04  Tom Tromey  <tom@tromey.com>

* cli/cli-cmds.c (valid_command_p): Return bool.

5 years agoChange valid_user_defined_cmd_name_p to return bool
Tom Tromey [Mon, 22 Apr 2019 02:10:51 +0000 (20:10 -0600)]
Change valid_user_defined_cmd_name_p to return bool

This changes valid_user_defined_cmd_name_p to return bool.

gdb/ChangeLog
2019-05-04  Tom Tromey  <tom@tromey.com>

* cli/cli-decode.c (valid_user_defined_cmd_name_p): Return bool.
* command.h (valid_user_defined_cmd_name_p): Channge return type.

5 years agoFix incorrect use of 'is' operator for comparison in python/lib/gdb/command/prompt.py
Raul Tambre [Sat, 4 May 2019 19:48:17 +0000 (15:48 -0400)]
Fix incorrect use of 'is' operator for comparison in python/lib/gdb/command/prompt.py

The 'is' operator is not meant to be used for comparisons. It currently working
is an implementation detail of CPython.  CPython 3.8 has added a SyntaxWarning
for this.

5 years agoDon't derive partial_symbol from general_symbol_info
Tom Tromey [Tue, 23 Apr 2019 22:42:14 +0000 (16:42 -0600)]
Don't derive partial_symbol from general_symbol_info

This patch partly reverts commit 8a6d42345 ("Change representation of
psymbol to flush out accessors"); specifically, it changes
partial_symbol to no longer derive from general_symbol_info.

The basic problem here is that the bcache compares objects bitwise,
and this change made it less likely that the relevant fields in the
psymbol would be fully initialized.  This could be seen by running a
test under valgrind on the Fedora-i686 buildbot.

I considered a simpler patch, namely just zeroing the psymbol's
"value" field in add_psymbol_to_bcache.  However, it wasn't clear to
me that this memset could not then be optimized away by the compiler.

Regression tested by the buildbot.  I think this should go in 8.3 as
well.

gdb/ChangeLog
2019-05-04  Tom Tromey  <tom@tromey.com>

* psymtab.c (psymbol_name_matches, match_partial_symbol)
(lookup_partial_symbol, print_partial_symbols)
(recursively_search_psymtabs, sort_pst_symbols, psymbol_hash)
(psymbol_compare): Update.
(add_psymbol_to_bcache): Clear the entire psymbol.
(maintenance_check_psymtabs): Update.
* psympriv.h (struct partial_symbol): Don't derive from
general_symbol_info.
<obj_section, unrelocated_address, address,
set_unrelocated_address>: Update.
<ginfo>: New member.
* dwarf-index-write.c (write_psymbols, debug_names::insert)
(debug_names::write_psymbols): Update.

5 years ago[gdb/testsuite] Add cc-with-debug-names.exp
Tom de Vries [Sat, 4 May 2019 08:11:53 +0000 (10:11 +0200)]
[gdb/testsuite] Add cc-with-debug-names.exp

Add a target board that makes it easy to run the test suite with a
.debug_names section added to executables.

gdb/ChangeLog:

2019-05-04  Tom de Vries  <tdevries@suse.de>

* contrib/cc-with-tweaks.sh: Support -n arg.

gdb/testsuite/ChangeLog:

2019-05-04  Tom de Vries  <tdevries@suse.de>

* boards/cc-with-debug-names.exp: New file.

5 years agom32c padding with nops
Alan Modra [Sat, 4 May 2019 06:33:47 +0000 (16:03 +0930)]
m32c padding with nops

m32c_md_end attempted to pad out a code section with nops, but this
was just plain wrong in many ways:
- The padding didn't happen at all if the last section emitted wasn't
  a code section.
- The padding went to the wrong place if subsections were used, and
  the last subseg used wasn't the highest numbered subseg.
- Padding wasn't added to all code sections.
- If the last section was empty, it was padded to 4 bytes.
- The padding didn't go to a 4-byte alignment boundary, instead it
  effectively made the last instruction 4 bytes in size.
- The padding didn't take into account that code sections may have
  contents other than machine instructions.

So, rip it out and handle nop padding properly, also fixing .align
.balign/.p2align in the middle of code.

gas/
* config/tc-m32c.c (insn_size): Delete static var.
(md_begin): Don't set it.
(m32c_md_end): Delete.
(md_assemble): Add insn_size auto var.
* config/tc-m32c.h (md_end): Don't define.
(m32c_md_end): Delete.
(NOP_OPCODE, HANDLE_ALIGN, MAX_MEM_FOR_RS_ALIGN_CODE): Define.
* testsuite/gas/all/align.d: Remove m32c from notarget list.
* testsuite/gas/all/incbin.d: Likewise.
* testsuite/gas/elf/dwarf2-11.d: Likewise.
* testsuite/gas/macros/semi.d: Likewise.
* testsuite/gas/all/gas.exp (do_comment): Similarly.
ld/
* testsuite/ld-scripts/fill.d: Don't xfail m32c
* testsuite/ld-scripts/fill16.d: Likewise.

5 years agoPR24511, nm should not mark symbols in .init_array as "t"
Alan Modra [Fri, 3 May 2019 12:06:46 +0000 (21:36 +0930)]
PR24511, nm should not mark symbols in .init_array as "t"

This patch restricts the section names matched in coff_section_type,
a function that translates section names to symbol type, and arranges
to translate section flags to symbol type before looking at names.
The latter change resulted in various test failures due to improper
section flags being used in tests, and by the plugin support, so fix
that too.

The new test fails on many ELF targets that lack .init/fini_array
in their scripts.  I've just xfailed those.  pru-elf oddly defines
__init_array_begin rather than __init_array_start.  I've left that
target as a FAIL, and pj-elf too which reports an error for undefined
weak symbols.

bfd/
PR 24511
* syms.c (coff_section_type): Only allow '.', '$' and numeric
following the standard section names.
(bfd_decode_symclass): Prioritize section flag tests in
decode_section_type before name tests in coff_section_type.
* plugin.c (bfd_plugin_canonicalize_symtab): Init fake_section
and fake_common_section using BFD_FAKE_SECTION.  Use "fake" as
their names and choose standard .text section flags for
fake_section.
ld/
PR 24511
* testsuite/ld-elf/pr14156a.d: Allow for .init/.fini being a
data section on hppa64.
* testsuite/ld-elf/pr14156b.d: Likewise.
* testsuite/ld-scripts/pr18963.t: Map standard sections to set
output section flags.
* testsuite/ld-scripts/sane1.t: Likewise.
* testsuite/ld-elf/init-fini-arrays.s: Reference __init_array_start
and __fini_array_start.  Define __start et al.
* testsuite/ld-elf/pr24511.d: New test.

5 years agoFix leaks by clearing registers and frame caches.
Philippe Waroquiers [Tue, 30 Apr 2019 20:18:48 +0000 (22:18 +0200)]
Fix leaks by clearing registers and frame caches.

Valgrind reports leaks such as the below in the tests:
gdb.threads/corethreads.exp
gdb.threads/gcore-thread.exp
gdb.ada/task_switch_in_core.exp
gdb.trace/tfile.exp
gdb.base/siginfo-thread.exp

==12701== 1,123 (72 direct, 1,051 indirect) bytes in 1 blocks are definitely lost in loss record 2,928 of 3,247
==12701==    at 0x4C2C4CC: operator new(unsigned long) (vg_replace_malloc.c:344)
==12701==    by 0x5CF771: get_thread_arch_aspace_regcache(ptid_t, gdbarch*, address_space*) (regcache.c:330)
==12701==    by 0x5CF92A: get_thread_regcache (regcache.c:366)
==12701==    by 0x5CF92A: get_current_regcache() (regcache.c:372)
==12701==    by 0x4C7964: get_current_frame() (frame.c:1587)
==12701==    by 0x4C7A3C: get_selected_frame(char const*) (frame.c:1651)
==12701==    by 0x669EAD: print_thread_info_1(ui_out*, char const*, int, int, int) (thread.c:1151)
==12701==    by 0x66A9A1: info_threads_command(char const*, int) (thread.c:1217)
==12701==    by 0x40A878: cmd_func(cmd_list_element*, char const*, int) (cli-decode.c:1892)
...

Fix these leaks by clearing registers and frame caches.
This leak and fix is similar to the leak fixed by 799efbe8e01

5 years agoRemove "struct" from foreach statements
Tom Tromey [Fri, 3 May 2019 23:21:36 +0000 (17:21 -0600)]
Remove "struct" from foreach statements

Some versions of gcc have a bug that causes

    for (struct mumble : something)

... to give a compiler error.  We routinely work around this bug in
gdb, but apparently had not done so in a while.  This patch fixes the
remaining known cases of this problem.

gdb/ChangeLog
2019-05-03  Sandra Loosemore  <sandra@codesourcery.com>
    Tom Tromey  <tom@tromey.com>

* dictionary.c (collate_pending_symbols_by_language): Remove
"struct" from foreach.
* symtab.c (lookup_global_symbol_from_objfile)
(lookup_symbol_in_objfile_from_linkage_name): Remove "struct" from
foreach.
* ser-tcp.c (net_open): Remove "struct" from foreach.
* objfiles.c (objfile_relocate, objfile_rebase)
(objfile_has_symbols): Remove "struct" from foreach.
* minsyms.c (lookup_minimal_symbol_by_pc_section): Remove "struct"
from foreach.
* dwarf2read.c (handle_struct_member_die): Remove "struct" from
foreach.
* darwin-nat.c (thread_info_from_private_thread_info): Remove
"struct" from foreach.
* ada-lang.c (create_excep_cond_exprs)
(ada_exception_catchpoint_cond_string): Remove "struct" from
foreach.

5 years agoAutomatic date update in version.in
GDB Administrator [Sat, 4 May 2019 00:00:19 +0000 (00:00 +0000)]
Automatic date update in version.in

5 years agoFix cast of character to enum type in Ada
Tom Tromey [Fri, 3 May 2019 18:18:26 +0000 (12:18 -0600)]
Fix cast of character to enum type in Ada

An internal bug report points out that, when a global character enum
type is used, casting fails, like:

    (gdb) print global_char_enum'('F')
    $1 = 70

The bug here turns out to be that enumerators are qualified, so for
example the mangled name might be "pck__QU48", rather than "QU48".

This patch fixes the problem by only examining the suffix of the
enumerator.  This is ok because the type is already known, and because
the mangling scheme ensures that there won't be clashes.

Tested on x86-64 Fedora 29.

gdb/ChangeLog
2019-05-03  Tom Tromey  <tromey@adacore.com>

* ada-exp.y (convert_char_literal): Check suffix of each
enumerator.

gdb/testsuite/ChangeLog
2019-05-03  Tom Tromey  <tromey@adacore.com>

* gdb.ada/char_enum/pck.ads (Global_Enum_Type): New type.
* gdb.ada/char_enum/foo.adb: Use Global_Enum_Type.
* gdb.ada/char_enum.exp: Add test.

5 years agoAdd noyywrap to ada-lex.l
Dilyan Palauzov [Fri, 3 May 2019 19:42:11 +0000 (13:42 -0600)]
Add noyywrap to ada-lex.l

This patch comes from PR ada/21406.  It adds the noyywrap option to
ada-lex.l.  This was already done (by the same author) for other .l
files in the binutils-gdb tree, so it seems reasonably safe.

Tested on x86-64 Fedora 29.

gdb/ChangeLog
2019-05-03  Dilyan Palauzov  <dilyan.palauzov@aegee.org>

PR ada/21406:
* ada-exp.y (yywrap): Don't define.
* ada-lex.l (%option): Add noyywrap
(yywrap): Remove.

5 years ago[gdb/testsuite] Add cc-with-gdb-index.exp
Tom de Vries [Fri, 3 May 2019 10:57:58 +0000 (12:57 +0200)]
[gdb/testsuite] Add cc-with-gdb-index.exp

Add a target board cc-with-gdb-index.exp, to make it easy to run cc-with-tweaks
with CC_WITH_TWEAKS_FLAGS='-i'.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

2019-05-03  Tom de Vries  <tdevries@suse.de>

* boards/cc-with-gdb-index.exp: New file.

5 years agoOn MS-Windows, define _WIN32_WINNT in a single common place.
Eli Zaretskii [Fri, 3 May 2019 07:55:33 +0000 (10:55 +0300)]
On MS-Windows, define _WIN32_WINNT in a single common place.

This changeset defines _WIN32_WINNT to at least 0x0501, the level
of Windows XP, unless defined to a higher level, in a single
place.  It then removes all the overrides of _WIN32_WINNT in
individual files as no longer needed.  Doing this also solves
compilation of windows-nat.c with mingw.org's MinGW, as that
file uses CONSOLE_FONT_INFO which needs the XP level to become
exposed in the Windows headers, while mingw.org defaults to
Windows 9X.

gdb/ChangeLog:
2019-05-03  Eli Zaretskii  <eliz@gnu.org>

* common/common-defs.h [__MINGW32__ || __CYGWIN__]: Define
_WIN32_WINNT to the XP level, unless already defined to a higher
level.

* unittests/parse-connection-spec-selftests.c:
* ser-tcp.c:
* common/netstuff.c [USE_WIN32API]:  Remove the _WIN32_WINNT
override.

gdb/gdbserver/ChangeLog:
2019-05-03  Eli Zaretskii  <eliz@gnu.org>

* remote-utils.c:
* gdbreplay.c [USE_WIN32API]: Remove the _WIN32_WINNT override.

5 years agoFix lookup of separate debug file on MS-Windows.
Eli Zaretskii [Fri, 3 May 2019 07:29:59 +0000 (10:29 +0300)]
Fix lookup of separate debug file on MS-Windows.

If you put the separate debug file in a global debug directory, GDB on
MS-Windows would fail to find it.  This happens because we obtain the
directory to look up the debug file by concatenating the debug
directory name with the leading directories of the executable, and the
latter includes the drive letter on MS-Windows.  So we get an invalid
file name like

   d:/usr/lib/debug/d:/usr/bin/foo.debug

This commit fixes that by removing the colon of the drive letter,
thus producing

   d:/usr/lib/debug/d/usr/bin/foo.debug

gdb/ChangeLog:
2019-05-03  Eli Zaretskii  <eliz@gnu.org>

* symfile.c (find_separate_debug_file): Remove colon from the
drive spec of DOS/Windows file names of the target, so that the
file name produced from DEBUGDIR and the target's directory will
be valid on DOS/Windows systems.

gdb/doc/ChangeLog:
2019-05-03  Eli Zaretskii  <eliz@gnu.org>

* gdb.texinfo (Separate Debug Files): Document how the
subdirectory of the global debug directory is computed on
MS-Windows/MS-DOS.

5 years agoAutomatic date update in version.in
GDB Administrator [Fri, 3 May 2019 00:00:15 +0000 (00:00 +0000)]
Automatic date update in version.in

5 years agogdb/rust: Handle printing structures containing strings
Andrew Burgess [Wed, 1 May 2019 23:40:01 +0000 (00:40 +0100)]
gdb/rust: Handle printing structures containing strings

When printing a rust structure that contains a string GDB can
currently fail to read the fields that define the string. This is
because GDB mistakenly treats a value that is the parent structure as
though it is the structure that defines the string, and then fails to
find the fields needed to extract a string.

The solution is to create a new value to represent the string field of
the parent value.

gdb/ChangeLog:

* rust-lang.c (val_print_struct): Handle printing structures
containing strings.

gdb/testsuite/ChangeLog:

* gdb.rust/simple.exp: Add new test case.
* gdb.rust/simple.rs (struct StringAtOffset): New struct.
(main): Initialise an instance of the new struct.

5 years agoi386: Issue a warning to IRET without suffix for .code16gcc
H.J. Lu [Thu, 2 May 2019 17:46:55 +0000 (10:46 -0700)]
i386: Issue a warning to IRET without suffix for .code16gcc

The .code16gcc directive to support 16-bit mode with 32-bit address.
For IRET without a suffix, generate 16-bit IRET with a warning to
return from an interrupt handler in 16-bit mode.

PR gas/24485
* config/tc-i386.c (process_suffix): Issue a warning to IRET
without a suffix for .code16gcc.
* testsuite/gas/i386/jump16.s: Add tests for iretX.
* testsuite/gas/i386/jump16.d: Updated.
* testsuite/gas/i386/jump16.e: New file.

5 years agoRemove _initialize_valarith
Tom Tromey [Thu, 2 May 2019 14:15:59 +0000 (08:15 -0600)]
Remove _initialize_valarith

I noticed that _initialize_valarith is empty.  This patch removes it.
Because init.c is constructed at build time, there's no reason to keep
empty initialization functions around, because there's no overhead to
reintroducing them when needed.

gdb/ChangeLog
2019-05-02  Tom Tromey  <tromey@adacore.com>

* valarith.c (_initialize_valarith): Remove.

5 years agoTreat the .gnu.debuglink and .gnu.debugaltlink sections as debug sections when readin...
Nick Clifton [Thu, 2 May 2019 14:11:39 +0000 (15:11 +0100)]
Treat the .gnu.debuglink and .gnu.debugaltlink sections as debug sections when reading them in from COFF/PE format files.

PR 24493
* coffcode.h (styp_to_sec_flags): Treat .gnu.debuglink and
.gnu.debugaltlink sections as debugging sections.

5 years agoAutomatic date update in version.in
GDB Administrator [Thu, 2 May 2019 00:00:22 +0000 (00:00 +0000)]
Automatic date update in version.in

5 years ago[BINUTILS, AArch64] Enable Transactional Memory Extension
Sudakshina Das [Wed, 1 May 2019 16:14:01 +0000 (17:14 +0100)]
[BINUTILS, AArch64] Enable Transactional Memory Extension

This patch enables the new Transactional Memory Extension added recently
as part of Arm's new architecture technologies.

We introduce a new optional extension "tme" to enable this. The following
instructions are part of the extension:
   * tstart <Xt>
   * ttest <Xt>
   * tcommit
   * tcancel #<imm>
The ISA for the above can be found here:
https://developer.arm.com/docs/ddi0602/latest/base-instructions-alphabetic-order

*** gas/ChangeLog ***

2019-05-01  Sudakshina Das  <sudi.das@arm.com>

* config/tc-aarch64.c (parse_operands): Add case for
AARCH64_OPND_TME_UIMM16.
(aarch64_features): Add "tme".
* doc/c-aarch64.texi: Document the same.
* testsuite/gas/aarch64/tme-invalid.d: New test.
* testsuite/gas/aarch64/tme-invalid.l: New test.
* testsuite/gas/aarch64/tme-invalid.s: New test.
* testsuite/gas/aarch64/tme.d: New test.
* testsuite/gas/aarch64/tme.s: New test.

*** include/ChangeLog ***

2019-05-01  Sudakshina Das  <sudi.das@arm.com>

* opcode/aarch64.h (AARCH64_FEATURE_TME): New.
(enum aarch64_opnd): Add AARCH64_OPND_TME_UIMM16.

*** opcodes/ChangeLog ***

2019-05-01  Sudakshina Das  <sudi.das@arm.com>

* aarch64-asm-2.c: Regenerated.
* aarch64-dis-2.c: Regenerated.
* aarch64-opc-2.c: Regenerated.
* aarch64-opc.c (operand_general_constraint_met_p): Add case for
AARCH64_OPND_TME_UIMM16.
(aarch64_print_operand): Likewise.
* aarch64-tbl.h (QL_IMM_NIL): New.
(TME): New.
(_TME_INSN): New.
(struct aarch64_opcode): Add tstart, tcommit, ttest and tcancel.

5 years agoFix spelling mistakes in binutils testsuite.
Matthew Malcomson [Wed, 1 May 2019 15:52:51 +0000 (16:52 +0100)]
Fix spelling mistakes in binutils testsuite.

* testsuite/binutils-all/objdump.exp: Correct executable
spelling.
* testsuite/binutils-all/compress.exp: Likewise.

5 years agoFix bug in assignment to nested packed structure
Tom Tromey [Mon, 29 Apr 2019 15:55:39 +0000 (09:55 -0600)]
Fix bug in assignment to nested packed structure

A user at AdaCore found a case where assignment to a nested packed
structure would fail.  The bug is that ada_value_primitive_field
doesn't account for the situation where a field is not packed relative
to its containing structure, but where the structure itself is packed
in its parent.

gdb/ChangeLog
2019-05-01  Tom Tromey  <tromey@adacore.com>

* ada-lang.c (ada_value_primitive_field): Treat more fields as
bitfields.

gdb/testsuite/ChangeLog
2019-05-01  Tom Tromey  <tromey@adacore.com>

* gdb.ada/packed_array_assign/aggregates.ads (Nested_Packed): New
record.
(NPR): New variable.
* gdb.ada/packed_array_assign.exp: Add nested packed assignment
test.

5 years agoFix big-endian aggregate assignment in Ada
Tom Tromey [Fri, 26 Apr 2019 16:57:52 +0000 (10:57 -0600)]
Fix big-endian aggregate assignment in Ada

A bug internal to AdaCore notes that assigning a non-scalar value to
an element of a packed array will sometimes fail.

The bug turns out to be that ada_value_assign incorrectly computes the
starting point for the assignment.  This patch fixes the problem.

gdb/ChangeLog
2019-05-01  Tom Tromey  <tromey@adacore.com>

* ada-lang.c (ada_value_assign): Correctly compute starting offset
for big-endian copies.

gdb/testsuite/ChangeLog
2019-05-01  Tom Tromey  <tromey@adacore.com>

* gdb.ada/packed_array_assign.exp: Add packed assignment
regression test.

5 years agoChange nm so that when it is running in POSIX compatible mode, it does not prefix...
Nick Clifton [Wed, 1 May 2019 13:43:06 +0000 (14:43 +0100)]
Change nm so that when it is running in POSIX compatible mode, it does not prefix symbol values with 0.

PR 24507
* nm.c: (print_format): New variable.
(value_format_32bit, value_format_64bit): Delete.
(set_print_radix): Remove code to alter value_format strings.
(set_output_format): Record chosen format in print_format.
(get_print_format): New function - constructs a printf formatting
string according to the requirements of size, radix, and output
format.
(print_value): Use get_print_format.
* testsuite/binutils-all/nm.exp: Add tests of "nm --format=posix"
and "nm -t d".

5 years ago[gdb/testsuite] Fix "unable to find usable gdb" error with cc-with-tweaks.exp
Tom de Vries [Wed, 1 May 2019 13:31:14 +0000 (15:31 +0200)]
[gdb/testsuite] Fix "unable to find usable gdb" error with cc-with-tweaks.exp

When running fullpath-expand.exp with target_board=dwarf4-gdb-index, we run
into:
...
$ make check-gdb RUNTESTFLAGS="--target_board=dwarf4-gdb-index fullpath-expand.exp"
Running src/gdb/testsuite/gdb.base/fullpath-expand.exp ...
gdb compile failed, cc-with-tweaks.sh: unable to find usable gdb

                === gdb Summary ===

nr of untested testcases         1
...
The same happens with fullname.exp.

The dwarf4-gdb-index.exp board file includes cc-with-tweaks.exp, which uses
cc-with-tweaks.sh, which calls gdb-add-index.sh.

The gdb-add-index.sh script uses a gdb executable, defaulting to gdb:
...
GDB=${GDB:=gdb}
...

The cc-with-tweaks.sh script tries to ensure that the build gdb executable is
used by gdb-add-index.sh:
...
if [ -z "$GDB" ]
then
    if [ -f ./gdb ]
    then
GDB="./gdb -data-directory data-directory"
    elif [ -f ../gdb ]
    then
GDB="../gdb -data-directory ../data-directory"
    elif [ -f ../../gdb ]
    then
GDB="../../gdb -data-directory ../../data-directory"
    else
echo "$myname: unable to find usable gdb" >&2
exit 1
    fi
fi
...
So, if the current directory is build/gdb/testsuite, then a gdb executable
build/gdb/testsuite/../gdb will be used.

However, in the case of fullpath-expand.exp the test cd's into the sources:
...
set saved_pwd [pwd]
cd $srcdir
set err [gdb_compile "${subdir}/${srcfile} ${subdir}/${srcfile2}" $binfile \
         executable {debug}]
cd $saved_pwd
...
and cc-with-tweaks.sh generates the "unable to find usable gdb" error.

The same error occurs if we use --target_board=cc-with-dwz instead (only in
this case we actually don't need gdb, we just need the GDB variable to be set
in cc-with-tweaks.sh, which arguably is a bug in cc-with-tweaks.sh).

Fix both errors in cc-with-tweaks.exp by generating a gdb script gdb.sh using
$GDB, $GDBFLAGS and $INTERNAL_GDBFLAGS and passing this script to
cc-with-tweaks.sh by setting env(GDB).

Tested on x86_64-linux for gdb.base.

gdb/testsuite/ChangeLog:

2019-05-01  Tom de Vries  <tdevries@suse.de>

* boards/cc-with-tweaks.exp: Generate gdb.sh, and pass it in env(GDB).

5 years ago[gdb/testsuite] Use cc-with-tweaks.exp in dwarf4-gdb-index.exp
Tom de Vries [Wed, 1 May 2019 11:30:52 +0000 (13:30 +0200)]
[gdb/testsuite] Use cc-with-tweaks.exp in dwarf4-gdb-index.exp

Board file dwarf4-gdb-index.exp contains all the commands from
cc-with-tweaks.exp (with CC_WITH_TWEAKS_FLAGS set to "-i").

Make dwarf4-gdb-index.exp smaller by including cc-with-tweaks.exp.

Tested on x86_64-linux for gdb.base.

gdb/testsuite/ChangeLog:

2019-05-01  Tom de Vries  <tdevries@suse.de>

* boards/dwarf4-gdb-index.exp: Use cc-with-tweaks.exp.

5 years agoAutomatic date update in version.in
GDB Administrator [Wed, 1 May 2019 00:00:15 +0000 (00:00 +0000)]
Automatic date update in version.in

5 years agoSupport DW_FORM_strx1, _strx2, _strx3, _strx4 forms.
Ali Tamur [Thu, 25 Apr 2019 20:35:53 +0000 (13:35 -0700)]
Support DW_FORM_strx1, _strx2, _strx3, _strx4 forms.

Dwarf5 defines DW_FORM_strx1 and others, which are similar
to DW_FORM_strx but uses 1-4 bytes unsigned integers. This is
a small step towards supporting dwarf5 in gdb.

5 years agogdb/windows-nat.c: Get rid of main_thread_id global
Joel Brobecker [Tue, 30 Apr 2019 21:00:19 +0000 (16:00 -0500)]
gdb/windows-nat.c: Get rid of main_thread_id global

This global is meant to point to the "main" thread of execution of
the program we are debugging. It is set when attaching to a process
or when receiving a CREATE_PROCESS_DEBUG_EVENT event. The theory at
the time was that this was also going to be the thread receiving
the EXIT_PROCESS_DEBUG_EVENT event.

Unfortunately, we have discovered since then that this is actually
not guaranteed. What this means in practice is that there is moderate
risk that main_thread_id refers to a thread which no longer exists.

This global is used in 3 situations:
  - OUTPUT_DEBUG_STRING_EVENT
  - LOAD_DLL_DEBUG_EVENT
  - UNLOAD_DLL_DEBUG_EVENT

It's not clear why we would need to use the main_thread_id in those cases
instead of using the thread ID provided by the kernel events itself.
So this patch implements this approach, which then allows us to delete
the main_thread_id global.

gdb/testsuite:

* windows-nat.c (main_thread_id): Delete.
(handle_output_debug_string): Replace main_thread_id by
current_event.dwThreadId.
(fake_create_process): Likewise.
(get_windows_debug_event) <CREATE_PROCESS_DEBUG_EVENT>:
Do not set main_thread_id.
<LOAD_DLL_DEBUG_EVENT>: Replace main_thread_id by
current_event.dwThreadId.
<UNLOAD_DLL_DEBUG_EVENT>: Likewise.

5 years ago(Windows) fix thr != nullptr assert failure in delete_thread_1
Joel Brobecker [Tue, 30 Apr 2019 20:59:17 +0000 (15:59 -0500)]
(Windows) fix thr != nullptr assert failure in delete_thread_1

We have observed that GDB would randomly trip the following
assertion failure when debugging on Windows. When allowing
the program to run until the inferior exits, we occasionally see:

     (gdb) cont
     Continuing.
     [Thread 48192.0xd100 exited with code 1]
     [Thread 48192.0x10ad8 exited with code 1]
     [Thread 48192.0x36e28 exited with code 0]
     [Thread 48192.0x52be4 exited with code 0]
     [Thread 48192.0x5aa40 exited with code 0]
     ../../src/gdb/thread.c:453: internal-error: void delete_thread_1(thread_inf
o*, bool): Assertion `thr != nullptr' failed.

Running the same scenario with some additional traces enabled...

    (gdb) set verbose
    (gdb) set debugevents

... allows us to understand what the issue is. To understand, we need
to first look at the events received when starting the program, and
in particular which threads got created how. First, we get a
CREATE_PROCESS_DEBUG_EVENT for tid=0x442a8:

    gdb: kernel event for pid=317536 tid=0x442a8 code=CREATE_PROCESS_DEBUG_EVENT)

Shortly after, we get some CREATE_THREAD_DEBUG_EVENT events,
one of them being for tid=0x4010c:

    gdb: kernel event for pid=317536 tid=0x4010c code=CREATE_THREAD_DEBUG_EVENT)
Fast forward a bit of debugging, and we do a "cont" as above,
at which point the programs reaches the end, and the system reports
"exit" events. The first interesting one is the following:

    gdb: kernel event for pid=317536 tid=0x442a8 code=EXIT_THREAD_DEBUG_EVENT)

This is reporting a thread-exit event for a thread whose tid
is the TID of what we call the "main thread". That's the thread
that was created when we received the CREATE_PROCESS_DEBUG_EVENT
notification, and whose TID is actually stored in a global variable
named main_thread_id. This is not something we expected, as
the assumption we made was that the main thread would exit last,
and we would be notified of it via an EXIT_PROCESS_DEBUG_EVENT.
But apparently, this is not always true, at least on Windows Server
2012 and 2016 where this issue has been observed happening randomly.

The consequence of the above notification is that we call
windows_delete_thread for that thread, which removes it from
our list of known threads.

And a little bit later, then we then get the EXIT_PROCESS_DEBUG_EVENT,
and we can see that the associated tid is not the main_thread_id,
but rather the tid of one of the threads that was created during
the lifetime of the program, in this case tid=0x4010c:

    gdb: kernel event for pid=317536 tid=0x4010c code=EXIT_PROCESS_DEBUG_EVENT)

And the debug trace printed right after shows why we're crashing:

    [Deleting Thread 317536.0x442a8]

We are trying to delete the thread whose tid=0x442a8, which is
the main_thread_id! As we have already deleted that thread before,
the search for it returns a nullptr, which then trips the assertion
check in delete_thread_1.

This commit fixes this issue. It ignores the open question of
what to do with the main_thread_id global, particularly after
that thread has been removed from our list of threads. This will
be dealt with as a separate patch, to allow cherry-picking
this patch into a release branch.

For now, we fix the code so as to avoid this crash.

gdb/ChangeLog:

* windows-nat.c (get_windows_debug_event) <EXIT_PROCESS_DEBUG_EVENT>:
Use current_event.dwThreadId instead of main_thread_id.

5 years agoFix "catch exception" with dynamic linking
Tom Tromey [Wed, 27 Mar 2019 21:00:21 +0000 (15:00 -0600)]
Fix "catch exception" with dynamic linking

When an Ada program is dynamically linked against libgnat, and when
one of the standard exceptions is used, the exception object may be
referenced by the main executable using a copy relocation.

In this situation, a "catch exception" for those exceptions will not
manage to stop.  This happens because, under the hood, "catch
exception" creates an expression object that examines the object
addresses -- but in this case, the address will be incorrect.

This patch fixes the problem by arranging for these filter expressions
to examine all the relevant minimal symbols.  This way, the object
from libgnat will be found as well.

Tested on x86-64 Fedora 29.

gdb/ChangeLog
2019-04-30  Tom Tromey  <tromey@adacore.com>

* ada-lang.c (ada_lookup_simple_minsyms): New function.
(create_excep_cond_exprs): Iterate over program spaces.
(ada_exception_catchpoint_cond_string): Examine all minimal
symbols for exception types.

gdb/testsuite/ChangeLog
2019-04-30  Tom Tromey  <tromey@adacore.com>

* lib/ada.exp (find_ada_tool): New proc.
* lib/gdb.exp (gdb_compile_shlib): Allow .o files as inputs.
* gdb.ada/catch_ex_std.exp: New file.
* gdb.ada/catch_ex_std/foo.adb: New file.
* gdb.ada/catch_ex_std/some_package.adb: New file.
* gdb.ada/catch_ex_std/some_package.ads: New file.

5 years agoFix crash in dwarf2read.c with template parameters
Tom Tromey [Mon, 22 Apr 2019 17:46:47 +0000 (11:46 -0600)]
Fix crash in dwarf2read.c with template parameters

PR c++/24470 concerns a crash in dwarf2read.c that occurs with a
particular test case.

The issue turns out to be that process_structure_scope will pass NULL
to symbol_symtab.  This happens because new_symbol decided not to
create a symbol for the particular DIE.

This patch fixes the problem by finding another reasonably-appropriate
symtab to use instead; issuing a complaint if one cannot be found for
some reason.

As mentioned in the bug, I think there are other bugs here.  For
example, when using "ptype" on the "l" object in the test case, I
think I would expect to see the template parameter.  I didn't research
this too closely, since it seemed more important to fix the crash.

Tested on x86-64 Fedora 29.

I'd like to check this in to the 8.3 branch as well.

2019-04-30  Tom Tromey  <tromey@adacore.com>

PR c++/24470:
* dwarf2read.c (process_structure_scope): Handle case where type
has template parameters but no symbol was created.

gdb/testsuite/ChangeLog
2019-04-30  Tom Tromey  <tromey@adacore.com>

PR c++/24470:
* gdb.cp/temargs.cc: Add test code from PR.

5 years agoPowerPC64 GOT indirect to GOT relative optimisation
Alan Modra [Tue, 30 Apr 2019 07:01:01 +0000 (16:31 +0930)]
PowerPC64 GOT indirect to GOT relative optimisation

This implements an optimisation that converts sequences like
  addis r9,r2,sym@got@ha
  ld r3,sym@got@l(r9)
to
  addis r9,r2,sym@toc@ha
  addi r3,r9,sym@toc@l
when "sym" is locally defined and can't be overridden.

bfd/
* elf64-ppc.c (struct ppc64_elf_obj_tdata): Add has_gotrel.
(struct _ppc64_elf_section_data): Likewise.
(ppc64_elf_check_relocs): Set above fields.
(ppc64_elf_edit_toc): Add a pass over GOT relocs.
(ppc64_elf_relocate_section): Edit GOT indirect to GOT relative
when possible.
ld/
* testsuite/ld-powerpc/elfv2exe.d: Update.
* testsuite/ld-powerpc/elfv2so.d: Update.
* testsuite/ld-powerpc/tocopt.d: Update.
* testsuite/ld-powerpc/tocopt.s: Update.
* testsuite/ld-powerpc/tocopt5.d: Update.
* testsuite/ld-powerpc/tocopt5.s: Update.
* testsuite/ld-powerpc/tocopt7.d: Update.
* testsuite/ld-powerpc/tocopt7.s: Update.
* testsuite/ld-powerpc/tocopt8.d: Update.
* testsuite/ld-powerpc/tocopt8.s: Update.

5 years agoWork around gcc9 warning bug
Alan Modra [Sun, 28 Apr 2019 23:47:05 +0000 (09:17 +0930)]
Work around gcc9 warning bug

* wrstabs.c (stab_start_class_type): Add assert to work around
gcc9 warning.  Tidy.

5 years agold.texi tweak for pod2man
Alan Modra [Sat, 27 Apr 2019 00:57:49 +0000 (10:27 +0930)]
ld.texi tweak for pod2man

Fixes the following error:
ld.pod around line 568: Expected '=item *'
POD document had syntax errors at /usr/bin/pod2man line 71.

* ld.texi (How GNU properties are merged): Avoid pod2man error.
Correct example.

5 years agogdb/fortran: Add allocatable type qualifier
Andrew Burgess [Thu, 7 Mar 2019 16:53:54 +0000 (16:53 +0000)]
gdb/fortran: Add allocatable type qualifier

Types in Fortran can have the 'allocatable' qualifier attached to
indicate that memory needs to be explicitly allocated by the user.
This patch extends GDB to show this qualifier when printing types.

Lots of tests results are then updated to include this new qualifier
in the expected results.

gdb/ChangeLog:

* f-typeprint.c (f_type_print_base): Print 'allocatable' type
qualifier.
* gdbtypes.h (TYPE_IS_ALLOCATABLE): Define.

gdb/testsuite/ChangeLog:

* gdb.fortran/vla-datatypes.exp: Update expected results.
* gdb.fortran/vla-ptype.exp: Likewise.
* gdb.fortran/vla-type.exp: Likewise.
* gdb.fortran/vla-value.exp: Likewise.

5 years agogdb/fortran: Update rules for printing whitespace in types
Andrew Burgess [Sun, 17 Feb 2019 00:37:20 +0000 (00:37 +0000)]
gdb/fortran: Update rules for printing whitespace in types

The whitespace produced as types are printed seems inconsistent.  This
commit updates the rules in an attempt to make whitespace more
balanced and consistent.  Expected results are updated.

gdb/ChangeLog:

* f-typeprint.c (f_print_type): Update rules for printing
whitespace.
(f_type_print_varspec_suffix): Likewise.

gdb/testsuite/ChangeLog:

* gdb.fortran/ptr-indentation.exp: Update expected results.
* gdb.fortran/ptype-on-functions.exp: Likewise.
* gdb.fortran/vla-ptr-info.exp: Likewise.
* gdb.fortran/vla-value.exp: Likewise.

5 years agogdb/fortran: print function arguments when printing function type
Andrew Burgess [Sat, 16 Feb 2019 17:26:44 +0000 (17:26 +0000)]
gdb/fortran: print function arguments when printing function type

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.

5 years agogdb/fortran: Print 'void' type in lower case
Andrew Burgess [Sat, 16 Feb 2019 16:39:29 +0000 (16:39 +0000)]
gdb/fortran: Print 'void' type in lower case

For a program compiled with gfortran the base type names are written
as lower cases in the DWARF, and so GDB will display them as lower
case.  Additionally, in most places where GDB supplies its own type
names (for example all of the types defined in f-lang.c in
`build_fortran_types`), the type names are all lower case.

An exception to this is where GDB prints the void type for Fortran.
In this case GDB uses upper case.

I'm not aware of any reason why this type should merit special
attention, and it looks our of place when printing types, so this
commit changes from 'VOID' to 'void' to match all the other types.

gdb/ChangeLog:

* f-lang.c (build_fortran_types): Change name of void type to
lower case.
* f-typeprint.c (f_type_print_base): Print the name of the void
type, rather than a fixed string.
* f-valprint.c (f_decorations): Use lower case void string.

gdb/testsuite/ChangeLog:

* gdb.fortran/exprs.exp (test_convenience_variables): Expect lower
case void string.

5 years agogdb/fortran: better types for components of complex numbers
Andrew Burgess [Sat, 16 Feb 2019 22:45:41 +0000 (22:45 +0000)]
gdb/fortran: better types for components of complex numbers

Currently when using $_creal and $_cimag to access the components of a
complex number the types of these components will have C type names
'float', 'double', etc.  This is because the components of a complex
number are not given type names in DWARF, so GDB has to pick some
suitable names, and currently we always use the C names.

This commit changes the type names used based on the language, so for
Fortran we will now use the Fortran float types, and so will get the
Fortran float type names 'real', 'real*8', etc.

gdb/ChangeLog:

* dwarf2read.c (dwarf2_init_complex_target_type): Use different
types for Fortran.

gdb/testsuite/ChangeLog:

* gdb.fortran/complex.exp: Expand.
* gdb.fortran/complex.f: Renamed to...
* gdb.fortran/complex.f90: ...this, and extended to add more
complex values.

5 years agogdb/fortran: Additional builtin procedures
Andrew Burgess [Wed, 13 Feb 2019 17:10:18 +0000 (17:10 +0000)]
gdb/fortran: Additional builtin procedures

Add some additional builtin procedures for Fortran, these are MOD,
CEILING, FLOOR, MODULO, and CMPLX.

gdb/ChangeLog:

* f-exp.y (BINOP_INTRINSIC): New token.
(exp): New parser rule handling BINOP_INTRINSIC.
(f77_keywords): Add new builtin procedures.
* f-lang.c (evaluate_subexp_f): Handle BINOP_MOD, UNOP_FORTRAN_CEILING,
UNOP_FORTRAN_FLOOR, BINOP_FORTRAN_MODULO, BINOP_FORTRAN_CMPLX.
(operator_length_f): Handle UNOP_FORTRAN_CEILING,
UNOP_FORTRAN_FLOOR, BINOP_FORTRAN_MODULO, BINOP_FORTRAN_CMPLX.
(print_unop_subexp_f): New function.
(print_binop_subexp_f): New function.
(print_subexp_f): Handle UNOP_FORTRAN_CEILING, UNOP_FORTRAN_FLOOR,
BINOP_FORTRAN_MODULO, BINOP_FORTRAN_CMPLX.
(dump_subexp_body_f): Likewise.
(operator_check_f): Likewise.
* fortran-operator.def: Add UNOP_FORTRAN_CEILING, UNOP_FORTRAN_FLOOR,
BINOP_FORTRAN_MODULO, BINOP_FORTRAN_CMPLX

gdb/testsuite/ChangeLog:

* gdb.fortran/intrinsics.exp: Extend to cover MOD, CEILING, FLOOR,
MODULO, CMPLX.

5 years agogdb/fortran: Introduce fortran-operator.def file
Andrew Burgess [Mon, 1 Apr 2019 20:01:09 +0000 (21:01 +0100)]
gdb/fortran: Introduce fortran-operator.def file

Future commits will add more Fortran specific expression operators.

In preparation for these new operators, this commit adds a new
fortran-operator.def file similar to how GDB already has
ada-operator.def.

I've moved UNOP_KIND the Fortran specific operator I introduced in
commit 4d00f5d8f6c4 into this file, and renamed it to make it clearer
that the operator is Fortran specific.  I've then updated the Fortran
exp_descriptor table (exp_descriptor_f) to use entirely Fortran
specific functions that now handle UNOP_FORTRAN_KIND (the new name for
UNOP_KIND).

There should be no visible changes for standard users after this
commit, though for developers, the output when 'set debug expression
1' is now better, before:

  (gdb) p kind (l1)
  Dump of expression @ 0x2ccc7a0, before conversion to prefix form:
   Language fortran, 5 elements, 16 bytes each.
   Index                Opcode         Hex Value  String Value
       0          OP_VAR_VALUE  42  *...............
       1               OP_NULL  47730176  .N..............
       2          BINOP_INTDIV  47729184   J..............
       3          OP_VAR_VALUE  42  *...............
       4             UNOP_KIND  78  N...............
  Dump of expression @ 0x2ccc7a0, after conversion to prefix form:
  Expression: `Invalid expression
  (gdb)

and after:

  (gdb) p kind (l1)
  Dump of expression @ 0x294d0b0, before conversion to prefix form:
   Language fortran, 5 elements, 16 bytes each.
   Index                Opcode         Hex Value  String Value
       0          OP_VAR_VALUE  40  (...............
       1   unknown opcode: 224  44088544  ................
       2   unknown opcode: 208  44087504  ................
       3          OP_VAR_VALUE  40  (...............
       4     UNOP_FORTRAN_KIND  119  w...............
  Dump of expression @ 0x294d0b0, after conversion to prefix form:
  Expression: `KIND(test::l1)'
   Language fortran, 5 elements, 16 bytes each.

       0  UNOP_FORTRAN_KIND
       1    OP_VAR_VALUE          Block @0x2a0bce0, symbol @0x2a0b8d0 (l1)
  $1 = 1
  (gdb)

gdb/ChangeLog:

* gdb/expprint.c (dump_subexp_body_standard): Remove use of
UNOP_KIND.
* gdb/expression.h (exp_opcode): Include 'fortran-operator.def'.
* gdb/f-exp.y (exp): Rename UNOP_KIND to UNOP_FORTRAN_KIND.
* gdb/f-lang.c (evaluate_subexp_f): Likewise.
(operator_length_f): New fuction.
(print_subexp_f): New function.
(op_name_f): New function.
(dump_subexp_body_f): New function.
(operator_check_f): New function.
(exp_descriptor_f): Replace standard expression handling functions
with new functions.
* gdb/fortran-operator.def: New file.
* gdb/parse.c (operator_length_standard): Remove use of UNOP_KIND.
* gdb/std-operator.def: Remove UNOP_KIND.

5 years agogdb: Remove an unbalanced stray double quote from a comment
Andrew Burgess [Sat, 30 Mar 2019 17:14:23 +0000 (17:14 +0000)]
gdb: Remove an unbalanced stray double quote from a comment

What appears to be a stray double quote character in std-operator.def
causes incorrect highlighting in my editor.

The quote was introduced in this commit:

    commit 858be34c5a03bb8973679ebf00d360182434dc00
    Date:   Mon Sep 4 20:21:15 2017 +0100

        Handle "p S::method()::static_var" in the C++ parser

I can't see any reason why the quote should be there, so this commit
removes it.

gdb/ChangeLog:

* std-operator.def: Remove unbalanced, stray double quote
character.

5 years agoAutomatic date update in version.in
GDB Administrator [Tue, 30 Apr 2019 00:00:28 +0000 (00:00 +0000)]
Automatic date update in version.in

5 years agogdb: Introduce 'print max-depth' feature
Andrew Burgess [Thu, 21 Mar 2019 15:13:23 +0000 (15:13 +0000)]
gdb: Introduce 'print max-depth' feature

Introduce a new print setting max-depth which can be set with 'set
print max-depth DEPTH'.  The default value of DEPTH is 20, but this
can also be set to unlimited.

When GDB is printing a value containing nested structures GDB will
stop descending at depth DEPTH.  Here is a small example:

    typedef struct s1 { int a; } s1;
    typedef struct s2 { s1 b; } s2;
    typedef struct s3 { s2 c; } s3;
    typedef struct s4 { s3 d; } s4;

    s4 var = { { { { 3 } } } };

The following table shows how various depth settings affect printing
of 'var':

    | Depth Setting | Result of 'p var'              |
    |---------------+--------------------------------|
    |     Unlimited | $1 = {d = {c = {b = {a = 3}}}} |
    |             4 | $1 = {d = {c = {b = {a = 3}}}} |
    |             3 | $1 = {d = {c = {b = {...}}}}   |
    |             2 | $1 = {d = {c = {...}}}         |
    |             1 | $1 = {d = {...}}               |
    |             0 | $1 = {...}                     |

Only structures, unions, and arrays are replaced in this way, scalars
and strings are not replaced.

The replacement is counted from the level at which you print, not from
the top level of the structure.  So, consider the above example and
this GDB session:

    (gdb) set print max-depth 2
    (gdb) p var
    $1 = {d = {c = {...}}}
    (gdb) p var.d
    $2 = {c = {b = {...}}}
    (gdb) p var.d.c
    $3 = {b = {a = 3}}

Setting the max-depth to 2 doesn't prevent the user from exploring
deeper into 'var' by asking for specific sub-fields to be printed.

The motivation behind this feature is to try and give the user more
control over how much is printed when examining large, complex data
structures.

The default max-depth of 20 means that there is a change in GDB's
default behaviour.  Someone printing a data structure with 20 levels
of nesting will now see '{...}' instead of their data, they would need
to adjust the max depth, or call print again naming a specific field
in order to dig deeper into their data structure.  If this is
considered a problem then we could increase the default, or even make
the default unlimited.

This commit relies on the previous commit, which added a new field to
the language structure, this new field was a string that contained the
pattern that should be used when a structure/union/array is replaced
in the output, this allows languages to use a syntax that is more
appropriate, mostly this will be selecting the correct types of
bracket '(...)' or '{...}', both of which are currently in use.

This commit should have no impact on MI output, expressions are
printed through the MI using -var-create and then -var-list-children.
As each use of -var-list-children only ever displays a single level of
an expression then the max-depth setting will have no impact.

This commit also adds the max-depth mechanism to the scripting
language pretty printers following basically the same rules as for the
built in value printing.

One quirk is that when printing a value using the display hint 'map',
if the keys of the map are structs then GDB will hide the keys one
depth level after it hides the values, this ensures that GDB produces
output like this:

  $1 = map_object = {[{key1}] = {...}, [{key2}] = {...}}

Instead of this less helpful output:

  $1 = map_object = {[{...}] = {...}, [{...}] = {...}}

This is covered by the new tests in gdb.python/py-nested-maps.exp.

gdb/ChangeLog:

* cp-valprint.c (cp_print_value_fields): Allow an additional level
of depth when printing anonymous structs or unions.
* guile/scm-pretty-print.c (gdbscm_apply_val_pretty_printer):
Don't print either the top-level value, or the children if the
max-depth is exceeded.
(ppscm_print_children): When printing the key of a map, allow one
extra level of depth.
* python/py-prettyprint.c (gdbpy_apply_val_pretty_printer): Don't
print either the top-level value, or the children if the max-depth
is exceeded.
(print_children): When printing the key of a map, allow one extra
level of depth.
* python/py-value.c (valpy_format_string): Add max_depth keyword.
* valprint.c: (PRINT_MAX_DEPTH_DEFAULT): Define.
(user_print_options): Initialise max_depth field.
(val_print_scalar_or_string_type_p): New function.
(val_print): Check to see if the max depth has been reached.
(val_print_check_max_depth): Define new function.
(show_print_max_depth): New function.
(_initialize_valprint): Add 'print max-depth' option.
* valprint.h (struct value_print_options) <max_depth>: New field.
(val_print_check_max_depth): Declare new function.
* NEWS: Document new feature.

gdb/doc/ChangeLog:

* gdb.texinfo (Print Settings): Document 'print max-depth'.
* guile.texi (Guile Pretty Printing API): Document that 'print
max-depth' can effect the display of a values children.
* python.texi (Pretty Printing API): Likewise.
(Values From Inferior): Document max_depth keyword.

gdb/testsuite/ChangeLog:

* gdb.base/max-depth.c: New file.
* gdb.base/max-depth.exp: New file.
* gdb.python/py-nested-maps.c: New file.
* gdb.python/py-nested-maps.exp: New file.
* gdb.python/py-nested-maps.py: New file.
* gdb.python/py-format-string.exp (test_max_depth): New proc.
(test_all_common): Call test_max_depth.
* gdb.fortran/max-depth.exp: New file.
* gdb.fortran/max-depth.f90: New file.
* gdb.go/max-depth.exp: New file.
* gdb.go/max-depth.go: New file.
* gdb.modula2/max-depth.exp: New file.
* gdb.modula2/max-depth.c: New file.
* lib/gdb.exp (get_print_expr_at_depths): New proc.

5 years agogdb: Introduce new language field la_is_string_type_p
Andrew Burgess [Tue, 9 Apr 2019 22:06:41 +0000 (23:06 +0100)]
gdb: Introduce new language field la_is_string_type_p

This commit is preparation work for the next commit, and by itself
makes no user visible change to GDB.  I've split this work into a
separate commit in order to make code review easier.

This commit adds a new field 'la_is_string_type_p' to the language
struct, this predicate will return true if a type is a string type for
the given language.

Some languages already have a "is this a string" predicate that I was
able to reuse, while for other languages I've had to add a new
predicate.  In this case I took inspiration from the value printing
code for that language - what different conditions would result in
printing something as a string.

A default "is this a string" method has also been added that looks for
TYPE_CODE_STRING, this is the fallback I've used for a couple of
languages.

In this commit I add the new field and initialise it for each
language, however at this stage the new field is never used.

gdb/ChangeLog:

* ada-lang.c (ada_language_defn): Initialise new field.
* c-lang.c (c_is_string_type_p): New function.
(c_language_defn): Initialise new field.
(cplus_language_defn): Initialise new field.
(asm_language_defn): Initialise new field.
(minimal_language_defn): Initialise new field.
* c-lang.h (c_is_string_type_p): Declare new function.
* d-lang.c (d_language_defn): Initialise new field.
* f-lang.c (f_is_string_type_p): New function.
(f_language_defn): Initialise new field.
* go-lang.c (go_is_string_type_p): New function.
(go_language_defn): Initialise new field.
* language.c (default_is_string_type_p): New function.
(unknown_language_defn): Initialise new field.
(auto_language_defn): Initialise new field.
* language.h (struct language_defn) <la_is_string_type_p>: New
member variable.
(default_is_string_type_p): Declare new function.
* m2-lang.c (m2_language_defn): Initialise new field.
* objc-lang.c (objc_language_defn): Initialise new field.
* opencl-lang.c (opencl_language_defn): Initialise new field.
* p-lang.c (pascal_is_string_type_p): New function.
(pascal_language_defn): Initialise new field.
* rust-lang.c (rust_is_string_type_p): New function.
(rust_language_defn): Initialise new field.

5 years agogdb: Introduce new language field la_struct_too_deep_ellipsis
Andrew Burgess [Tue, 26 Mar 2019 19:34:06 +0000 (19:34 +0000)]
gdb: Introduce new language field la_struct_too_deep_ellipsis

This commit is preparation work for a later commit, and by itself
makes no user visible change to GDB.  I've split this work into a
separate commit in order to make code review easier.

This commit adds a new field 'la_struct_too_deep_ellipsis' to the
language struct, this string will be used in the next commit to print
a language specific string from within the generic value printing
code.

In this commit I add the new field and initialise it for each
language, however at this stage the new field is never used.

gdb/ChangeLog:

* language.h (struct language_defn) <la_struct_too_deep_ellipsis>:
New field.
* ada-lang.c (ada_language_defn): Initialise new field.
* c-lang.c (c_language_defn): Likewise.
(cplus_language_defn): Likewise.
(asm_language_defn): Likewise.
(minimal_language_defn): Likewise.
* d-lang.c (d_language_defn): Likewise.
* f-lang.c (f_language_defn): Likewise.
* go-lang.c (go_language_defn): Likewise.
* language.c (unknown_language_defn): Likewise.
(auto_language_defn): Likewise.
* m2-lang.c (m2_language_defn): Likewise.
* objc-lang.c (objc_language_defn): Likewise.
* opencl-lang.c (opencl_language_defn): Likewise.
* p-lang.c (pascal_language_defn): Likewise.
* rust-lang.c (rust_language_defn): Likewise.

5 years agogdb/ada: Update some predicate functions to return bool
Andrew Burgess [Wed, 10 Apr 2019 22:07:10 +0000 (23:07 +0100)]
gdb/ada: Update some predicate functions to return bool

A later commit would like to make use of a pointer to the function
ada_is_string_type, however, this will require the function to return
a bool (so the signature matches).

As the ada_is_string_type is a predicate function, and its return
value is only ever used as either true or false, then this commit
updates the function to return a bool.

As a consequence ada_is_character_type needs to change too.

There should be no user visible changes after this commit.

gdb/ChangeLog:

* ada-lang.c (ada_is_character_type): Change return type to bool.
(ada_is_string_type): Likewise.
* ada-lang.h (ada_is_character_type): Update declaration
(ada_is_string_type): Likewise.

5 years ago[gdb/testsuite] Fix regexp in skip_opencl_tests
Tom de Vries [Mon, 29 Apr 2019 14:52:10 +0000 (16:52 +0200)]
[gdb/testsuite] Fix regexp in skip_opencl_tests

When running gdb-caching-proc.exp, if skip_opencl_tests fails like this:
...
(gdb) run
Starting program: \
  build/gdb/testsuite/outputs/gdb.base/gdb-caching-proc/opencltest13530.x
CHK_ERR (clGetPlatformIDs (1, &platform, NULL), -1001)
src/gdb/testsuite/lib/opencl_hostapp.c:73 error: Unknown
[Inferior 1 (process 13600) exited with code 01]
(gdb)
skip_opencl_tests: OpenCL support not detected
...
then this regexp in skip_opencl_tests fails to match:
...
        -re ".*$inferior_exited_re code.*${gdb_prompt} $" {
...
so instead we hit the default clause after a 30 seconds timeout.  With the
iteration count set at 10, we end up taking 6 minutes to run this test-case.

Fix this by adding the missing "with" in the regexp, bring back the runtime to
half a minute.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

2019-04-29  Tom de Vries  <tdevries@suse.de>

* lib/opencl.exp (skip_opencl_tests): Add missing "with" in regexp.

5 years agoS12Z: Opcodes: Fix crash when trying to decode a truncated operation.
John Darrington [Mon, 29 Apr 2019 14:05:54 +0000 (16:05 +0200)]
S12Z: Opcodes: Fix crash when trying to decode a truncated operation.

opcodes/
* s12z-opc.c (shift_discrim): Return OP_INVALID when reading fails.

gas/
* testsuite/gas/s12z/truncated.d: New file.
* testsuite/gas/s12z/truncated.s: New file.
* testsuite/gas/s12z/s12z.exp: Add new test.

5 years agoAutomatic date update in version.in
GDB Administrator [Mon, 29 Apr 2019 00:00:32 +0000 (00:00 +0000)]
Automatic date update in version.in

5 years agoFollow-up to Support style in 'frame|thread apply'
Philippe Waroquiers [Sun, 28 Apr 2019 04:54:32 +0000 (06:54 +0200)]
Follow-up to Support style in 'frame|thread apply'

Fix build problem when configuring with guile.
Fix the forgotten copy of ChangeLog info to ChangeLog.

5 years agoAutomatic date update in version.in
GDB Administrator [Sun, 28 Apr 2019 00:01:02 +0000 (00:01 +0000)]
Automatic date update in version.in

5 years agoHave 'thread|frame apply' style their output.
Philippe Waroquiers [Sat, 9 Mar 2019 22:55:44 +0000 (23:55 +0100)]
Have 'thread|frame apply' style their output.

'thread|frame apply CMD' launches CMD so that CMD output goes to a string_file.
This patch ensures that string_file for such CMD output contains
style escape sequences that 'thread|frame apply' will later on
output on the real terminal, so as to have CMD output properly styled.

The idea is to have the class ui_file having overridable methods
to indicate that the output to this ui_file should be done using
'terminal' behaviour such as styling.
Then these methods are overriden in string_file so that a specially
constructed string_file will get output with style escape sequences.

After this patch, the output of CMD by thread|frame apply CMD is styled
similarly as when CMD is launched directly.
Note that string_file (term_out true) could also support wrapping,
but this is not done (yet?).

Tested on debian/amd64.

gdb/ChangeLog
2019-04-27  Philippe Waroquiers  <philippe.waroquiers@skynet.be>

Support style in 'frame|thread apply'

* gdbcmd.h (execute_command_to_string): New term_out parameter.
* record.c (record_start, record_stop): Update callers of
execute_command_to_string with false.
* ui-file.h (class ui_file): New term_out and can_emit_style_escape
methods.
(class string_file): New constructor with term_out parameter.
Override methods term_out and can_emit_style_escape.  New member
term_out.
(class stdio_file): Override can_emit_style_escape.
(class tee_file): Override term_out and can_emit_style_escape.
* utils.h (can_emit_style_escape): Remove.
* utils.c (can_emit_style_escape): Likewise.
Update all callers of can_emit_style_escape (SOMESTREAM) to
SOMESTREAM->can_emit_style_escape.
* source-cache.c (source_cache::get_source_lines): Likewise.
* stack.c (frame_apply_command_count): Call execute_command_to_string
passing the term_out characteristic of the current gdb_stdout.
* thread.c (thr_try_catch_cmd): Likewise.
* top.c (execute_command_to_string): pass term_out parameter
to construct the string_file for the command output.
* ui-file.c (term_cli_styling): New function (most code moved
from utils.c can_emit_style_escape).
(string_file::string_file, string_file::can_emit_style_escape,
stdio_file::can_emit_style_escape, tee_file::term_out,
tee_file::can_emit_style_escape): New functions.

5 years agoImplement show | set may-call-functions [on|off]
Philippe Waroquiers [Tue, 23 Apr 2019 21:43:24 +0000 (23:43 +0200)]
Implement show | set may-call-functions [on|off]

Inferior function calls are powerful but might lead to undesired
results such as crashes when calling nested functions (frequently
used in particular in Ada).

This implements a GDB setting to disable calling inferior functions.

Note: the idea is that if/when the 'slash command' patch is pushed,
that this setting can be changed e.g. by using the shortcut /c.

This is version 2 of the patch.  It handles all the received comments,
mostly replace 'can-call' by 'may-call', and avoid using
'inferior function call' in factor of 'calling function in the program'.

2019-04-26  Philippe Waroquiers  <philippe.waroquiers@skynet.be>

gdb/ChangeLog
* NEWS: Mention the new set|show may-call-functions.
* infcall.c (may_call_functions_p): New variable.
(show_may_call_functions_p): New function.
(call_function_by_hand_dummy): Throws an error if not
may-call-functions.
(_initialize_infcall): Call add_setshow_boolean_cmd for
may-call-functions.

gdb/testsuite/ChangeLog
* gdb.base/callexit.exp: Test may-call-functions off.

gdb/doc/ChangeLog
* gdb.texinfo (Calling): Document the new
set|show may-call-functions.

5 years ago[MIPS] Add load-link, store-conditional paired instructions
Andrew Bennett [Mon, 22 Apr 2019 22:12:09 +0000 (15:12 -0700)]
[MIPS] Add load-link, store-conditional paired instructions

Add several baseline MIPS32R6[1] and MIPS64R6[2] instructions
that were omitted from the initial spec.  These instructions
are optional in implementations but not associated with any
ASE or pseudo-ASE.  Their presence is indicated by the XNP bit
in the Config5 register.

[1] "MIPS Architecture for Programmers Volume II-A: The MIPS32
     Instruction Set Manual", Imagination Technologies Ltd., Document
     Number: MD00086, Revision 6.06, December 15, 2016, Section 3.2
     "Alphabetical List of Instructions", pp. 228-229, pp. 354-357.

[2] "MIPS Architecture for Programmers Volume II-A: The MIPS64
     Instruction Set Manual", Imagination Technologies Ltd., Document
     Number: MD00087, Revision 6.06, December 15, 2016, Section 3.2
     "Alphabetical List of Instructions", pp. 289-290 and pp. 458-460.

gas/
* config/tc-mips.c (macro) <M_LLWP_AB, M_LLDP_AB, M_SCWP_AB,
M_SCDP_AB>: New cases and expansions for paired instructions.
* testsuite/gas/mips/llpscp-32.s: New test source.
* testsuite/gas/mips/llpscp-64.s: Likewise.
* testsuite/gas/mips/llpscp-32.d: New test.
* testsuite/gas/mips/llpscp-64.d: Likewise.
* testsuite/gas/mips/mips.exp: Run the new tests.
* testsuite/gas/mips/r6.s: Add new instructions to test source.
* testsuite/gas/mips/r6-64.s: Likewise.
* testsuite/gas/mips/r6-64-n32.d: Check new instructions.
* testsuite/gas/mips/r6-64-n64.d: Likewise.
* testsuite/gas/mips/r6-n32.d: Likewise.
* testsuite/gas/mips/r6-n64.d: Likwwise.
* testsuite/gas/mips/r6.d: Likewise.

include/
* opcode/mips.h (M_LLWP_AB, M_LLDP_AB): New enum values.
(M_SCWP_AB, M_SCDP_AB): Likewise.

opcodes/
* mips-opc.c (mips_builtin_opcodes): Add llwp, lldp, scwp, scdp.

5 years agoAutomatic date update in version.in
GDB Administrator [Sat, 27 Apr 2019 00:00:28 +0000 (00:00 +0000)]
Automatic date update in version.in

5 years agoi386: Don't add 0x66 prefix to IRET for .code16gcc
H.J. Lu [Fri, 26 Apr 2019 17:19:53 +0000 (10:19 -0700)]
i386: Don't add 0x66 prefix to IRET for .code16gcc

The .code16gcc directive supports 16bit mode with 32-bit address.  Since
IRET (opcode 0xcf) in 16bit mode returns from an interrupt in 16bit mode,
we shouldn't add 0x66 prefix for IRET.

PR gas/24485
* config/tc-i386.c (process_suffix): Don't add DATA_PREFIX_OPCODE
to IRET for .code16gcc.
* testsuite/gas/i386/jump16.s: Add IRET tests.
* testsuite/gas/i386/jump16.d: Updated.

5 years agoDon't complain undefined weak dynamic reference
H.J. Lu [Fri, 26 Apr 2019 14:52:00 +0000 (07:52 -0700)]
Don't complain undefined weak dynamic reference

When undefined non-weak references in IR objects are optimized out
by LTO, we can have weak dynamic referencs to symbols marked with
bfd_link_hash_undefined.  We shouldn't complain such undefined weak
dynamic references.

bfd/

PR ld/24486
* elflink.c (elf_link_output_extsym): Don't complain undefined
weak dynamic reference.

ld/

PR ld/24486
* testsuite/ld-plugin/lto.exp: Run PR ld/24486 tests.
* testsuite/ld-plugin/pr24486a.c: New file.
* testsuite/ld-plugin/pr24486b.c: Likewise.
* testsuite/ld-plugin/pr24486c.c: Likewise.

5 years agoUpdated Russian translation for the ld subdirectory.
Nick Clifton [Fri, 26 Apr 2019 14:29:39 +0000 (15:29 +0100)]
Updated Russian translation for the ld subdirectory.

* po/ru.po: Updated Russian translation.

5 years agoFix the hyphenation of word phrases such as "target specific" and "machine specific".
Christopher Yeleighton [Fri, 26 Apr 2019 14:23:59 +0000 (15:23 +0100)]
Fix the hyphenation of word phrases such as "target specific" and "machine specific".

* ld.texi: Properly hyphenate the word "specific".

5 years agoAutomatic date update in version.in
GDB Administrator [Fri, 26 Apr 2019 00:00:21 +0000 (00:00 +0000)]
Automatic date update in version.in

5 years agoc++/24367: Infinite recursion of typedef substitution
Keith Seitz [Thu, 25 Apr 2019 20:05:51 +0000 (13:05 -0700)]
c++/24367: Infinite recursion of typedef substitution

This bug finds another usage where we end up segfaulting while
normalizing user input.  inspect_type and replace_type recurse,
attempting to substitute the "real" symbol name for the typedef name.
However, since the both these names are the same, they keep calling
each other until the stack overflows.

A simple reproducer for it is given by

  typedef struct foo foo;
  int qux (foo *f) { return 0; }

  (gdb) b qux(foo*)
  Segmentation fault

inspect_type already contains some special handling to prevent a
similar situation from occurring with namespaces.  I wonder, however,
whether we need be so pedantic about the exact nature of the substitution.

This patch implements this rather more aggressive assumption that these
substitutions should be avoided whenever the replacement symbol's name is
exactly the same as the one we're trying to substitute.  [In the above
example, we're trying to substitute the tyepdef named "foo" with the symbol
named "foo" (a struct).]

gdb/ChangeLog:

PR c++/24367
* cp-support.c (inspect_type): Don't attempt substitutions
of symbol with the same name.

gdb/testsuite/ChangeLog:

PR c++/24367
* gdb.cp/meth-typedefs.cc (incomplete_struct)
(another_incomplete_struct, test_incomplete): New definitions.
(main): Use new definitions.
* gdb.cp/meth-typedefs.exp: Add new tests for `test_incomplete'
functions.

5 years agoFix memory leak in exception code
Tom Tromey [Wed, 24 Apr 2019 18:13:35 +0000 (12:13 -0600)]
Fix memory leak in exception code

PR gdb/24475 concerns a memory leak coming from gdb's exception
handling code.

The leak occurs because throw_exception_sjlj does not arrange to
destroy the exception object it is passed.  However, because
gdb_exception has a destructor, it's undefined to longjmp in this
situation.

This patch fixes the problem by avoiding the need to run any
destructors in gdb_rl_callback_handler, by making the gdb_exception
"static".

gdb/ChangeLog
2019-04-25  Tom Tromey  <tromey@adacore.com>

PR gdb/24475:
* event-top.c (gdb_rl_callback_handler): Make "gdb_rl_expt"
static.

5 years agoMake exception handling more efficient
Tom Tromey [Wed, 24 Apr 2019 12:50:06 +0000 (06:50 -0600)]
Make exception handling more efficient

This makes exception handling more efficient in a few spots, through
the use of const- and rvalue-references.

I wrote this patch by commenting out the gdb_exception copy
constructor and then examining the resulting error messages one by
one, introducing the use of std::move where appropriate.

gdb/ChangeLog
2019-04-25  Tom Tromey  <tromey@adacore.com>

* xml-support.c (struct gdb_xml_parser) <set_error>: Take an
rvalue reference.
(gdb_xml_start_element_wrapper, gdb_xml_end_element_wrapper)
(gdb_xml_parser::parse): Use std::move.
* python/python-internal.h (gdbpy_convert_exception): Take a const
reference.
* python/py-value.c (valpy_getitem, valpy_nonzero): Use
std::move.
* python/py-utils.c (gdbpy_convert_exception): Take a const
reference.
* python/py-inferior.c (infpy_write_memory, infpy_search_memory):
Use std::move.
* python/py-breakpoint.c (bppy_set_condition, bppy_set_commands):
Use std::move.
* mi/mi-main.c (mi_print_exception): Take a const reference.
* main.c (handle_command_errors): Take a const reference.
* linespec.c (parse_linespec): Use std::move.
* infcall.c (run_inferior_call): Use std::move.
(call_function_by_hand_dummy): Use std::move.
* exec.c (try_open_exec_file): Use std::move.
* exceptions.h (exception_print, exception_fprintf)
(exception_print_same): Update.
* exceptions.c (print_exception, exception_print)
(exception_fprintf, exception_print_same): Change parameters to
const reference.
* event-top.c (gdb_rl_callback_read_char_wrapper): Update.
* common/new-op.c: Use std::move.
* common/common-exceptions.h (struct gdb_exception): Add move
constructor.
(struct gdb_exception_error, struct gdb_exception_quit, struct
gdb_quit_bad_alloc): Change constructor to move constructor.
(throw_exception): Change parameter to rvalue reference.
* common/common-exceptions.c (throw_exception): Take rvalue
reference.
* cli/cli-interp.c (safe_execute_command): Use std::move.
* breakpoint.c (insert_bp_location, location_to_sals): Use
std::move.

5 years agoAvoid undefined behavior in Guile exception handling
Tom Tromey [Wed, 24 Apr 2019 12:50:01 +0000 (06:50 -0600)]
Avoid undefined behavior in Guile exception handling

The Guile code will longjmp (via scm_throw) when an object requiring
destruction is on the stack.  This is undefined behavior.

This changes this code to run any destructors in inner scopes, and to
pass a POD to gdbscm_throw_gdb_exception.

gdb/ChangeLog
2019-04-25  Tom Tromey  <tromey@adacore.com>

* guile/scm-exception.c (gdbscm_scm_from_gdb_exception)
(gdbscm_throw_gdb_exception): Take a gdbscm_gdb_exception.
* guile/scm-block.c, guile/scm-breakpoint.c, guile/scm-cmd.c,
guile/scm-disasm.c, guile/scm-frame.c, guile/scm-lazy-string.c,
guile/scm-math.c, guile/scm-param.c, guile/scm-ports.c,
guile/scm-symbol.c, guile/scm-symtab.c, guile/scm-type.c,
guile/scm-value.c: Use unpack.
* guile/guile-internal.h (gdbscm_scm_from_gdb_exception): Take a
gdbscm_gdb_exception.
(gdbscm_throw_gdb_exception): Likewise.
(struct gdbscm_gdb_exception): New.
(unpack): New function.
(gdbscm_wrap): Use unpack.

5 years agoMake SJLJ exceptions more efficient
Tom Tromey [Tue, 23 Apr 2019 13:29:49 +0000 (07:29 -0600)]
Make SJLJ exceptions more efficient

This changes the SJLJ exception handling code to be a bit more
efficient, by using rvalue references and move assignment when
possible.

Tested by the buildbot.

gdb/ChangeLog
2019-04-25  Tom Tromey  <tromey@adacore.com>

* event-top.c (gdb_rl_callback_read_char_wrapper_noexcept)
(gdb_rl_callback_handler): Use std::move.
* common/common-exceptions.h (struct gdb_exception): Add move
assignment operator.
(throw_exception_sjlj): Change "exception" to const reference.
* common/common-exceptions.c (exceptions_state_mc_catch): Update.
(throw_exception_sjlj): Change "exception" to const reference.

5 years agoRemove exception_none
Tom Tromey [Tue, 23 Apr 2019 21:31:07 +0000 (15:31 -0600)]
Remove exception_none

Now that gdb_exception has a constructor, there's no need for
exception_none.  This patch removes it.

gdb/ChangeLog
2019-04-25  Tom Tromey  <tromey@adacore.com>

* xml-support.c (gdb_xml_parser::gdb_xml_parser): Update.
* python/py-value.c (valpy_getitem, valpy_nonzero): Update.
* python/py-inferior.c (infpy_write_memory, infpy_search_memory):
Update.
* python/py-breakpoint.c (bppy_set_condition, bppy_set_commands):
Update.
* mi/mi-interp.c (mi_interp::exec): Update.
* linespec.c (parse_linespec): Update.
* infcall.c (run_inferior_call): Update.
* guile/scm-value.c (gdbscm_value_to_lazy_string): Update.
* guile/scm-symbol.c (gdbscm_lookup_symbol)
(gdbscm_lookup_global_symbol): Update.
* guile/scm-param.c (gdbscm_parameter_value): Update.
* guile/scm-frame.c (gdbscm_frame_read_register)
(gdbscm_frame_read_var): Update.
* guile/scm-breakpoint.c (gdbscm_register_breakpoint_x): Update.
* exec.c (try_open_exec_file): Update.
* event-top.c (gdb_rl_callback_read_char_wrapper_noexcept)
(gdb_rl_callback_handler): Update.
* common/common-exceptions.h (exception_none): Don't declare.
* common/common-exceptions.c (exception_none): Don't define.
(struct catcher) <exception>: Update.
* cli/cli-interp.c (safe_execute_command): Update.
* breakpoint.c (insert_bp_location, location_to_sals): Update.

5 years ago[PATCH] Support for DW_FORM_strx tag
Ali Tamur [Sat, 30 Mar 2019 02:29:24 +0000 (19:29 -0700)]
[PATCH] Support for DW_FORM_strx tag

DW_FORM_strx is the new name of DW_FORM_GNU_str_index in the Dwarf 5 standard.
This is a small step towards supporting Dwarf 5 in gdb.

5 years agoChangeLog entries for the previous commit.
Sergio Durigan Junior [Thu, 25 Apr 2019 18:26:18 +0000 (14:26 -0400)]
ChangeLog entries for the previous commit.

I forgot to include the ChangeLog entries in the commit
57e5e645010430b3d73f8c6a757d09f48dc8f8d5 ("Implement dump of mappings
with ELF headers by gcore").

5 years agoImplement dump of mappings with ELF headers by gcore
Sergio Durigan Junior [Tue, 23 Apr 2019 22:17:57 +0000 (18:17 -0400)]
Implement dump of mappings with ELF headers by gcore

This patch has a long story, but it all started back in 2015, with
commit df8411da087dc05481926f4c4a82deabc5bc3859 ("Implement support
for checking /proc/PID/coredump_filter").  The purpose of that commit
was to bring GDB's corefile generation closer to what the Linux kernel
does.  However, back then, I did not implement the full support for
the dumping of memory mappings containing ELF headers (like mappings
of DSOs or executables).  These mappings were being dumped most of
time, though, because the default value of /proc/PID/coredump_filter
is 0x33, which would cause anonymous private mappings (DSOs/executable
code mappings have this type) to be dumped.  Well, until something
happened on binutils...

A while ago, I noticed something strange was happening with one of our
local testcases on Fedora GDB: it was failing due to some strange
build-id problem.  On Fedora GDB, we (unfortunately) carry a bunch of
"local" patches, and some of these patches actually extend upstream's
build-id support in order to generate more useful information for the
user of a Fedora system (for example, when the user loads a corefile
into GDB, we detect whether the executable that generated that
corefile is present, and if it's not we issue a warning suggesting
that it should be installed, while also providing the build-id of the
executable).  A while ago, Fedora GDB stopped printing those warnings.

I wanted to investigate this right away, and spent some time trying to
determine what was going on, but other things happened and I got
sidetracked.  Meanwhile, the bug started to be noticed by some of our
users, and its priority started changing.  Then, someone on IRC also
mentioned the problem, and when I tried helping him, I noticed he
wasn't running Fedora.  Hm...  So maybe the bug was *also* present
upstream.

After "some" time investigating, and with a lot of help from Keith and
others, I was finally able to determine that yes, the bug is also
present upstream, and that even though it started with a change in ld,
it is indeed a GDB issue.

So, as I said, the problem started with binutils, more specifically
after the following commit was pushed:

  commit f6aec96dce1ddbd8961a3aa8a2925db2021719bb
  Author: H.J. Lu <hjl.tools@gmail.com>
  Date:   Tue Feb 27 11:34:20 2018 -0800

      ld: Add --enable-separate-code

This commit makes ld use "-z separate-code" by default on x86-64
machines.  What this means is that code pages and data pages are now
separated in the binary, which is confusing GDB when it tries to decide
what to dump.

BTW, Fedora 28 binutils doesn't have this code, which means that
Fedora 28 GDB doesn't have the problem.  From Fedora 29 on, binutils
was rebased and incorporated the commit above, which started causing
Fedora GDB to fail.

Anyway, the first thing I tried was to pass "-z max-page-size" and
specify a bigger page size (I saw a patch that did this and was
proposed to Linux, so I thought it might help).  Obviously, this
didn't work, because the real "problem" is that ld will always use
separate pages for code and data.  So I decided to look into how GDB
dumped the pages, and that's where I found the real issue.

What happens is that, because of "-z separate-code", the first two pages
of the ELF binary are (from /proc/PID/smaps):

  00400000-00401000 r--p 00000000 fc:01 799548                             /file
  Size:                  4 kB
  KernelPageSize:        4 kB
  MMUPageSize:           4 kB
  Rss:                   4 kB
  Pss:                   4 kB
  Shared_Clean:          0 kB
  Shared_Dirty:          0 kB
  Private_Clean:         4 kB
  Private_Dirty:         0 kB
  Referenced:            4 kB
  Anonymous:             0 kB
  LazyFree:              0 kB
  AnonHugePages:         0 kB
  ShmemPmdMapped:        0 kB
  Shared_Hugetlb:        0 kB
  Private_Hugetlb:       0 kB
  Swap:                  0 kB
  SwapPss:               0 kB
  Locked:                0 kB
  THPeligible:    0
  VmFlags: rd mr mw me dw sd
  00401000-00402000 r-xp 00001000 fc:01 799548                             /file
  Size:                  4 kB
  KernelPageSize:        4 kB
  MMUPageSize:           4 kB
  Rss:                   4 kB
  Pss:                   4 kB
  Shared_Clean:          0 kB
  Shared_Dirty:          0 kB
  Private_Clean:         0 kB
  Private_Dirty:         4 kB
  Referenced:            4 kB
  Anonymous:             4 kB
  LazyFree:              0 kB
  AnonHugePages:         0 kB
  ShmemPmdMapped:        0 kB
  Shared_Hugetlb:        0 kB
  Private_Hugetlb:       0 kB
  Swap:                  0 kB
  SwapPss:               0 kB
  Locked:                0 kB
  THPeligible:    0
  VmFlags: rd ex mr mw me dw sd

Whereas before, we had only one:

  00400000-00401000 r-xp 00000000 fc:01 798593                             /file
  Size:                  4 kB
  KernelPageSize:        4 kB
  MMUPageSize:           4 kB
  Rss:                   4 kB
  Pss:                   4 kB
  Shared_Clean:          0 kB
  Shared_Dirty:          0 kB
  Private_Clean:         0 kB
  Private_Dirty:         4 kB
  Referenced:            4 kB
  Anonymous:             4 kB
  LazyFree:              0 kB
  AnonHugePages:         0 kB
  ShmemPmdMapped:        0 kB
  Shared_Hugetlb:        0 kB
  Private_Hugetlb:       0 kB
  Swap:                  0 kB
  SwapPss:               0 kB
  Locked:                0 kB
  THPeligible:    0
  VmFlags: rd ex mr mw me dw sd

Notice how we have "Anonymous" data mapped into the page.  This will be
important.

So, the way GDB decides which pages it should dump has been revamped
by my patch in 2015, and now it takes the contents of
/proc/PID/coredump_filter into account.  The default value for Linux
is 0x33, which means:

  Dump anonymous private, anonymous shared, ELF headers and HugeTLB
  private pages.

Or:

  filter_flags filterflags = (COREFILTER_ANON_PRIVATE
      | COREFILTER_ANON_SHARED
      | COREFILTER_ELF_HEADERS
      | COREFILTER_HUGETLB_PRIVATE);

Now, it is important to keep in mind that GDB doesn't always have *all*
of the necessary information to exactly determine the type of a page, so
the whole algorithm is based on heuristics (you can take a look at
linux-tdep.c:dump_mapping_p and
linux-tdep.c:linux_find_memory_regions_full for more info).

Before the patch to make ld use "-z separate-code", the (single) page
containing data and code was being flagged as an anonymous (due to the
non-zero "Anonymous:" field) private (due to the "r-xp" permission),
which means that it was being dumped into the corefile.  That's why it
was working fine.

Now, as you can imagine, when "-z separate-code" is used, the *data*
page (which is where the ELF notes are, including the build-id one) now
doesn't have any "Anonymous:" mapping, so the heuristic is flagging it
as file-backed private, which is *not* dumped by default.

The next question I had to answer was: how come a corefile generated by
the Linux kernel was correct?  Well, the answer is that GDB, unlike
Linux, doesn't actually implement the COREFILTER_ELF_HEADERS support.
On Linux, even though the data page is also treated as a file-backed
private mapping, it is also checked to see if there are any ELF headers
in the page, and then, because we *do* have ELF headers there, it is
dumped.

So, after more time trying to think of ways to fix this, I was able to
implement an algorithm that reads the first few bytes of the memory
mapping being processed, and checks to see if the ELF magic code is
present.  This is basically what Linux does as well, except that, if
it finds the ELF magic code, it just dumps one page to the corefile,
whereas GDB will dump the whole mapping.  But I don't think that's a
big issue, to be honest.

It's also important to explain that we *only* perform the ELF magic
code check if:

  - The algorithm has decided *not* to dump the mapping so far, and;
  - The mapping is private, and;
  - The mapping's offset is zero, and;
  - The user has requested us to dump mappings with ELF headers.

IOW, we're not going to blindly check every mapping.

As for the testcase, I struggled even more trying to write it.  Since
our build-id support on upstream GDB is not very extensive, it's not
really possible to determine whether a corefile contains build-id
information or not just by using GDB.  So, after thinking a lot about
the problem, I decided to rely on an external tool, eu-unstrip, in
order to verify whether the dump was successful.  I verified the test
here on my machine, and everything seems to work as expected (i.e., it
fails without the patch, and works with the patch applied).  We are
working hard to upstream our "local" Fedora GDB patches, and we intend
to submit our build-id extension patches "soon", so hopefully we'll be
able to use GDB itself to perform this verification.

I built and regtested this on the BuildBot, and no problems were
found.

gdb/ChangeLog:
2019-04-25  Sergio Durigan Junior  <sergiodj@redhat.com>

PR corefiles/11608
PR corefiles/18187
* linux-tdep.c (dump_mapping_p): Add new parameters ADDR and
OFFSET.  Verify if current mapping contains an ELF header.
(linux_find_memory_regions_full): Adjust call to
dump_mapping_p.

gdb/testsuite/ChangeLog:
2019-04-25  Sergio Durigan Junior  <sergiodj@redhat.com>

PR corefiles/11608
PR corefiles/18187
* gdb.base/coredump-filter-build-id.exp: New file.

5 years agotestsuite: Add option to capture gdbserver debug
Alan Hayward [Fri, 12 Apr 2019 15:36:51 +0000 (16:36 +0100)]
testsuite: Add option to capture gdbserver debug

Add both board option and environment variable which enables gdbserver
debug and sends it to the file gdbserver.debug, located in the output
directory for the current test.  Document this.

Add support for the environment variable in the Makefile.

The testsuite can be run with gdbserver debug enabled in the following way:

make check GDBSERVER_DEBUG=all

Disable tspeed.exp when debugging to prevent the log file filling
many gigabytes then timing out.

gdb/testsuite/ChangeLog:

* Makefile.in: Pass through GDBSERVER_DEBUG.
        * README (Testsuite Parameters): Add GDBSERVER_DEBUG.
        (gdbserver,debug): Add board setting.
        * gdb.trace/tspeed.exp: Skip when debugging.
* lib/gdb.exp (gdbserver_debug_enabled): New procedure.
* lib/gdbserver-support.exp: Likewise