binutils-gdb.git
4 years agoMSP430: sim: Fix incorrect simulation of unsigned widening multiply
Jozef Lawrynowicz [Tue, 28 Jul 2020 09:36:10 +0000 (10:36 +0100)]
MSP430: sim: Fix incorrect simulation of unsigned widening multiply

Operand sizes used for simulation of MSP430 hardware multiply
operations are not aligned with the sizes used on the target, resulting
in the simulator storing signed operands with too much precision.

Additionally, simulation of unsigned multiplication is missing explicit
casts to prevent any implicit sign extension.

gcc.c-torture/execute/pr91450-1.c uses unsigned widening multiplication
of 32-bit operands -4 and 2, to produce a 64-bit result:
0xffff fffc * 0x2 = 0x1 ffff fff8

If -4 is stored in 64-bit precision, then the multiplication is
essentially signed and the result is -8 in 64-bit precision
(0xffff ffff ffff fffc), which is not correct.

sim/msp430/ChangeLog:

* msp430-sim.c (put_op): For unsigned multiplication, explicitly cast
operands to the unsigned type before multiplying.
* msp430-sim.h (struct msp430_cpu_state): Fix types used to store hwmult
operands.

sim/testsuite/sim/msp430/ChangeLog:

* mpyull_hwmult.s: New test.

4 years ago[gdb] Fix prop->const_val uses in gdbtypes.c
Tom de Vries [Wed, 5 Aug 2020 10:31:58 +0000 (12:31 +0200)]
[gdb] Fix prop->const_val uses in gdbtypes.c

After commit 66d6346b25 "gdb: remove TYPE_DYN_PROP_ADDR", I run into:
...
FAIL: gdb.fortran/class-allocatable-array.exp: print this%_data%b
...
(and 185 more FAILs, all for fortran test-cases).

The commit replaces "!x" by "x != 0".

Fix this by using "x == 0" instead.

Build and tested on x86_64-linux.

gdb/ChangeLog:

2020-08-05  Tom de Vries  <tdevries@suse.de>

* gdbtypes.c (type_not_allocated, type_not_associated): Use
"prop->const_val () == 0" instead of "prop->const_val () != 0".

4 years agoRevert "PR26337, Malloc size error in objdump"
Alan Modra [Wed, 5 Aug 2020 08:08:26 +0000 (17:38 +0930)]
Revert "PR26337, Malloc size error in objdump"

This reverts commit 0b97e818464a42305c8243a980a5c13967554fd9.

4 years agoPR26337, Malloc size error in objdump
Alan Modra [Wed, 5 Aug 2020 00:33:00 +0000 (10:03 +0930)]
PR26337, Malloc size error in objdump

A malloc failure triggered by a fuzzed object file isn't a real
problem unless objdump doesn't exit cleanly after the failure, which
it does.  However we have bfd_malloc_and_get_section to sanity check
size of uncompressed sections before allocating memory.  Use it.

PR 26337
* objdump.c (load_specific_debug_section): Don't malloc space for
section contents, use bfd_malloc_and_get_section.

4 years agoAutomatic date update in version.in
GDB Administrator [Wed, 5 Aug 2020 00:00:07 +0000 (00:00 +0000)]
Automatic date update in version.in

4 years agoZ8k: fix sout/soudb opcodes with direct address
Christian Groessler [Tue, 4 Aug 2020 20:29:15 +0000 (22:29 +0200)]
Z8k: fix sout/soudb opcodes with direct address

Problem found by Tadashi G. Takaoka.

2020-08-04  Christian Groessler  <chris@groessler.org>
     Tadashi G. Takaoka <tadashi.g.takaoka@gmail.com>

 * z8kgen.c (opt): Fix "sout imm16,rs" and "soutb imm16,rbs"
 opcodes (special "out" to absolute address).
 * z8k-opc.h: Regenerate.

2020-08-04  Christian Groessler  <chris@groessler.org>

 * gas/testsuite/gas/z8k/inout.d: Adapt to correct encoding of
 "sout/soutb #imm,reg"

4 years agogdb: use bool in frame code
Simon Marchi [Tue, 4 Aug 2020 18:53:10 +0000 (14:53 -0400)]
gdb: use bool in frame code

Change instances of int variables and return values used as boolean
values to use the bool type.

Shorten the comments of a few functions, because I think they go a bit
too much in implementation details, which appear out of date anyway.

Make other misc changes to the functions that are already being changed,
such as using nullptr instead of NULL, dropping `struct` keywords and
declaring variables when first used.

gdb/ChangeLog:

* frame.h (frame_id_p): Return bool.
(frame_id_artificial_p): Return bool.
(frame_id_eq): Return bool.
(has_stack_frames): Return bool.
(get_selected_frame): Fix typo in comment.
(get_frame_pc_if_available): Return bool.
(get_frame_address_in_block_if_available): Return bool.
(get_frame_func_if_available): Return bool.
(read_frame_register_unsigned): Return bool.
(get_frame_register_bytes): Return bool.
(safe_frame_unwind_memory): Return bool.
(deprecated_frame_register_read): Return bool.
(frame_unwinder_is): Return bool.
* frame.c (struct frame_info) <prev_arch::p>: Change type to
bool.
<this_id::p>: Likewise.
<prev_p>: Likewise.
(frame_stash_add): Return bool.
(get_frame_id): Use bool.
(frame_id_build_special) Use bool.
(frame_id_build_unavailable_stack): Use bool.
(frame_id_build): Use bool.
(frame_id_p): Return bool, use true/false instead of 1/0.
(frame_id_artificial_p): Likewise.
(frame_id_eq): Likewise.
(frame_id_inner): Likewise.
(get_frame_func_if_available): Likewise.
(read_frame_register_unsigned): Likewise.
(deprecated_frame_register_read): Likewise.
(get_frame_register_bytes): Likewise.
(has_stack_frames): Likewise.
(inside_main_func): Likewise.
(inside_entry_func): Likewise.
(get_frame_pc_if_available): Likewise.
(get_frame_address_in_block_if_available): Likewise.
(frame_unwinder_is): Likewise.
(safe_frame_unwind_memory): Likewise.
(frame_unwind_arch): Likewise.

Change-Id: I6121fa56739b688be79d73d087d76b268ba5a46a

4 years agogdb: change frame_info::prev_func::p type to cached_copy_status
Simon Marchi [Tue, 4 Aug 2020 18:52:44 +0000 (14:52 -0400)]
gdb: change frame_info::prev_func::p type to cached_copy_status

One might think that variable `frame_info::prev_func::p` is a simple
true/false value, but that's not the case, it can also have the value -1
to mean "unavaiable".  Change it to use the `cached_copy_status` enum,
which seems designed exactly for this purpose.

Rename to `status` to be consistent with `prev_pc::status` (and be cause
`p` means `predicate`, which implies boolean, which this is not).

gdb/ChangeLog:

* frame.c (frame_info) <prev_func> <p>: Rename to status, change
type to cached_copy_status.
(fprintf_frame): Adjust.
(get_frame_func_if_available): Adjust.
(frame_cleanup_after_sniffer): Adjust.

Change-Id: I50c6ebef6c0acb076e25c741f7f417bfd101d953

4 years agoUpdate email address in MAINTAINERS
Mark Wielaard [Tue, 4 Aug 2020 18:44:10 +0000 (20:44 +0200)]
Update email address in MAINTAINERS

gdb/ChangeLog:

* MAINTAINERS (Write After Approval): Update email address.

4 years agogdb: remove TYPE_DYN_PROP_ADDR
Simon Marchi [Tue, 4 Aug 2020 18:47:39 +0000 (14:47 -0400)]
gdb: remove TYPE_DYN_PROP_ADDR

Remove TYPE_DYN_PROP_ADDR, replacing its uses with calling
dynamic_prop::const_val directly.

gdb/ChangeLog:

* gdbtypes.h (TYPE_DYN_PROP_ADDR): Remove, replace uses with
dynamic_prop::const_val.

Change-Id: Ie99b9cd9a0627488c1c69a75e57f020d34e392af

4 years agogdb: remove TYPE_DYN_PROP_KIND
Simon Marchi [Tue, 4 Aug 2020 18:47:36 +0000 (14:47 -0400)]
gdb: remove TYPE_DYN_PROP_KIND

Replace uses with calling the dynamic_prop::kind method directly.

gdb/ChangeLog:

* gdbtypes.h (TYPE_DYN_PROP_KIND): Remove, replace uses with
dynamic_prop::kind.

Change-Id: I78a3e2890f0b3e3950e9a19ad657b976cbb9610b

4 years agogdb: remove TYPE_DYN_PROP_BATON
Simon Marchi [Tue, 4 Aug 2020 18:47:09 +0000 (14:47 -0400)]
gdb: remove TYPE_DYN_PROP_BATON

This macro is now unused.

gdb/ChangeLog:

* gdbtypes.h (TYPE_DYN_PROP_BATON): Remove.

Change-Id: I6daead794f7ecb516cc59f9e05262c894515fad3

4 years agosim: generated files for the eBPF simulator
Jose E. Marchesi [Tue, 4 Aug 2020 16:11:31 +0000 (18:11 +0200)]
sim: generated files for the eBPF simulator

This patch adds the CGEN generated files for the eBPF simulator.

sim/ChangeLog:

2020-08-04  Jose E. Marchesi  <jose.marchesi@oracle.com>
    David Faust <david.faust@oracle.com>

* bpf/arch.c: Likewise.
* bpf/arch.h: Likewise.
* bpf/cpu.c: Likewise.
* bpf/cpu.h: Likewise.
* bpf/cpuall.h: Likewise.
* bpf/decode-be.c: Likewise.
* bpf/decode-be.h: Likewise.
* bpf/decode-le.c: Likewise.
* bpf/decode-le.h: Likewise.
* bpf/defs-be.h: Likewise.
* bpf/defs-le.h: Likewise.
* bpf/sem-be.c: Likewise.
* bpf/sem-le.c: Likewise.

4 years agosim: eBPF simulator
Jose E. Marchesi [Tue, 4 Aug 2020 16:09:16 +0000 (18:09 +0200)]
sim: eBPF simulator

This patch introduces the basics of an instruction-simulator for eBPF.
The simulator is based on CGEN.

gdb/ChangeLog:

2020-08-04  Jose E. Marchesi  <jose.marchesi@oracle.com>

* configure.tgt: Set gdb_sim for bpf-*-* targets.

sim/ChangeLog:

2020-08-04  Jose E. Marchesi  <jose.marchesi@oracle.com>
    David Faust <david.faust@oracle.com>

* configure.tgt (sim_arch): Add entry for bpf-*-*.
* configure: Regenerate.
* MAINTAINERS: Add maintainer for the BPF simulator.
* bpf/Makefile.in: New file.
* bpf/bpf-helpers.c: Likewise.
* bpf/bpf-helpers.def: Likewise.
* bpf/bpf-helpers.h: Likewise.
* bpf/bpf-sim.h: Likewise.
* bpf/bpf.c: Likewise.
* bpf/config.in: Likewise.
* bpf/configure.ac: Likewise.
* bpf/decode.h: Likewise.
* bpf/eng.h: Likewise.
* bpf/mloop.in: Likewise.
* bpf/sim-if.c: Likewise.
* bpf/sim-main.h: Likewise.
* bpf/traps.c: Likewise.
* bpf/configure: Generate.
* bpf/aclocal.m4: Likewise.

sim/testsuite/ChangeLog:

2020-08-04  David Faust  <david.faust@oracle.com>
    Jose E. Marchesi  <jose.marchesi@oracle.com>

* configure: Regenerate.
* sim/bpf/allinsn.exp: New file.
* sim/bpf/alu.s: Likewise.
* sim/bpf/alu32.s: Likewise.
* sim/bpf/endbe.s: Likewise.
* sim/bpf/endle.s: Likewise.
* sim/bpf/jmp.s: Likewise.
* sim/bpf/jmp32.s: Likewise.
* sim/bpf/ldabs.s: Likewise.
* sim/bpf/mem.s: Likewise.
* sim/bpf/mov.s: Likewise.
* sim/bpf/testutils.inc: Likewise.
* sim/bpf/xadd.s: Likewise.

4 years agogdb: support for eBPF
Jose E. Marchesi [Tue, 4 Aug 2020 16:01:55 +0000 (18:01 +0200)]
gdb: support for eBPF

This patch adds basic support for the eBPF target: tdep and build
machinery.  The accompanying simulator is introduced in subsequent
patches.

gdb/ChangeLog:

2020-08-04  Weimin Pan <weimin.pan@oracle.com>
    Jose E. Marchesi  <jose.marchesi@oracle.com>

* configure.tgt: Add entry for bpf-*-*.
* Makefile.in (ALL_TARGET_OBS): Add bpf-tdep.o
(ALLDEPFILES): Add bpf-tdep.c.
* bpf-tdep.c: New file.
* MAINTAINERS: Add bpf target and maintainer.

gdb/doc/ChangeLog:

2020-08-04  Jose E. Marchesi  <jose.marchesi@oracle.com>

* gdb.texinfo (Contributors): Add information for the eBPF
support.
(BPF): New section.

4 years agogdb/testsuite: Use 'array unset' instead of just 'unset'
Andrew Burgess [Tue, 4 Aug 2020 11:13:37 +0000 (12:13 +0100)]
gdb/testsuite: Use 'array unset' instead of just 'unset'

In the check-test-names.exp library 'unset' was being used to unset an
array variable.  Though this seems to work fine on tcl 8.6, it was
discovered on a CentOS 7.8.2003 machine, running tcl 8.5, that this
doesn't work and 'array unset' should be used instead.

Using 'array unset' should work fine for newer and older versions of
tcl (since 8.3, releases ~2000).

gdb/testsuite/ChangeLog:

* lib/check-test-names.exp (do_reset_vars): Use 'array unset' to
unset the array variable.

4 years agogas/NEWS: Mention {disp16} pseudo prefix
H.J. Lu [Tue, 4 Aug 2020 12:55:31 +0000 (05:55 -0700)]
gas/NEWS: Mention {disp16} pseudo prefix

* NEWS: Mention {disp16} pseudo prefix.

4 years agogas: Revert an accidental change in x86-64-pseudos.d
H.J. Lu [Tue, 4 Aug 2020 12:50:12 +0000 (05:50 -0700)]
gas: Revert an accidental change in x86-64-pseudos.d

Revert an accidental change in

commit 41eb8e88859b297f59f4d093aab9306d4b7057d9
Author: H.J. Lu <hjl.tools@gmail.com>
Date:   Thu Jul 30 16:13:02 2020 -0700

    x86: Add {disp16} pseudo prefix

@@ -304,7 +308,7 @@ Disassembly of section .text:
  +[a-f0-9]+:  40 d3 e0                rex shl %cl,%eax
  +[a-f0-9]+:  40 a0 01 00 00 00 00 00 00 00    rex movabs 0x1,%al
  +[a-f0-9]+:  40 38 ca                rex cmp %cl,%dl
- +[a-f0-9]+:  40 b3 01                rex mov \$(0x)?1,%bl
+ +[a-f0-9]+:  40 b3 01                rex mov \$(0x)1,%bl
  +[a-f0-9]+:  f2 40 0f 38 f0 c1       rex crc32 %cl,%eax
  +[a-f0-9]+:  40 89 c3                rex mov %eax,%ebx
  +[a-f0-9]+:  41 89 c6                mov    %eax,%r14d

PR gas/26305
* testsuite/gas/i386/x86-64-pseudos.d: Revert an accidental
change.

4 years agogas: Use udata for DW_AT_high_pc when emitting DWARF4
Mark Wielaard [Mon, 3 Aug 2020 20:02:24 +0000 (22:02 +0200)]
gas: Use udata for DW_AT_high_pc when emitting DWARF4

For DWARF4 DW_AT_high_pc can be expressed as constant offset from
DW_AT_low_pc which saves a relocation. Use DW_FORM_udate (uleb128)
to keep the constant value as small as possible.

gas/ChangeLog:

       * dwarf2dbg.c (out_debug_abbrev): When DWARF2_VERSION >= 4, use
       DW_FORM_udata for DW_AT_high_pc.
       (out_debug_info): Use emit_leb128_expr for DW_AT_high_pc, when
       DWARF2_VERSION >= 4.
       * read.c (emit_leb128_exp): No longer static.
       * read.h (emit_leb128_exp): Define.

4 years agogas: Make sure .debug_line file table contains a zero filename and dir
Mark Wielaard [Mon, 3 Aug 2020 00:23:44 +0000 (02:23 +0200)]
gas: Make sure .debug_line file table contains a zero filename and dir

For DWARF5 the zero file list entry in the .debug_line table represents
the compile unit main file. It can be set with .file 0 when -gdwarf-5
is given. But since this directive is illegal for older versions, this
is almost never set. To make sure it is always set (so DW_AT_name of
the compile unit can be set) use file (and dir) 1 if that is defined
(otherwise fall back to pwd, to match DW_AT_comp_dir).

gas/ChangeLog:

* gas/dwarf2dbg.c (out_dir_and_file_list): For DWARF5 emit at
least one directory if there is at least one file. Use dirs[1]
if dirs[0] is not set, or if there is no dirs[1] the current
working directory. Use files[1] filename, when files[0] filename
isn't set.

4 years agogas: Fix .debug_info CU header for --gdwarf-5
Mark Wielaard [Mon, 3 Aug 2020 00:04:17 +0000 (02:04 +0200)]
gas: Fix .debug_info CU header for --gdwarf-5

DWARF5 CU headers have a new unit type field and move the abbrev offset
to the end of the header.

gas/ChangeLog:

* dwarf2dbg.c (out_debug_info): Emit unit type and abbrev offset
for DWARF5.
* gas/testsuite/gas/elf/dwarf-4-cu.d: New file.
* gas/testsuite/gas/elf/dwarf-4-cu.s: Likewise.
* gas/testsuite/gas/elf/dwarf-5-cu.d: Likewise.
* gas/testsuite/gas/elf/dwarf-5-cu.s: Likewise.
* testsuite/gas/elf/elf.exp: Run dwarf-4-cu and dwarf-5-cu.

4 years agogas: Fix as.texi typo infortmation
Mark Wielaard [Sun, 2 Aug 2020 16:55:52 +0000 (18:55 +0200)]
gas: Fix as.texi typo infortmation

gas/ChangeLog:

* doc/as.texi (--gdwarf-[345]): Fix typo.

4 years ago[gdb/symtab] Handle invalid partial DIE reference
Tom de Vries [Tue, 4 Aug 2020 09:16:37 +0000 (11:16 +0200)]
[gdb/symtab] Handle invalid partial DIE reference

When reverting commit 9cfd2b89bd "[gdb/testsuite] Fix
gdb.arch/amd64-entry-value-paramref.S", we run into an internal-error:
...
(gdb) file amd64-entry-value-paramref^M
Reading symbols from amd64-entry-value-paramref...^M
src/gdb/dwarf2/read.c:18903: internal-error: could not find partial DIE
  0x1b7 in cache [from module amd64-entry-value-paramref]^M

A problem internal to GDB has been detected,^M
further debugging may prove unreliable.^M
...
because of invalid dwarf.

In contrast, when using -readnow, we have:
...
(gdb) file -readnow amd64-entry-value-paramref
Reading symbols from amd64-entry-value-paramref...
Expanding full symbols from amd64-entry-value-paramref...
Dwarf Error: Cannot find DIE at 0x1b7 referenced from DIE at 0x11a \
  [in module amd64-entry-value-paramref]
(gdb)
...

Change the internal error into a Dwarf Error, such that we have:
...
(gdb) file amd64-entry-value-paramref^M
Reading symbols from amd64-entry-value-paramref...^M
Dwarf Error: Cannot not find DIE at 0x1b7 \
  [from module amd64-entry-value-paramref]^M
^M
(No debugging symbols found in amd64-entry-value-paramref)^M
(gdb)
...

Build and tested on x86_64-linux.

gdb/ChangeLog:

2020-08-04  Tom de Vries  <tdevries@suse.de>

PR symtab/23270
* dwarf2/read.c (find_partial_die): Change internal error into Dwarf
Error.

4 years agoAutomatic date update in version.in
GDB Administrator [Tue, 4 Aug 2020 00:00:06 +0000 (00:00 +0000)]
Automatic date update in version.in

4 years agoUpdate FreeBSD system calls for 13.0-CURRENT.
John Baldwin [Mon, 3 Aug 2020 16:47:17 +0000 (09:47 -0700)]
Update FreeBSD system calls for 13.0-CURRENT.

This matches the current set of system calls in the FreeBSD head
development branch as of r363367.  Some of these system calls
were also included in 12.1 release.

gdb/ChangeLog:

* syscalls/freebsd.xml: Regenerate.

4 years agoFix script name in usage and generated year range.
John Baldwin [Mon, 3 Aug 2020 16:47:17 +0000 (09:47 -0700)]
Fix script name in usage and generated year range.

gdb/ChangeLog:

* syscalls/update-freebsd.sh: Fix usage and year range.

4 years agoMSP430: Remove unused -md GAS option
Jozef Lawrynowicz [Mon, 3 Aug 2020 14:04:58 +0000 (15:04 +0100)]
MSP430: Remove unused -md GAS option

The MSP430 GAS option "-md" is supposed to indicate that the CRT startup
code should copy data from ROM to RAM at startup. However, this option
has no effect; GAS handles the related behaviour automatically by
looking for the presence of certain symbols in the input file.

gas/ChangeLog:

* config/tc-msp430.c (OPTION_MOVE_DATA): Remove.
(md_parse_option): Remove case for OPTION_MOVE_DATA.
(md_longopts): Remove "md" entry.
(md_show_usage): Likewise.

4 years ago[gdb/symtab] Ignore DW_LNE_lo_user/DW_LNE_hi_user range
Tom de Vries [Mon, 3 Aug 2020 14:59:20 +0000 (16:59 +0200)]
[gdb/symtab] Ignore DW_LNE_lo_user/DW_LNE_hi_user range

When reading an exec with a .debug_line section containing a vendor-specific
extended opcode, we get:
...
$ gdb -batch -iex "set complaints 10" dw2-vendor-extended-opcode
During symbol reading: mangled .debug_line section
...
and reading of the .debug_line section is abandoned.

The vendor-specific extended opcode should be ignored, as specified in the
DWARF standard (7.1 Vendor Extensibility).  [ FWIW, vendor-specific
standard opcodes are already ignored. ]

Fix this by ignoring all vendor-specific extended opcodes.

Build and tested on x86_64-linux.

gdb/ChangeLog:

2020-08-03  Tom de Vries  <tdevries@suse.de>

PR symtab/26333
* dwarf2/read.c (dwarf_decode_lines_1): Ignore
DW_LNE_lo_user/DW_LNE_hi_user range.

gdb/testsuite/ChangeLog:

2020-08-03  Tom de Vries  <tdevries@suse.de>

PR symtab/26333
* lib/dwarf.exp (DW_LNE_user): New proc.
* gdb.dwarf2/dw2-vendor-extended-opcode.c: New test.
* gdb.dwarf2/dw2-vendor-extended-opcode.exp: New file.

4 years agoasan: alpha-vms: buffer overflow in vms_traverse_index
Alan Modra [Mon, 3 Aug 2020 13:44:57 +0000 (23:14 +0930)]
asan: alpha-vms: buffer overflow in vms_traverse_index

* vms-lib.c (vms_traverse_index): Sanity check size remaining
before accessing vms_idx or vms_elfidx.

4 years agoPR26330, Malloc size error in objdump
Alan Modra [Mon, 3 Aug 2020 01:31:27 +0000 (11:01 +0930)]
PR26330, Malloc size error in objdump

PR 26330
* elf.c (_bfd_elf_get_symtab_upper_bound): Sanity check symbol table
size against file size.  Correct LONG_MAX limit check.
(_bfd_elf_get_dynamic_symtab_upper_bound): Likewise.
(_bfd_elf_get_reloc_upper_bound): Don't check file size if writing.
(_bfd_elf_get_dynamic_reloc_upper_bound): Likewise.
* elf64-x86-64-.c (elf_x86_64_get_synthetic_symtab): Use
bfd_malloc_and_get_section.

4 years agoUse xmalloc rather than malloc
Alan Modra [Mon, 3 Aug 2020 01:29:38 +0000 (10:59 +0930)]
Use xmalloc rather than malloc

As far as I can tell, the following comment is false nowadays.
/* Calls to m-alloc get turned by sed into xm-alloc.  */

Remove it, and call xmalloc.

* ldlex.l (yy_create_string_buffer): Use xmalloc rather than malloc.
* lexsup.c (parse_args): Likewise.

4 years agoPR26328, Compilation warning when building ld v2.35 with MinGW
Alan Modra [Mon, 3 Aug 2020 01:28:11 +0000 (10:58 +0930)]
PR26328, Compilation warning when building ld v2.35 with MinGW

PR 26328
* configure.ac: AC_CHECK_DECLS asprintf.
* configure: Regenerate.
* config.in: Regenerate.

4 years agoTidy objdump_symstuff and objdump_dynsymstuff
Alan Modra [Mon, 3 Aug 2020 01:27:09 +0000 (10:57 +0930)]
Tidy objdump_symstuff and objdump_dynsymstuff

* testsuite/ld-elfvers/vers.exp (objdump_symstuff): Remove unused
variable.  Init list_a and list_b to empty.
(objdump_dynsymstuff): Likewise, and remove undefined list_a
handling.
* testsuite/ld-elfweak/elfweak.exp (objdump_symstuff): Similarly.
(objdump_dynsymstuff): Similarly.

4 years agoAutomatic date update in version.in
GDB Administrator [Mon, 3 Aug 2020 00:00:07 +0000 (00:00 +0000)]
Automatic date update in version.in

4 years agoAutomatic date update in version.in
GDB Administrator [Sun, 2 Aug 2020 00:00:06 +0000 (00:00 +0000)]
Automatic date update in version.in

4 years agoAutomatic date update in version.in
GDB Administrator [Sat, 1 Aug 2020 00:00:07 +0000 (00:00 +0000)]
Automatic date update in version.in

4 years agogdb.base/coremaker2.c: Fix compilation problems for x86_64 -m32 multilib
Kevin Buettner [Fri, 31 Jul 2020 03:51:40 +0000 (20:51 -0700)]
gdb.base/coremaker2.c: Fix compilation problems for x86_64 -m32 multilib

There are compilation warnings / errors when compiling coremaker2.c
for the gdb.base/corefile2.exp tests.  Here's the command to use
on x86_64 linux:

make check RUNTESTFLAGS="--target_board unix/-m32" \
           TESTS="gdb.base/corefile2.exp"

These are the warnings / errors - I've shortened the paths somewhat:

gdb compile failed, gdb/testsuite/gdb.base/coremaker2.c: In function 'main':
gdb/testsuite/gdb.base/coremaker2.c:106:11: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
  106 |   addr = ((unsigned long long) buf_ro + pagesize) & ~(pagesize - 1);
      |           ^
gdb/testsuite/gdb.base/coremaker2.c:108:15: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
  108 |   if (addr <= (unsigned long long) buf_ro
      |               ^
gdb/testsuite/gdb.base/coremaker2.c:109:18: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
  109 |       || addr >= (unsigned long long) buf_ro + sizeof (buf_ro))
      |                  ^
gdb/testsuite/gdb.base/coremaker2.c:115:19: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
  115 |   mbuf_ro = mmap ((void *) addr, pagesize, PROT_READ,
      |                   ^
gdb/testsuite/gdb.base/coremaker2.c:130:11: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
  130 |   addr = ((unsigned long long) buf_rw + pagesize) & ~(pagesize - 1);
      |           ^
gdb/testsuite/gdb.base/coremaker2.c:132:15: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
  132 |   if (addr <= (unsigned long long) buf_rw
      |               ^
gdb/testsuite/gdb.base/coremaker2.c:133:18: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
  133 |       || addr >= (unsigned long long) buf_rw + sizeof (buf_rw))
      |                  ^
gdb/testsuite/gdb.base/coremaker2.c:139:19: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
  139 |   mbuf_rw = mmap ((void *) addr, pagesize, PROT_READ,
      |                   ^

These were fixed by changing unsigned long long to uintptr_t.

Tested on either rawhide or Fedora 32 with architectures: x86_64,
x86_64/-m32, aarch64, s390x, and ppc64le.

gdb/testsuite/ChangeLog:

* gdb.base/coremaker2.c: Change all uses of 'unsigned long long'
to 'uintptr_t'
(inttypes.h): Include.

4 years agoFix gdb.base/corefile2.exp test case for ppc64le
Kevin Buettner [Fri, 31 Jul 2020 03:09:05 +0000 (20:09 -0700)]
Fix gdb.base/corefile2.exp test case for ppc64le

It turns out that the recently added gdb.base/corefile2.exp test won't
run on ppc64le linux.  The test case fails the internal checks which
ensure that a mmap'd region can be placed within the statically
allocated regions buf_rw[] and buf_ro[].

ppc64le linux apparently has 64k pages, which is much larger than
the 24k regions originally allocated for buf_rw[] and buf_ro[].

This patch increases the size of each region to 256 KiB.

Tested on either rawhide or Fedora 32 for these architectures: x86_64,
x86_64/-m32, ppc64le, aarch64, and s390x.

gdb/testsuite/ChangeLog:

* gdb.base/coremaker2.c (buf_rw): Increase size to 256 KiB.
(C5_24k): Delete.
(C5_8k, C5_64k, C5_256k): New macros.
(buf_ro): Allocate 256 KiB of initialized data.

4 years agold: Add -fno-lto to linker tests
H.J. Lu [Fri, 31 Jul 2020 14:40:27 +0000 (07:40 -0700)]
ld: Add -fno-lto to linker tests

LTO can be used to build binutils with

$ CC="gcc -flto -ffat-lto-objects -Wl,--as-needed" CXX="g++ -flto -ffat-lto-objects -Wl,--as-needed" .../configure

But not all linker tests are compatible with LTO.  Pass -fno-lto to CC
to disable LTO on linker tests by default.  -flto is passed explicitly
to CC in linker LTO tests.

* testsuite/ld-elf/indirect.exp: Append -fno-lto to CC.
* testsuite/ld-elfvers/vers.exp: Likewise.
* testsuite/ld-elfweak/elfweak.exp: Likewise.
* testsuite/ld-ifunc/ifunc.exp: Likewise.
* testsuite/ld-plugin/lto.exp (no_lto): New.
Add $no_lto to build pr15146c.so.
* testsuite/lib/ld-lib.exp (at_least_gcc_version): Filter out
-Wl,xxx options.
(check_gcc_plugin_enabled): Likewise.
(run_ld_link_exec_tests): Prepend -fno-lto to $cflags.
(run_cc_link_tests): Likewise.

4 years agoPR26314, Linking LTO objects with symbols from static and shared libraries
Alan Modra [Fri, 31 Jul 2020 07:07:17 +0000 (16:37 +0930)]
PR26314, Linking LTO objects with symbols from static and shared libraries

gcc -O2 -g -o ar -Wl,--as-needed arparse.o arlex.o ar.o not-ranlib.o arsup.o rename.o binemul.o emul_vanilla.o bucomm.o version.o filemode.o libbfd-2.35-3.fc33.so libiberty.a -Wl,-R,.

All of the above .o files are lto, leading to libbfd-2.35-3.fc33.so
not being found needed when loading the IR objects.  That's problem
number one:  We exclude IR references when deciding a shared library
is needed.  See PR15146.  Thus none of the libbfd.so symbols are
loaded before libiberty.a is scanned, and libbfd.so contains copies of
libiberty.a functions.  We ought to be using the libbfd.so copies
rather than extracting them from the archive (an object is extracted
even to satisfy IR symbols).  After lto recompilation, libbfd.so is of
course found to be needed and loaded.  But that causes more problems.
The lto recompilation didn't see symbol references from libbfd.so and
variables like _xexit_cleanup are made local in the recompiled
objects.  Oops, two copies of them.  Finally, those silly undefined
symbols in the lto output debug files, combined with definitions in
both libbfd.so and IR objects result in IR symbols being made
dynamic.

The main fix here is to revert the PR15146 change to
elf_link_add_object_symbols.

PR 26314
* elflink.c (bfd_elf_link_record_dynamic_symbol): Don't allow
IR symbols to become dynamic.
(elf_link_add_object_symbols): Don't exclude IR symbols when
deciding whether an as-needed shared library is needed.

4 years agoARC: Fix ld/pr24511 test
Shahab Vahedi [Thu, 30 Jul 2020 16:40:41 +0000 (18:40 +0200)]
ARC: Fix ld/pr24511 test

With this patch, ld/pr24511 test passes for ARC.

At first glance, the test was failing because the order of
"__init_array_start" and "__fini_array_start" weak symbols were
reversed:

$ nm -n dump.out

      expected output          |          real output
00002104 D __init_array_start  |  00002104 D __fini_array_start
0000210c D __fini_array_start  |  00002104 D __init_array_start

The order of the symbols are different as a side effect of both
symbols being mapped to the _same_ address (0x2104).  Looking
further into the mapping logs [1] revealed that the linker
script must consider all instances of ".init_array" (in other
words ".init_array.*") inside its relevant section. Same logic
holds for ".fini_array".

Therefore, adding "KEEP (*(SORT(.init_array.*)))" to the linker
script, along with the one for ".finit_array.*", resolved the
problem.  While at it, I took the liberty of refactoring the
script a little bit and made those pieces of script macros.

[1] Linker's mapping for the relevant part of the test
---------------------------------------------------------------
.init_array     0x2104        0x0
                0x2104        PROVIDE (__init_array_start = .)
 *(.init_array)
                [!provide]    PROVIDE (__init_array_end = .)

.fini_array     0x2104        0x0
                0x2104        PROVIDE (__fini_array_start = .)
 *(.fini_array)
                [!provide]    PROVIDE (__fini_array_end = .)

.data           0x2104        0x0
 *(.data .data.* .gnu.linkonce.d.*)
 .data          0x2104        0x0 pr24511.o

.init_array.01000
                0x2104        0x8
 .init_array.01000
                0x2104        0x8 pr24511.o

.fini_array.01000
                0x210c        0x8
 .fini_array.01000
                0x210c        0x8 pr24511.o
---------------------------------------------------------------

ld:
* scripttempl/elfarc.sc (.init_array): Keep ".init_array.*".
  (.fini_array): Keep ".fini_array.*".

Signed-off-by: Claudiu Zissulescu <claziss@gmail.com>
4 years agoAutomatic date update in version.in
GDB Administrator [Fri, 31 Jul 2020 00:00:09 +0000 (00:00 +0000)]
Automatic date update in version.in

4 years agox86: Add {disp16} pseudo prefix
H.J. Lu [Thu, 30 Jul 2020 23:13:02 +0000 (16:13 -0700)]
x86: Add {disp16} pseudo prefix

Use Prefix_XXX for pseudo prefixes.  Add {disp16} pseudo prefix and
replace {disp32} pseudo prefix with {disp16} in 16-bit mode test.
Check invalid {disp16}/{disp32} pseudo prefixes.

gas/

PR gas/26305
* config/tc-i386.c (_i386_insn::disp_encoding): Add
disp_encoding_16bit.
(parse_insn): Check Prefix_XXX for pseudo prefixes.  Handle
{disp16}.
(build_modrm_byte): Handle {disp16}.
(i386_index_check): Check invalid {disp16} and {disp32} pseudo
prefixes.
* doc/c-i386.texi: Update {disp32} documentation and document
{disp16}.
* testsuite/gas/i386/i386.exp: Run x86-64-inval-pseudo.
* testsuite/gas/i386/inval-pseudo.s: Add {disp32}/{disp16}
tests.
* testsuite/gas/i386/pseudos.s: Add {disp8}/{disp32} vmovaps
tests with 128-byte displacement.  Add {disp16} tests.
* testsuite/gas/i386/x86-64-pseudos.s: Add {disp8}/{disp32}
vmovaps test.  Add (%r13)/(%r13d) tests.
* testsuite/gas/i386/x86-64-inval-pseudo.l: New file.
* testsuite/gas/i386/x86-64-inval-pseudo.s: Likewise.
* testsuite/gas/i386/inval-pseudo.l: Updated.
* testsuite/gas/i386/pseudos.d: Likewise.
* testsuite/gas/i386/x86-64-pseudos.d: Likewise.

opcodes/

PR gas/26305
* i386-opc.h (Prefix_Disp8): New.
(Prefix_Disp16): Likewise.
(Prefix_Disp32): Likewise.
(Prefix_Load): Likewise.
(Prefix_Store): Likewise.
(Prefix_VEX): Likewise.
(Prefix_VEX3): Likewise.
(Prefix_EVEX): Likewise.
(Prefix_REX): Likewise.
(Prefix_NoOptimize): Likewise.
* i386-opc.tbl: Use Prefix_XXX on pseudo prefixes.  Add {disp16}.
* i386-tbl.h: Regenerated.

4 years agogdb: handle non-const property types in ada_modulus (PR ada/26318)
Simon Marchi [Thu, 30 Jul 2020 18:56:08 +0000 (14:56 -0400)]
gdb: handle non-const property types in ada_modulus (PR ada/26318)

PR 26318 shows that running `maint print symbols` on an Ada binary,
compiled with an Ada distribution that includes debug info for the
standard library, triggers this assertion:

    /home/simark/src/binutils-gdb/gdb/gdbtypes.h:526: internal-error: LONGEST dynamic_prop::const_val() const: Assertion `m_kind == PROP_CONST' failed.

The problem is in particular when printing type
`system__object_reader__decoded_ada_name__TTdecodedSP1___XDL_0`, which
has a dynamic high bound (PROP_LOCLIST kind).  When printing a concrete
value of this type, this type gets resolved to a type with a constant
high bound, so ada_modulus can return this constant value.

However, when printing the dynamic range type on its own, such as with
`maint print symbols`, the high bound is still of kind PROP_LOCLIST.
When ada_modulus tries to access the property as a const value, the
assert triggers.

There's no sensible numerical value to return in this case.  Ideally,
ada_modulus would return something to the caller indicating that the
value is dynamic and therefore can't be returned as an integer.  The
callers would handle it, for example `maint print symbols` would say
that the high bound of the type is dynamic.

However, this patch implements the simpler fix of returning 0 in that
case.  It kind of restores the previous behavior of before we validated
the dynamic property kind in the getters, where we would just return
whatever random integer value was in `const_val`.  Except now it's
consistently 0.

This is what we had before we added dynamic property getters:

$ ./gdb -q ~/foo -ex "maint expand-symtabs" -ex "maint print symbols" -batch | grep 'typedef <system__object_reader__decoded_ada_name__TTdecodedSP1'
     typedef <system__object_reader__decoded_ada_name__TTdecodedSP1: mod 107820865988257;

and this is what we have now:

$ ./gdb -q ~/foo -ex "maint expand-symtabs" -ex "maint print symbols" -batch | grep 'typedef <system__object_reader__decoded_ada_name__TTdecodedSP1'
     typedef <system__object_reader__decoded_ada_name__TTdecodedSP1: mod 0;

The value 107820865988257 is the `baton` field of the property's union
interpreted as an integer, so a bogus value.

gdb/ChangeLog:

PR ada/26318
* ada-lang.c (ada_modulus): Return 0 if property is not of const
kind.

Change-Id: I3f6d343a9c3cd7cd62a4fc591943a43541223d50

4 years agogdb/breakpoint: refactor 'set_breakpoint_condition'
Tankut Baris Aktemur [Thu, 30 Jul 2020 17:23:38 +0000 (19:23 +0200)]
gdb/breakpoint: refactor 'set_breakpoint_condition'

Apply minor refactoring to 'set_breakpoint_condition'.

gdb/ChangeLog:
2020-07-30  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

* breakpoint.c (set_breakpoint_condition): Do minor refactoring.

4 years agogdb/breakpoint: set the condition exp after parsing the condition successfully
Tankut Baris Aktemur [Thu, 30 Jul 2020 17:23:38 +0000 (19:23 +0200)]
gdb/breakpoint: set the condition exp after parsing the condition successfully

In 'set_breakpoint_condition', GDB resets the condition expressions
before parsing the condition input by the user.  This leads to the
problem of losing the condition expressions if the new condition
does not parse successfully and is thus rejected.

For instance:

  $ gdb ./test
  Reading symbols from ./test...
  (gdb) start
  Temporary breakpoint 1 at 0x114e: file test.c, line 4.
  Starting program: test

  Temporary breakpoint 1, main () at test.c:4
  4         int a = 10;
  (gdb) break 5
  Breakpoint 2 at 0x555555555155: file test.c, line 5.

Now define a condition that would evaluate to false.  Next, attempt
to overwrite that with an invalid condition:

  (gdb) cond 2 a == 999
  (gdb) cond 2 gibberish
  No symbol "gibberish" in current context.
  (gdb) info breakpoints
  Num     Type           Disp Enb Address            What
  2       breakpoint     keep y   0x0000555555555155 in main at test.c:5
          stop only if a == 999

It appears as if the bad condition is successfully rejected.  But if we
resume the program, we see that we hit the breakpoint although the condition
would evaluate to false.

  (gdb) continue
  Continuing.

  Breakpoint 2, main () at test.c:5
  5         a = a + 1; /* break-here */

Fix the problem by not resetting the condition expressions before
parsing the condition input.

Suppose the fix is applied.  A similar problem could occur if the
condition is valid, but has "junk" at the end.  In this case, parsing
succeeds, but an error is raised immediately after.  It is too late,
though; the condition expression is already updated.

For instance:

  $ gdb ./test
  Reading symbols from ./test...
  (gdb) start
  Temporary breakpoint 1 at 0x114e: file test.c, line 4.
  Starting program: test

  Temporary breakpoint 1, main () at test.c:4
  4         int a = 10;
  (gdb) break 5
  Breakpoint 2 at 0x555555555155: file test.c, line 5.
  (gdb) cond 2 a == 999
  (gdb) cond 2 a == 10 if
  Junk at end of expression
  (gdb) info breakpoints
  Num     Type           Disp Enb Address            What
  2       breakpoint     keep y   0x0000555555555155 in main at test.c:5
          stop only if a == 999
  (gdb) c
  Continuing.

  Breakpoint 2, main () at test.c:5
  5         a = a + 1; /* break-here */
  (gdb)

We should not have hit the breakpoint because the condition would
evaluate to false.

Fix this problem by updating the condition expression of the breakpoint
after parsing the input successfully and checking that there is no
remaining junk.

gdb/ChangeLog:
2020-07-30  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

* breakpoint.c (set_breakpoint_condition): Update the condition
expressions after checking that the input condition string parses
successfully and does not contain junk at the end.

gdb/testsuite/ChangeLog:
2020-07-30  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

* gdb.base/condbreak-bad.exp: Extend the test with scenarios
that attempt to overwrite an existing condition with a condition
that fails parsing and also with a condition that parses fine
but contains junk at the end.

4 years agogdb/breakpoint: do not update the condition string if parsing the condition fails
Tankut Baris Aktemur [Thu, 30 Jul 2020 17:23:38 +0000 (19:23 +0200)]
gdb/breakpoint: do not update the condition string if parsing the condition fails

The condition of a breakpoint can be set with the 'cond' command.  If
the condition has errors that make it problematic to evaluate, it
appears like GDB rejects the condition, but updates the breakpoint's
condition string, which causes incorrect/unintuitive behavior.

For instance:

  $ gdb ./test
  Reading symbols from ./test...
  (gdb) break 5
  Breakpoint 1 at 0x1155: file test.c, line 5.
  (gdb) cond 1 gibberish
  No symbol "gibberish" in current context.

At this point, it looks like the condition was rejected.
But "info breakpoints" shows the following:

  (gdb) info breakpoints
  Num     Type           Disp Enb Address            What
  1       breakpoint     keep y   0x0000000000001155 in main at test.c:5
          stop only if gibberish

Running the code gives the following behavior, where re-insertion of
the breakpoint causes failures.

  (gdb) run
  Starting program: test
  warning: failed to reevaluate condition for breakpoint 1: No symbol "gibberish" in current context.
  warning: failed to reevaluate condition for breakpoint 1: No symbol "gibberish" in current context.
  warning: failed to reevaluate condition for breakpoint 1: No symbol "gibberish" in current context.
  warning: failed to reevaluate condition for breakpoint 1: No symbol "gibberish" in current context.
  warning: failed to reevaluate condition for breakpoint 1: No symbol "gibberish" in current context.
  [Inferior 1 (process 19084) exited normally]
  (gdb)

This broken behavior occurs because GDB updates the condition string
of the breakpoint *before* checking that it parses successfully.
When parsing fails, the update has already taken place.

Fix the problem by updating the condition string *after* parsing the
condition.  We get the following behavior when this patch is applied:

  $ gdb ./test
  Reading symbols from ./test...
  (gdb) break 5
  Breakpoint 1 at 0x1155: file test.c, line 5.
  (gdb) cond 1 gibberish
  No symbol "gibberish" in current context.
  (gdb) info breakpoints
  Num     Type           Disp Enb Address            What
  1       breakpoint     keep y   0x0000000000001155 in main at test.c:5
  (gdb) run
  Starting program: test

  Breakpoint 1, main () at test.c:5
  5         a = a + 1; /* break-here */
  (gdb) c
  Continuing.
  [Inferior 1 (process 15574) exited normally]
  (gdb)

A side note: The problem does not occur if the condition is given
at the time of breakpoint definition, as in "break 5 if gibberish",
because the parsing of the condition fails during symtab-and-line
creation, before the breakpoint is created.

Finally, the code included the following comment:

  /* I don't know if it matters whether this is the string the user
     typed in or the decompiled expression.  */

This comment did not make sense to me because the condition string is
the user-typed input.  The patch updates this comment, too.

gdb/ChangeLog:
2020-07-30  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

* breakpoint.c (set_breakpoint_condition): Update the
condition string after parsing the new condition successfully.

gdb/testsuite/ChangeLog:
2020-07-30  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

* gdb.base/condbreak-bad.c: New test.
* gdb.base/condbreak-bad.exp: New file.

4 years agoaarch64: set sh_entsize of .plt to 0
Szabolcs Nagy [Wed, 29 Jul 2020 14:47:50 +0000 (15:47 +0100)]
aarch64: set sh_entsize of .plt to 0

On aarch64 the first PLT entry is 32 bytes, subsequent entries
are 16 bytes by default but can be 24 bytes with BTI or with
PAC-PLT.

sh_entsize of .plt was set to the PLT entry size, so in some
cases sh_size % sh_entsize != 0, which breaks some tools.

Note that PLT0 (and the TLSDESC stub code which is also in the
PLT) were historically not padded up to meet the sh_size
requirement, but to ensure that PLT stub code is aligned on
cache lines. Similar layout is present on other targets too
which just happens to make sh_size a multiple of sh_entsize and
it is not expected that sh_entsize of .plt is used for anything.

This patch sets sh_entsize of .plt to 0: the section does not
hold a table of fixed-size entries so other values are not
conforming in principle to the ELF spec.

bfd/ChangeLog:

PR ld/26312
* elfnn-aarch64.c (elfNN_aarch64_init_small_plt0_entry): Set sh_entsize
to 0.
(elfNN_aarch64_finish_dynamic_sections): Remove sh_entsize setting.

4 years ago[gdb/testsuite] Fix gdb.fortran/info-modules.exp with gcc-4.8
Tom de Vries [Thu, 30 Jul 2020 15:47:37 +0000 (17:47 +0200)]
[gdb/testsuite] Fix gdb.fortran/info-modules.exp with gcc-4.8

When running test-case gdb.fortran/info-modules.exp with gfortran 4.8.5, I
get:
...
FAIL: gdb.fortran/info-modules.exp: info module functions: \
  check for entry 'info-types.f90', '35', \
  'void mod1::__copy_mod1_M1t1\(Type m1t1, Type m1t1\);'
FAIL: gdb.fortran/info-modules.exp: info module functions -m mod1: \
  check for entry 'info-types.f90', '35', \
  'void mod1::__copy_mod1_M1t1\(Type m1t1, Type m1t1\);'
FAIL: gdb.fortran/info-modules.exp: info module variables: \
  check for entry 'info-types.f90', '(35)?', \
  'Type m1t1 mod1::__def_init_mod1_M1t1;'
FAIL: gdb.fortran/info-modules.exp: info module variables: \
  check for entry 'info-types.f90', '(35)?', \
  'Type __vtype_mod1_M1t1 mod1::__vtab_mod1_M1t1;'
...

With gfortran 7.5.0, we have:
...
$ readelf -wi info-modules | egrep "DW_AT_name.*(copy|def_init|vtype)_mod1"
    <286>   DW_AT_name        : __def_init_mod1_M1t1
    <29f>   DW_AT_name        : __vtype_mod1_M1t1
    <3de>   DW_AT_name        : __copy_mod1_M1t1
$
...
but with gfortran 4.8.5:
...
$ readelf -wi info-modules | egrep "DW_AT_name.*(copy|def_init|vtype)_mod1"
$
...

Fix this by allowing these module functions and variables to be missing.

Tested on x86_64-linux with gcc 4.8.5 and gcc 7.5.0.

gdb/testsuite/ChangeLog:

2020-07-30  Tom de Vries  <tdevries@suse.de>

* lib/sym-info-cmds.exp (GDBInfoModuleSymbols::check_entry_1): Factor
out of ...
(GDBInfoModuleSymbols::check_entry): ... here.
(GDBInfoModuleSymbols::check_optional_entry): New proc.
* gdb.fortran/info-modules.exp: Use check_optional_entry for entries
related to __def_init_mod1_M1t1 / __vtype_mod1_M1t1 / __copy_mod1_M1t1.

4 years agoStrange - my previous commit to as.c to set the default dwarf level to 3 seems to...
Nick Clifton [Thu, 30 Jul 2020 15:23:09 +0000 (16:23 +0100)]
Strange - my previous commit to as.c to set the default dwarf level to 3 seems to have disappeared.  So here is the commit again.

4 years agoDefault to DWARF level 3 for the assembler.
Nick Clifton [Thu, 30 Jul 2020 13:59:39 +0000 (14:59 +0100)]
Default to DWARF level 3 for the assembler.

* as.c (dwarf_level): Initialise to 3 in case this is not set on
the command line.

4 years agoUnify Solaris procfs and largefile handling
Rainer Orth [Thu, 30 Jul 2020 13:41:50 +0000 (15:41 +0200)]
Unify Solaris procfs and largefile handling

GDB currently doesn't build on 32-bit Solaris:

* On Solaris 11.4/x86:

In file included from /usr/include/sys/procfs.h:26,
                 from /vol/src/gnu/gdb/hg/master/dist/gdb/i386-sol2-nat.c:24:
/usr/include/sys/old_procfs.h:31:2: error: #error "Cannot use procfs in the large file compilation environment"
 #error "Cannot use procfs in the large file compilation environment"
  ^~~~~

* On Solaris 11.3/x86 there are several more instances of this.

The interaction between procfs and large-file support historically has
been a royal mess on Solaris:

* There are two versions of the procfs interface:

** The old ioctl-based /proc, deprecated and not used any longer in
   either gdb or binutils.

** The `new' (introduced in Solaris 2.6, 1997) structured /proc.

* There are two headers one can possibly include:

** <procfs.h> which only provides the structured /proc, definining
   _STRUCTURED_PROC=1 and then including ...

** <sys/procfs.h> which defaults to _STRUCTURED_PROC=0, the ioctl-based
   /proc, but provides structured /proc if _STRUCTURED_PROC == 1.

* procfs and the large-file environment didn't go well together:

** Until Solaris 11.3, <sys/procfs.h> would always #error in 32-bit
   compilations when the large-file environment was active
   (_FILE_OFFSET_BITS == 64).

** In both Solaris 11.4 and Illumos, this restriction was lifted for
   structured /proc.

So one has to be careful always to define _STRUCTURED_PROC=1 when
testing for or using <sys/procfs.h> on Solaris.  As the errors above
show, this isn't always the case in binutils-gdb right now.

Also one may need to disable large-file support for 32-bit compilations
on Solaris.  config/largefile.m4 meant to do this by wrapping the
AC_SYS_LARGEFILE autoconf macro with appropriate checks, yielding
ACX_LARGEFILE.  Unfortunately the macro doesn't always succeed because
it neglects the _STRUCTURED_PROC part.

To make things even worse, since GCC 9 g++ predefines
_FILE_OFFSET_BITS=64 on Solaris.  So even if largefile.m4 deciced not to
enable large-file support, this has no effect, breaking the gdb build.

This patch addresses all this as follows:

* All tests for the <sys/procfs.h> header are made with
  _STRUCTURED_PROC=1, the definition going into the various config.h
  files instead of having to make them (and sometimes failing) in the
  affected sources.

* To cope with the g++ predefine of _FILE_OFFSET_BITS=64,
  -U_FILE_OFFSET_BITS is added to various *_CPPFLAGS variables.  It had
  been far easier to have just

  #undef _FILE_OFFSET_BITS

  in config.h, but unfortunately such a construct in config.in is
  commented by config.status irrespective of indentation and whitespace
  if large-file support is disabled.  I found no way around this and
  putting the #undef in several global headers for bfd, binutils, ld,
  and gdb seemed way more invasive.

* Last, the applicability check in largefile.m4 was modified only to
  disable largefile support if really needed.  To do so, it checks if
  <sys/procfs.h> compiles with _FILE_OFFSET_BITS=64 defined.  If it
  doesn't, the disabling only happens if gdb exists in-tree and isn't
  disabled, otherwise (building binutils from a tarball), there's no
  conflict.

  What initially confused me was the check for $plugins here, which
  originally caused the disabling not to take place.  Since AC_PLUGINGS
  does enable plugin support if <dlfcn.h> exists (which it does on
  Solaris), the disabling never happened.

  I could find no explanation why the linker plugin needs large-file
  support but thought it would be enough if gld and GCC's lto-plugin
  agreed on the _FILE_OFFSET_BITS value.  Unfortunately, that's not
  enough: lto-plugin uses the simple-object interface from libiberty,
  which includes off_t arguments.  So to fully disable large-file
  support would mean also disabling it in libiberty and its users: gcc
  and libstdc++-v3.  This seems highly undesirable, so I decided to
  disable the linker plugin instead if large-file support won't work.

The patch allows binutils+gdb to build on i386-pc-solaris2.11 (both
Solaris 11.3 and 11.4, using GCC 9.3.0 which is the worst case due to
predefined _FILE_OFFSET_BITS=64).  Also regtested on
amd64-pc-solaris2.11 (again on Solaris 11.3 and 11.4),
x86_64-pc-linux-gnu and i686-pc-linux-gnu.

config:
* largefile.m4 (ACX_LARGEFILE) <sparc-*-solaris*|i?86-*-solaris*>:
Check for <sys/procfs.h> incompatilibity with large-file support
on Solaris.
Only disable large-file support and perhaps plugins if needed.
Set, substitute LARGEFILE_CPPFLAGS if so.

bfd:
* bfd.m4 (BFD_SYS_PROCFS_H): New macro.
(BFD_HAVE_SYS_PROCFS_TYPE): Require BFD_SYS_PROCFS_H.
Don't define _STRUCTURED_PROC.
(BFD_HAVE_SYS_PROCFS_TYPE_MEMBER): Likewise.
* elf.c [HAVE_SYS_PROCFS_H] (_STRUCTURED_PROC): Don't define.
* configure.ac: Use BFD_SYS_PROCFS_H to check for <sys/procfs.h>.
* configure, config.in: Regenerate.
* Makefile.am (AM_CPPFLAGS): Add LARGEFILE_CPPFLAGS.
* Makefile.in, doc/Makefile.in: Regenerate.

binutils:
* Makefile.am (AM_CPPFLAGS): Add LARGEFILE_CPPFLAGS.
* Makefile.in, doc/Makefile.in: Regenerate.
* configure: Regenerate.

gas:
* Makefile.am (AM_CPPFLAGS): Add LARGEFILE_CPPFLAGS.
* Makefile.in, doc/Makefile.in: Regenerate.
* configure: Regenerate.

gdb:
* proc-api.c (_STRUCTURED_PROC): Don't define.
* proc-events.c: Likewise.
* proc-flags.c: Likewise.
* proc-why.c: Likewise.
* procfs.c: Likewise.

* Makefile.in (INTERNAL_CPPFLAGS): Add LARGEFILE_CPPFLAGS.
* configure, config.in: Regenerate.

gdbserver:
* configure, config.in: Regenerate.

gdbsupport:
* Makefile.am (AM_CPPFLAGS): Add LARGEFILE_CPPFLAGS.
* common.m4 (GDB_AC_COMMON): Use BFD_SYS_PROCFS_H to check for
<sys/procfs.h>.
* Makefile.in: Regenerate.
* configure, config.in: Regenerate.

gnulib:
* configure.ac: Run ACX_LARGEFILE before gl_EARLY.
* configure: Regenerate.

gprof:
* Makefile.am (AM_CPPFLAGS): Add LARGEFILE_CPPFLAGS.
* Makefile.in: Regenerate.
* configure: Regenerate.

ld:
* Makefile.am (AM_CPPFLAGS): Add LARGEFILE_CPPFLAGS.
* Makefile.in: Regenerate.
* configure: Regenerate.

4 years agox86: Pass --gdwarf-3 to assembler
H.J. Lu [Thu, 30 Jul 2020 11:56:46 +0000 (04:56 -0700)]
x86: Pass --gdwarf-3 to assembler

Pass --gdwarf-3 to assembler for

commit 4d8ee860737005517be588f4771c358593fa421c
Author: Nick Clifton <nickc@redhat.com>
Date:   Thu Jul 30 08:39:14 2020 +0100

    Prevent the generation of DWARF level 0 line number tables...

binutils/

* testsuite/binutils-all/i386/compressed-1a.d: Pass --gdwarf-3
to assembler.
* testsuite/binutils-all/i386/compressed-1b.d: Likewise.
* testsuite/binutils-all/i386/compressed-1c.d: Likewise.
* testsuite/binutils-all/x86-64/compressed-1a.d: Likewise.
* testsuite/binutils-all/x86-64/compressed-1b.d: Likewise.
* testsuite/binutils-all/x86-64/compressed-1c.d: Likewise.

gas/

* testsuite/gas/elf/dwarf2-3.d:Pass --gdwarf-3 to assembler.
* testsuite/gas/elf/dwarf2-5.d: Likewise.
* testsuite/gas/i386/dw2-compress-3a.d: Likewise.
* testsuite/gas/i386/dw2-compress-3b.d: Likewise.
* testsuite/gas/i386/dw2-compressed-3a.d: Likewise.
* testsuite/gas/i386/dw2-compressed-3b.d: Likewise.

4 years agoelf: Add sym_cache to elf_link_hash_table
H.J. Lu [Thu, 30 Jul 2020 10:41:30 +0000 (03:41 -0700)]
elf: Add sym_cache to elf_link_hash_table

Since many ELF backends have sym_cache to their link hash tables, add
sym_cache to elf_link_hash_table.  Also use sdynbss and srelbss in
elf_link_hash_table.

* elf-bfd.h (sym_cache): Moved before elf_link_hash_table.
(elf_link_hash_table): Add sym_cache.
* elf32-arm.c (elf32_arm_link_hash_table): Remove sym_cache.
(elf32_arm_check_relocs): Updated.
(elf32_arm_size_dynamic_sections): Likewise.
* elf32-bfin.c (bfin_link_hash_table): Removed.
(bfin_link_hash_newfunc): Updated.
(bfin_hash_table): Removed.
* elf32-csky.c (csky_elf_link_hash_table): Remove sym_cache.
(csky_elf_check_relocs): Updated.
* elf32-hppa.c (elf32_hppa_link_hash_table): Remove sym_cache.
(elf32_hppa_check_relocs): Updated.
* elf32-i386.c (elf_i386_tls_transition): Updated.
(elf_i386_convert_load_reloc): Likewise.
(elf_i386_check_relocs): Likewise.
* elf32-m32r.c (elf_m32r_link_hash_table): Removed.
(m32r_elf_hash_table): Updated.
(m32r_elf_link_hash_table_create): Likewise.
(m32r_elf_create_dynamic_sections): Likewise.
(m32r_elf_adjust_dynamic_symbol): Likewise.
(allocate_dynrelocs): Likewise.
(m32r_elf_size_dynamic_sections): Likewise.
(m32r_elf_relocate_section): Likewise.
(m32r_elf_finish_dynamic_symbol): Likewise.
(m32r_elf_check_relocs): Likewise.
* elf32-m68hc1x.h (m68hc11_elf_link_hash_table): Remove
sym_cache.
* elf32-m68k.c (elf_m68k_link_hash_table): Likewise.
(elf_m68k_check_relocs): Updated.
* elf32-metag.c (elf_metag_link_hash_table): Remove sym_cache.
(elf_metag_check_relocs): Updated.
* elf32-microblaze.c (elf32_mb_link_hash_table): Remove sym_sec.
(microblaze_elf_check_relocs): Updated.
* elf32-nds32.c (nds32_elf_link_hash_table_create): Likewise.
(nds32_elf_create_dynamic_sections): Likewise.
(nds32_elf_adjust_dynamic_symbol): Likewise.
(nds32_elf_check_relocs): Likewise.
* elf32-nds32.h (elf_nds32_link_hash_table): Remove sdynbss,
srelbss and aym_cache.
* elf32-nios2.c (elf32_nios2_link_hash_table): Remove sym_cache.
(nios2_elf32_check_relocs): Updated.
* elf32-or1k.c (elf_or1k_link_hash_table): Remove sym_sec.
(or1k_elf_check_relocs): Updated.
* elf32-ppc.c (ppc_elf_check_relocs): Remove sym_cache.
(ppc_elf_check_relocs): Updated.
* elf32-s390.c (elf_s390_link_hash_table): Remove sym_cache.
(elf_s390_check_relocs): Updated.
(elf_s390_finish_dynamic_sections): Likewise.
* elf32-sh.c (elf_sh_link_hash_table): Remove sdynbss, srelbss
and aym_cache.
(sh_elf_create_dynamic_sections): Updated.
(sh_elf_adjust_dynamic_symbol): Likewise.
(sh_elf_size_dynamic_sections): Likewise.
(sh_elf_check_relocs): Likewise.
* elf32-tic6x.c (elf32_tic6x_link_hash_table): Remove sym_cache.
(elf32_tic6x_check_relocs): Updated.
* elf32-tilepro.c (tilepro_elf_link_hash_table): Removed.
(tilepro_elf_hash_table): Updated.
(tilepro_elf_link_hash_table_create): Likewise.
(tilepro_elf_check_relocs): Likewise.
(tilepro_elf_adjust_dynamic_symbol): Likewise.
(allocate_dynrelocs): Likewise.
(tilepro_elf_size_dynamic_sections): Likewise.
(tilepro_elf_relocate_section): Likewise.
(tilepro_elf_finish_dynamic_symbol): Likewise.
(tilepro_finish_dyn): Likewise.
(tilepro_elf_finish_dynamic_sections): Likewise.
* elf64-ppc.c (ppc_link_hash_table): Remove sym_cache.
(ppc64_elf_before_check_relocs): Updated.
(ppc64_elf_check_relocs): Likewise.
* elf64-s390.c (elf_s390_link_hash_table): Remove sym_cache.
(elf_s390_check_relocs): Updated.
(elf_s390_relocate_section): Likewise.
(elf_s390_finish_dynamic_sections): Likewise.
* elf64-x86-64.c (elf_x86_64_tls_transition): Likewise.
(elf_x86_64_check_relocs): Likewise.
* elfnn-aarch64.c (elf_aarch64_link_hash_table): Remove
sym_cache.
(elfNN_aarch64_check_relocs): Updated.
* elfnn-riscv.c (riscv_elf_link_hash_table): Remove sym_cache.
(riscv_elf_check_relocs): Updated.
* elfxx-mips.c (mips_elf_link_hash_table): Remove sym_cache.
(mips_elf_resolve_got_page_ref): Updated.
* elfxx-sparc.c (_bfd_sparc_elf_check_relocs): Likewise.
* elfxx-sparc.h (_bfd_sparc_elf_link_hash_table): Remove
sym_cache.
* elfxx-tilegx.c (tilegx_elf_link_hash_table): Likewise.
(tilegx_elf_check_relocs): Updated.
* elfxx-x86.h (elf_x86_link_hash_table): Remove sym_cache.

4 years ago[gdb/testsuite] Fix gdb.fortran/ptype-on-functions.exp with gcc-4.8
Tom de Vries [Thu, 30 Jul 2020 10:35:57 +0000 (12:35 +0200)]
[gdb/testsuite] Fix gdb.fortran/ptype-on-functions.exp with gcc-4.8

When running test-case gdb.fortran/ptype-on-functions.exp with gfortran 4.8.5,
we run into:
...
(gdb) ptype some_module::get_number^M
type = integer(kind=4) (Type __class_some_module_Number)^M
(gdb) FAIL: gdb.fortran/ptype-on-functions.exp: ptype some_module::get_number
ptype some_module::set_number^M
type = void (Type __class_some_module_Number, integer(kind=4))^M
(gdb) FAIL: gdb.fortran/ptype-on-functions.exp: ptype some_module::set_number
...

The test-case pattern expects a "_t" suffix on "__class_some_module_Number".

The difference is caused by a gcc commit 073afca6884 'class.c
(gfc_build_class_symbol): Append "_t" to target class names to make the
generated type names unique' which has been present since gcc 4.9.0.

Fix the pattern by optionally matching the _t suffix.

Tested on x86_64-linux, with gfortran 4.8.5 and 7.5.0.

gdb/testsuite/ChangeLog:

2020-07-30  Tom de Vries  <tdevries@suse.de>

* gdb.fortran/ptype-on-functions.exp: Make "_t" suffix on
"__class_some_module_Number_t" optional.

4 years agoPrevent the generation of DWARF level 0 line number tables...
Nick Clifton [Thu, 30 Jul 2020 07:39:14 +0000 (08:39 +0100)]
Prevent the generation of DWARF level 0 line number tables...

* as.c (dwarf_level): Initialise to 4 in case this is not set on
the command line.

4 years ago[gdb/build] Fix Wmaybe-uninitialized in gdb/ui-style.h
Tom de Vries [Thu, 30 Jul 2020 07:23:01 +0000 (09:23 +0200)]
[gdb/build] Fix Wmaybe-uninitialized in gdb/ui-style.h

When building CFLAGS/CXXFLAGS="-O2 -g -Wall" and gcc 4.8.5, we run into:
...
src/gdb/cli/cli-style.c:154:42: warning: '*((void*)&<anonymous> +8)' \
  may be used uninitialized in this function [-Wmaybe-uninitialized]
src/gdb/cli/cli-style.c:154:42: warning: '*((void*)&<anonymous> +9)' \
  may be used uninitialized in this function [-Wmaybe-uninitialized]
src/gdb/cli/cli-style.c:154:42: warning: '*((void*)&<anonymous> +10)' \
  may be used uninitialized in this function [-Wmaybe-uninitialized]
...

The root cause is that the data members of class color, nested in struct
ui_file_style in gdb/ui-style.h:
...
    bool m_simple;
    int m_value;
    uint8_t m_red, m_green, m_blue;
...
are only partially initialized by this constructor:
...
    color (int c)
      : m_simple (true),
        m_value (c)
    {
      gdb_assert (c >= -1 && c <= 255);
    }
...
but the default copy constructor will copy all the fields.

The member m_simple acts as a discriminant, to indicate which other members
are valid:
- m_value (with m_simple == true)
- m_red, m_green, m_blue (with m_simple == false)
So, we don't need storage for both m_value and m_red/m_green/m_blue at the
same time.

Fix this by wrapping the respective members in a union:
...
    bool m_simple;
    union
    {
      int m_value;
      struct
      {
       uint8_t m_red, m_green, m_blue;
      };
    };
...
which also fixes the warning.

Build and reg-tested on x86_64-linux.

gdb/ChangeLog:

2020-07-30  Tom de Vries  <tdevries@suse.de>

PR build/26320
* ui-style.h (struct ui_file_style::color): Wrap m_value and
m_red/m_green/m_blue in a union.

4 years agoAutomatic date update in version.in
GDB Administrator [Thu, 30 Jul 2020 00:00:07 +0000 (00:00 +0000)]
Automatic date update in version.in

4 years agoRun `autoreconf -vf` throughout
Simon Marchi [Wed, 29 Jul 2020 20:02:57 +0000 (16:02 -0400)]
Run `autoreconf -vf` throughout

I ran

    for i in $(find . -name configure.ac); do pushd $(dirname $i); autoreconf -vf; popd; done

to re-generate all automake/autoconf files throughout the repo (with
upstream autoconf 2.69 and automake 1.15.1).  These were the changes
that came out.  I am pushing this as obvious.

libdecnumber/ChangeLog:

* aclocal.m4, configure: Re-generate.

sim/bfin/ChangeLog:

* aclocal.m4, configure: Re-generate.

sim/erc32/ChangeLog:

* configure: Re-generate.

sim/mips/ChangeLog:

* configure: Re-generate.

sim/testsuite/ChangeLog:

* configure: Re-generate.

Change-Id: I97335c09972d25cc5f6fd8da4db4ffe4a0348787

4 years agoMIPS: Make the IRIX naming of local section symbols consistent
Maciej W. Rozycki [Wed, 29 Jul 2020 19:56:41 +0000 (20:56 +0100)]
MIPS: Make the IRIX naming of local section symbols consistent

Make the MIPS/IRIX naming of local section symbols consistent between
files produced by generic ELF code and ELF linker code, complementing
commit 174fd7f95561 ("New bfd elf hook: force naming of local section
symbols"), <https://sourceware.org/ml/binutils/2004-02/msg00072.html>.

Local section symbols have no names in the standard ELF gABI, however
the lack of a name causes problems with IRIX's MIPSpro linker.  To work
around the issue we give them names, however we do that in generic ELF
code only, based on what the `elf_backend_name_local_section_symbols'
hook returns if present.  That makes objects created by GAS or `objdump'
work correctly, however not ones created by `ld -r'.  That would not
normally cause issues with IRIX systems using GAS and `objdump' only
with the MIPSpro linker, however if GNU LD was used for whatever reason
in producing objects later fed to IRIX's MIPSpro linker, then things
would break.

Modify ELF linker code accordingly then, using the same hook.  Adjust
the `ld-elf/64ksec-r' test accordingly so that it also accepts a section
symbol with a name.

Also modify the hook itself so that only actual ET_REL objects have
names assigned to local section symbols.  Other kinds of ELF files are
not ever supposed to be relocated with the MIPSpro linker, so we can
afford producing more standard output.

Add suitable GAS, LD and `objcopy' test cases to the relevant testsuites
to keep these tools consistently verified.  This change also fixes:

FAIL: objcopy executable (pr25662)

across MIPS targets using the IRIX compatibility mode.

bfd/
* elflink.c (bfd_elf_final_link): Give local symbols a name if
so requested.
* elfxx-mips.c (_bfd_mips_elf_name_local_section_symbols): Only
return TRUE if making ET_REL output.

binutils/
* testsuite/binutils-all/mips/global-local-symtab-sort-o32.d:
New test.
* testsuite/binutils-all/mips/global-local-symtab-sort-o32t.d:
New test.
* testsuite/binutils-all/mips/global-local-symtab-sort-n32.d:
New test.
* testsuite/binutils-all/mips/global-local-symtab-sort-n32t.d:
New test.
* testsuite/binutils-all/mips/global-local-symtab-sort-n64.d:
New test.
* testsuite/binutils-all/mips/global-local-symtab-sort-n64t.d:
New test.
* testsuite/binutils-all/mips/global-local-symtab-final-o32.d:
New test.
* testsuite/binutils-all/mips/global-local-symtab-final-n32.d:
New test.
* testsuite/binutils-all/mips/global-local-symtab-final-n64.d:
New test.
* testsuite/binutils-all/mips/mips.exp: Run the new tests.

gas/
* testsuite/gas/mips/global-local-symtab-sort-o32.d: New test.
* testsuite/gas/mips/global-local-symtab-sort-o32t.d: New test.
* testsuite/gas/mips/global-local-symtab-sort-n32.d: New test.
* testsuite/gas/mips/global-local-symtab-sort-n32t.d: New test.
* testsuite/gas/mips/global-local-symtab-sort-n64.d: New test.
* testsuite/gas/mips/global-local-symtab-sort-n64t.d: New test.
* testsuite/gas/mips/mips.exp: Run the new tests.

ld/
* testsuite/ld-elf/sec64k.exp: Also accept a section symbol with
a name.
* testsuite/ld-mips-elf/global-local-symtab-sort-o32.d: New
test.
* testsuite/ld-mips-elf/global-local-symtab-sort-o32t.d: New
test.
* testsuite/ld-mips-elf/global-local-symtab-sort-n32.d: New
test.
* testsuite/ld-mips-elf/global-local-symtab-sort-n32t.d: New
test.
* testsuite/ld-mips-elf/global-local-symtab-sort-n64.d: New
test.
* testsuite/ld-mips-elf/global-local-symtab-sort-n64t.d: New
test.
* testsuite/ld-mips-elf/global-local-symtab-final-o32.d: New
test.
* testsuite/ld-mips-elf/global-local-symtab-final-n32.d: New
test.
* testsuite/ld-mips-elf/global-local-symtab-final-n64.d: New
test.
* testsuite/ld-mips-elf/mips-elf.exp: Run the new tests.

4 years agoMIPS/LD: Set symtab's `sh_info' correctly for IRIX emulations
Maciej W. Rozycki [Wed, 29 Jul 2020 19:56:41 +0000 (20:56 +0100)]
MIPS/LD: Set symtab's `sh_info' correctly for IRIX emulations

Correct ELF linker code so as to set the `sh_info' value of the static
symbol table section according to the section symbols vs other symbols
split where required by the selection of the IRIX compatibility mode for
MIPS target.  Add a `elf_backend_elfsym_local_is_section' hook for that
purpose, returning TRUE if it is only STB_LOCAL/STT_SECTION symbols that
are to be considered local for the purpose of this split rather than all
STB_LOCAL symbols.

We do it already in generic ELF code, and have done it since 1993, with
the `elf_backend_sym_is_global' hook, affecting GAS and `objcopy', so
these tools produce correct ELF output in the IRIX compatibility mode,
however if such output is fed as input to `ld -r', then the linker's
output is no longer valid for that mode.  The relevant changes to
generic ELF code are:

commit 062189c6eab72c7ba1bab1cf30fdb27d67a7d668
Author: Ian Lance Taylor <ian@airs.com>
Date:   Thu Nov 18 17:12:47 1993 +0000

and:

commit 6e07e54f1b347f885cc6c021c3fd912c79bdaf55
Author: Ian Lance Taylor <ian@airs.com>
Date:   Thu Jan 6 20:01:42 1994 +0000

(split across two GIT commits likely due to repository conversion
peculiarities).

The `elf_backend_sym_is_global' hook however operates on BFD rather than
ELF symbols, making it unsuitable for the ELF linker as the linker does
not convert any symbol tables processed into the BFD format.  Converting
the hook to operate on ELF symbols would in principle be possible, but
it would still require a considerable rewrite of `bfd_elf_final_link' to
adapt to the interface.

Therefore, especially given that no new use for the IRIX compatibility
mode is expected, minimize changes made to the ELF linker code and just
add an entirely new hook, and wire it in the o32 and n32 MIPS backends
accordingly; the n64 backend never uses the IRIX compatibility mode.

Since we have no coverage here at all add suitable GAS, LD and `objcopy'
test cases to the relevant testsuites to keep these tools consistently
verified.

bfd/
* elf-bfd.h (elf_backend_data): Add
`elf_backend_elfsym_local_is_section' member.
* elfxx-target.h (elf_backend_elfsym_local_is_section): New
macro.
(elfNN_bed): Add `elf_backend_elfsym_local_is_section' member.
* elflink.c (bfd_elf_final_link): Use it to determine whether
set the `.symtab' section's `sh_info' value to the index of the
first non-local or non-section symbol.
* elf32-mips.c (mips_elf32_elfsym_local_is_section): New
function.
(elf_backend_elfsym_local_is_section): New macro.
* elfn32-mips.c (mips_elf_n32_elfsym_local_is_section): New
function.
(elf_backend_elfsym_local_is_section): New macro.

binutils/
* testsuite/binutils-all/mips/global-local-symtab-o32.d: New
test.
* testsuite/binutils-all/mips/global-local-symtab-o32t.d: New
test.
* testsuite/binutils-all/mips/global-local-symtab-n32.d: New
test.
* testsuite/binutils-all/mips/global-local-symtab-n32t.d: New
test.
* testsuite/binutils-all/mips/global-local-symtab-n64.d: New
test.
* testsuite/binutils-all/mips/mips.exp: Run the new tests.

gas/
* testsuite/gas/mips/global-local-symtab-o32.d: New test.
* testsuite/gas/mips/global-local-symtab-o32t.d: New test.
* testsuite/gas/mips/global-local-symtab-n32.d: New test.
* testsuite/gas/mips/global-local-symtab-n32t.d: New test.
* testsuite/gas/mips/global-local-symtab-n64.d: New test.
* testsuite/gas/mips/global-local-symtab.s: New test source.
* testsuite/gas/mips/mips.exp: Run the new tests.

ld/
* testsuite/ld-mips-elf/global-local-symtab-o32.d: New test.
* testsuite/ld-mips-elf/global-local-symtab-o32t.d: New test.
* testsuite/ld-mips-elf/global-local-symtab-n32.d: New test.
* testsuite/ld-mips-elf/global-local-symtab-n32t.d: New test.
* testsuite/ld-mips-elf/global-local-symtab-n64.d: New test.
* testsuite/ld-mips-elf/global-local-symtab.ld: New test linker
script.
* testsuite/ld-mips-elf/mips-elf.exp: Run the new tests.

4 years agoPR26279 Work around maybe-uninitialized warning in s390-mkopc.c
Andreas Arnez [Wed, 29 Jul 2020 17:46:44 +0000 (19:46 +0200)]
PR26279 Work around maybe-uninitialized warning in s390-mkopc.c

In s390-mkopc.c, the function insertExpandedMnemonic() searches for the
first occurrence of '*' or '$' in the given mnemonic, and, if a match is
found, chooses an extension table using a switch() on that character.  The
switch statement contains a default case that prints an error message and
does not set the extension table.  Although this case cannot occur, some
GCC versions obviously conclude that the extension table might have been
left uninitialized after the switch statement and consequently emit
maybe-uninitialized warnings for the variables 'ext_table' and
'ext_table_length'.

Circumvent the warning by handling the unreachable default case with
abort().

opcodes/
* s390-mkopc.c (insertExpandedMnemonic): Handle unreachable
default case with abort() instead of printing an error message and
continuing, to avoid a maybe-uninitialized warning.

4 years ago[gdb/testsuite] Fix captured_command_loop breakpoint in selftests
Tom de Vries [Wed, 29 Jul 2020 16:16:26 +0000 (18:16 +0200)]
[gdb/testsuite] Fix captured_command_loop breakpoint in selftests

When building gcc with CFLAGS/CXXFLAGS="-O2 -g", and running the regression
tests, I run into the following FAILs:
...
FAIL: gdb.gdb/complaints.exp: breakpoint in captured_command_loop
FAIL: gdb.gdb/python-interrupts.exp: breakpoint in captured_command_loop
FAIL: gdb.gdb/python-selftest.exp: breakpoint in captured_command_loop
...

The problem is that when setting the breakpoint at captured_command_loop:
...
(gdb) break captured_command_loop^M
Breakpoint 1 at 0x4230ed: captured_command_loop. (2 locations)^M
(gdb) FAIL: gdb.gdb/complaints.exp: breakpoint in captured_command_loop
...
there are two breakpoint locations instead of one.  This is due to
PR26096 - "gdb sets breakpoint at cold clone":
...
$ nm gdb | grep captured_command_loop| c++filt
0000000000659f20 t captured_command_loop()
00000000004230ed t captured_command_loop() [clone .cold]
...

Work around this by allowing multiple breakpoint locations for
captured_command_loop.

Reg-tested on x86_64-linux.

gdb/testsuite/ChangeLog:

2020-07-29  Tom de Vries  <tdevries@suse.de>

* lib/selftest-support.exp (selftest_setup): Allow breakpoint at
multiple locations.

4 years agoFor DWARF v5 Dwarf Package Files (.dwp files), the section identifier encodings have...
Caroline Tice [Wed, 29 Jul 2020 15:33:07 +0000 (16:33 +0100)]
For DWARF v5 Dwarf Package Files (.dwp files), the section identifier encodings have changed. This patch updates dwarf2.h to contain the new encodings.  (see dwarfstd.org/doc/DWARF5.pdf, section 7.3.5).

        * dwarf2.h (enum dwarf_sect_v5): A new enum section for the
 sections in a DWARF 5 DWP file (DWP version 5).

4 years agoDon't segfault on discarded section dynsyms
Alan Modra [Wed, 29 Jul 2020 08:04:18 +0000 (17:34 +0930)]
Don't segfault on discarded section dynsyms

We get lots of errors before we get to this code, but let's not
segfault.

* elflink.c (bfd_elf_final_link): Don't segfault on local dynsyms
defined in excluded sections.

4 years agoDon't assert at ldwrite.c:212
Alan Modra [Wed, 29 Jul 2020 08:00:15 +0000 (17:30 +0930)]
Don't assert at ldwrite.c:212

When excluding SHF_LINK_ORDER sections that happen to have SEC_KEEP
set, we need to set SEC_EXCLUDE here to avoid a problem later.

* ldelf.c (ldelf_before_place_orphans): Set SEC_EXCLUDE for
discarded sections.

4 years ago[tdep/s390] Fix Wmaybe-uninitialized in s390_displaced_step_fixup
Tom de Vries [Wed, 29 Jul 2020 07:03:20 +0000 (09:03 +0200)]
[tdep/s390] Fix Wmaybe-uninitialized in s390_displaced_step_fixup

When building gdb with CFLAGS/CXXFLAGS="-O2 -g -Wall", I see:
...
src/gdb/s390-tdep.c: In function 'void s390_displaced_step_fixup(gdbarch*, \
  displaced_step_closure*, CORE_ADDR, CORE_ADDR, regcache*)':
src/gdb/s390-tdep.c:528:30: warning: 'r2' may be used uninitialized in this \
  function [-Wmaybe-uninitialized]
  528 |       if (insn[0] == op_basr && r2 == 0)
      |           ~~~~~~~~~~~~~~~~~~~^~~~~~~~~~
...

The problem is that the compiler is unaware that
'is_rr (insn, op_basr, &r1, &r2) == 1' ensures that 'insn[0] == op_basr':
...
  if (is_rr (insn, op_basr, &r1, &r2)
      || is_rx (insn, op_bas, &r1, &d2, &x2, &b2))
    {
      /* Recompute saved return address in R1.  */
      regcache_cooked_write_unsigned (regs, S390_R0_REGNUM + r1,
                                      amode | (from + insnlen));
      /* Update PC iff the instruction doesn't actually branch.  */
      if (insn[0] == op_basr && r2 == 0)
        regcache_write_pc (regs, from + insnlen);
    }
...

Fix this by storing the result of the call, and using it instead of
'insn[0] ==op_basr'.

Build on x86_64-linux with --enable-targets=s390-suse-linux,s390x-suse-linux.

gdb/ChangeLog:

2020-07-29  Tom de Vries  <tdevries@suse.de>

PR tdep/26280
* s390-tdep.c (s390_displaced_step_fixup): Fix Wmaybe-uninitialized.

4 years ago[gdb/testsuite] Make gdb.dwarf2/dw2-line-number-zero.exp more robust
Tom de Vries [Wed, 29 Jul 2020 06:41:09 +0000 (08:41 +0200)]
[gdb/testsuite] Make gdb.dwarf2/dw2-line-number-zero.exp more robust

On aarch64, there are FAILs for gdb.dwarf2/dw2-line-number-zero.exp due to
problems in the prologue analyzer (filed as PR26310).

Make the test-case more robust by avoiding to use the prologue analyzer:
...
-gdb_breakpoint "bar1"
+gdb_breakpoint "$srcfile:27"
...

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

2020-07-29  Tom de Vries  <tdevries@suse.de>

* gdb.dwarf2/dw2-line-number-zero.exp: Set breakpoints on lines
rather than function name.

4 years agoAutomatic date update in version.in
GDB Administrator [Wed, 29 Jul 2020 00:00:06 +0000 (00:00 +0000)]
Automatic date update in version.in

4 years agoDemangle function names when disassembling
Andrew Burgess [Tue, 28 Jul 2020 17:48:15 +0000 (11:48 -0600)]
Demangle function names when disassembling

Andrew Burgess pointed out a regression, which he described in
PR symtab/26270:

================
After commit:

  commit bcfe6157ca288efed127c5efe21ad7924e0d98cf (refs/bisect/bad)
  Date:   Fri Apr 24 15:35:01 2020 -0600

      Use the linkage name if it exists

The disassembler no longer demangles function names in its output.  So
we see things like this:

  (gdb) disassemble tree_insert
  Dump of assembler code for function _Z11tree_insertP4nodei:
    ....

Instead of this:

  (gdb) disassemble tree_insert
  Dump of assembler code for function tree_insert(node*, int):
    ....

This is because find_pc_partial_function now returns the linkage name
rather than the demangled name.
================

This patch fixes the problem by introducing a new "overload" of
find_pc_partial_function, which returns the general_symbol_info rather
than simply the name.  This lets the disassemble command choose which
name to show.

Regression tested on x86-64 Fedora 32.

gdb/ChangeLog
2020-07-28  Tom Tromey  <tromey@adacore.com>

PR symtab/26270:
* symtab.h (find_pc_partial_function_sym): Declare.
* cli/cli-cmds.c (disassemble_command): Use
find_pc_partial_function_sym.  Check asm_demangle.
* blockframe.c (cache_pc_function_sym): New global.
(cache_pc_function_name): Remove.
(clear_pc_function_cache): Update.
(find_pc_partial_function_sym): New function, from
find_pc_partial_function.
(find_pc_partial_function): Rewrite using
find_pc_partial_function_sym.

gdb/testsuite/ChangeLog
2020-07-28  Andrew Burgess  <andrew.burgess@embecosm.com>

PR symtab/26270:
* gdb.cp/disasm-func-name.cc: New file.
* gdb.cp/disasm-func-name.exp: New file.

4 years agoUpdate "disassemble" help
Tom Tromey [Tue, 28 Jul 2020 17:43:24 +0000 (11:43 -0600)]
Update "disassemble" help

Pedro pointed out that disassemble/m should be documented after
disassemble/s, because /m is deprecated.  This patch does so, and adds
a usage line.

Regression tested on x86-64 Fedora 32.

gdb/ChangeLog
2020-07-28  Tom Tromey  <tromey@adacore.com>

* cli/cli-cmds.c (_initialize_cli_cmds): Rearrange "disassemble"
help.  Add usage.

4 years agoFix bug in DW_OP_GNU_variable_value evaluation
Tom Tromey [Tue, 28 Jul 2020 16:55:43 +0000 (10:55 -0600)]
Fix bug in DW_OP_GNU_variable_value evaluation

A modified version of the gnat compiler (TBH I don't know if the
modifications are relevant to this bug or not, but I figured I'd
mention it) can generate a DWARF location expression like:

 <1><1201>: Abbrev Number: 3 (DW_TAG_dwarf_procedure)
    <1202>   DW_AT_location    : 32 byte block: 12 31 29 28 4 0 30 2f 12 0 14 30 2d 28 4 0 14 2f 1 0 30 34 1e 23 3 9 fc 1a 16 13 16 13  (DW_OP_dup; DW_OP_lit1; DW_OP_eq; DW_OP_bra: 4; DW_OP_lit0; DW_OP_skip: 18; DW_OP_over; DW_OP_lit0; DW_OP_lt; DW_OP_bra: 4; DW_OP_over; DW_OP_skip: 1; DW_OP_lit0; DW_OP_lit4; DW_OP_mul; DW_OP_plus_uconst: 3; DW_OP_const1s: -4; DW_OP_and; DW_OP_swap; DW_OP_drop; DW_OP_swap; DW_OP_drop)

 <2><1279>: Abbrev Number: 9 (DW_TAG_structure_type)
    <127a>   DW_AT_name        : (indirect string, offset: 0x1a5a): p__logical_channel_t
    <127e>   DW_AT_byte_size   : 18 byte block: fd 43 12 0 0 97 94 1 99 34 0 0 0 23 7 9 fc 1a  (DW_OP_GNU_variable_value: <0x1243>; DW_OP_push_object_address; DW_OP_deref_size: 1; DW_OP_call4: <0x1201>; DW_OP_plus_uconst: 7; DW_OP_const1s: -4; DW_OP_and)

When evaluated, this gives:

    Incompatible types on DWARF stack

In Jakub's original message about DW_OP_GNU_variable_value:

    https://gcc.gnu.org/legacy-ml/gcc-patches/2017-02/msg01499.html

.. it says:

    The intended behavior is that the debug info consumer computes the
    value of that referenced variable at the current PC, and if it can
    compute it and pushes the value as a generic type integer into the
    DWARF stack

Instead, gdb is using the variable's type -- but this fails with some
operations, like DW_OP_and, which expect the types to match.

I believe what was intended was for the value to be cast to the DWARF
"untyped" type, which is what this patch implements.  This patch also
updates varval.exp to exhibit the bug.

gdb/ChangeLog
2020-07-28  Tom Tromey  <tromey@adacore.com>

* dwarf2/expr.c (dwarf_expr_context::execute_stack_op)
<DW_OP_GNU_variable_value>: Cast to address type.

gdb/testsuite/ChangeLog
2020-07-28  Tom Tromey  <tromey@adacore.com>

* gdb.dwarf2/varval.exp (setup_exec): Add 'or' instruction to
'varval' location.

4 years agoImplement xfer_partial TARGET_OBJECT_SIGNAL_INFO for NetBSD
Kamil Rytarowski [Sun, 26 Jul 2020 12:10:56 +0000 (14:10 +0200)]
Implement xfer_partial TARGET_OBJECT_SIGNAL_INFO for NetBSD

NetBSD implements reading and overwriting siginfo_t received by the
tracee. With TARGET_OBJECT_SIGNAL_INFO signal information can be
examined and modified through the special variable $_siginfo.

Implement the "get_siginfo_type" gdbarch method for NetBSD architectures.

As with Linux architectures, cache the created type in the gdbarch when it
is first created.  Currently NetBSD uses an identical siginfo type on
all architectures, so there is no support for architecture-specific fields.

gdb/ChangeLog:

* nbsd-nat.h (nbsd_nat_target::xfer_partial): New declaration.
* nbsd-nat.c (nbsd_nat_target::xfer_partial): New function.
* nbsd-tdep.c (nbsd_gdbarch_data_handle, struct nbsd_gdbarch_data)
(init_nbsd_gdbarch_data, get_nbsd_gdbarch_data)
(nbsd_get_siginfo_type): New.
(nbsd_init_abi): Install gdbarch "get_siginfo_type" method.
(_initialize_nbsd_tdep): New

4 years agoPKG_CHECK_MODULES: Properly check if $pkg_cv_[]$1[]_LIBS works
H.J. Lu [Tue, 28 Jul 2020 13:59:20 +0000 (06:59 -0700)]
PKG_CHECK_MODULES: Properly check if $pkg_cv_[]$1[]_LIBS works

There is no need to check $pkg_cv_[]$1[]_LIBS works if package check
failed.

config/

PR binutils/26301
* pkg.m4 (PKG_CHECK_MODULES): Use AC_TRY_LINK only if
$pkg_failed = no.

binutils/

PR binutils/26301
* configure: Regenerated.

gdb/

PR binutils/26301
* configure: Regenerated.

4 years ago[gdb/build] Fix Wmaybe-uninitialized in gdb_optional.h
Tom de Vries [Tue, 28 Jul 2020 13:07:44 +0000 (15:07 +0200)]
[gdb/build] Fix Wmaybe-uninitialized in gdb_optional.h

When building with CFLAGS/CXXFLAGS="-O2 -g -Wall", we run into:
...
In file included from src/gdb/exceptions.h:23,
                 from src/gdb/utils.h:24,
                 from src/gdb/defs.h:630,
                 from src/gdb/record-btrace.c:22:
src/gdb/ui-out.h: In function 'void btrace_insn_history(ui_out*, \
  const btrace_thread_info*, const btrace_insn_iterator*, \
  const btrace_insn_iterator*, gdb_disassembly_flags)':
src/gdb/ui-out.h:352:18: warning: \
  'asm_list.ui_out_emit_type<ui_out_type_list>::m_uiout' may be used \
  uninitialized in this function [-Wmaybe-uninitialized]
  352 |     m_uiout->end (Type);
      |     ~~~~~~~~~~~~~^~~~~~
src/gdb/record-btrace.c:795:35: note: \
  'asm_list.ui_out_emit_type<ui_out_type_list>::m_uiout' was declared here
  795 |   gdb::optional<ui_out_emit_list> asm_list;
      |                                   ^~~~~~~~
...

This is reported as PR gcc/80635 - "[8/9/10/11 regression] std::optional and
bogus -Wmaybe-uninitialized warning".

Silence the warning by using the workaround suggested here (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635#c53 ):
...
   union
   {
     struct { } m_dummy;
     T m_item;
+    volatile char dont_use; // Silences -Wmaybe-uninitialized warning.
   };
...

Build on x86_64-linux.

gdbsupport/ChangeLog:

2020-07-28  Tom de Vries  <tdevries@suse.de>

PR build/26281
* gdb_optional.h (class optional): Add volatile member to union
contaning m_dummy and m_item.

4 years agoPKG_CHECK_MODULES: Check if $pkg_cv_[]$1[]_LIBS works
H.J. Lu [Tue, 28 Jul 2020 10:50:10 +0000 (03:50 -0700)]
PKG_CHECK_MODULES: Check if $pkg_cv_[]$1[]_LIBS works

It is quite normal to have headers without library on multilib OSes.
Add AC_TRY_LINK to PKG_CHECK_MODULES to check if $pkg_cv_[]$1[]_LIBS
works.

config/

PR binutils/26301
* pkg.m4 (PKG_CHECK_MODULES): Add AC_TRY_LINK to check if
$pkg_cv_[]$1[]_LIBS works.

binutils/

PR binutils/26301
* configure: Regenerated.

gdb/

PR binutils/26301
* configure: Regenerated.

4 years agox86: Handle {disp32} for (%bp)/(%ebp)/(%rbp)
H.J. Lu [Tue, 28 Jul 2020 10:41:16 +0000 (03:41 -0700)]
x86: Handle {disp32} for (%bp)/(%ebp)/(%rbp)

Since (%bp)/(%ebp)/(%rbp) are encoded as 0(%bp)/0(%ebp)/0(%rbp), use
disp32/disp16 on 0(%bp)/0(%ebp)/0(%rbp) for {disp32}.

Note: Since there is no disp32 on 0(%bp), use disp16 instead.

PR gas/26305
* config/tc-i386.c (build_modrm_byte): Use disp32/disp16 on
(%bp)/(%ebp)/(%rbp) for {disp32}.
* doc/c-i386.texi: Update {disp32} documentation.
* testsuite/gas/i386/pseudos.s: Add (%bp)/(%ebp) tests.
* testsuite/gas/i386/x86-64-pseudos.s: Add (%ebp)/(%rbp) tests.
* testsuite/gas/i386/pseudos.d: Updated.
* testsuite/gas/i386/x86-64-pseudos.d: Likewise.

4 years agogdb/python: make more use of RegisterDescriptors
Andrew Burgess [Wed, 22 Jul 2020 11:13:11 +0000 (12:13 +0100)]
gdb/python: make more use of RegisterDescriptors

This commit unifies all of the Python register lookup code (used by
Frame.read_register, PendingFrame.read_register, and
gdb.UnwindInfo.add_saved_register), and adds support for using a
gdb.RegisterDescriptor for register lookup.

Currently the register unwind code (PendingFrame and UnwindInfo) allow
registers to be looked up either by name, or by GDB's internal
number.  I suspect the number was added for performance reasons, when
unwinding we don't want to repeatedly map from name to number for
every unwind.  However, this kind-of sucks, it means Python scripts
could include GDB's internal register numbers, and if we ever change
this numbering in the future users scripts will break in unexpected
ways.

Meanwhile, the Frame.read_register method only supports accessing
registers using a string, the register name.

This commit unifies all of the register to register-number lookup code
in our Python bindings, and adds a third choice into the mix, the use
of gdb.RegisterDescriptor.

The register descriptors can be looked up by name, but once looked up,
they contain GDB's register number, and so provide all of the
performance benefits of using a register number directly.  However, as
they are looked up by name we are no longer tightly binding the Python
API to GDB's internal numbering scheme.

As we may already have scripts in the wild that are using the register
numbers directly I have kept support for this in the API, but I have
listed this method last in the manual, and I have tried to stress that
this is NOT a good method to use and that users should use either a
string or register descriptor approach.

After this commit all existing Python code should function as before,
but users now have new options for how to identify registers.

gdb/ChangeLog:

* python/py-frame.c: Remove 'user-regs.h' include.
(frapy_read_register): Rewrite to make use of
gdbpy_parse_register_id.
* python/py-registers.c (gdbpy_parse_register_id): New function,
moved here from python/py-unwind.c.  Updated the return type, and
also accepts register descriptor objects.
* python/py-unwind.c: Remove 'user-regs.h' include.
(pyuw_parse_register_id): Moved to python/py-registers.c.
(unwind_infopy_add_saved_register): Update to use
gdbpy_parse_register_id.
(pending_framepy_read_register): Likewise.
* python/python-internal.h (gdbpy_parse_register_id): Declare.

gdb/testsuite/ChangeLog:

* gdb.python/py-unwind.py: Update to make use of a register
descriptor.

gdb/doc/ChangeLog:

* python.texi (Unwinding Frames in Python): Update descriptions
for PendingFrame.read_register and
gdb.UnwindInfo.add_saved_register.
(Frames In Python): Update description of Frame.read_register.

4 years agogdb: Add a find method for RegisterDescriptorIterator
Andrew Burgess [Wed, 22 Jul 2020 13:02:30 +0000 (14:02 +0100)]
gdb: Add a find method for RegisterDescriptorIterator

Adds a new method 'find' to the gdb.RegisterDescriptorIterator class,
this allows gdb.RegisterDescriptor objects to be looked up directly by
register name rather than having to iterate over all registers.

This will be of use for a later commit.

I've documented the new function in the manual, but I don't think a
NEWS entry is required here, as, since the last release, the whole
register descriptor mechanism is new, and is already mentioned in the
NEWS file.

gdb/ChangeLog:

* python/py-registers.c: Add 'user-regs.h' include.
(register_descriptor_iter_find): New function.
(register_descriptor_iterator_object_methods): New static global
methods array.
(register_descriptor_iterator_object_type): Add pointer to methods
array.

gdb/testsuite/ChangeLog:

* gdb.python/py-arch-reg-names.exp: Add additional tests.

gdb/doc/ChangeLog:

* python.texi (Registers In Python): Document new find function.

4 years agoPR25022 testcase segfault for generic ELF linker targets
Alan Modra [Tue, 28 Jul 2020 05:19:07 +0000 (14:49 +0930)]
PR25022 testcase segfault for generic ELF linker targets

Even a testcase that is expected to fail shouldn't segfault.

* elf.c (assign_section_numbers): Comment.  Don't segfault on
discarded sections when setting linked-to section for generic
ELF linker.
* elflink.c (bfd_elf_match_symbols_in_sections): Allow NULL info.

4 years agoMore just-syms changes
Alan Modra [Tue, 28 Jul 2020 02:14:16 +0000 (11:44 +0930)]
More just-syms changes

* ldlang.c (lang_check): Don't complain about relocs or merge
attributes from --just-symbols input.
* testsuite/ld-misc/just-symbols.exp: Just dump .data section.
Don't run test on a number of targets.

4 years agoRe: Allow new just-symbols test to run on XCOFF and PE
Alan Modra [Tue, 28 Jul 2020 01:13:34 +0000 (10:43 +0930)]
Re: Allow new just-symbols test to run on XCOFF and PE

This ensures we don't match random data *before* the line we want to
see, ie. that --just-symbols has excluded section contents from
just-symbols-0.o.  Oops, missed the ChangeLog entry before too.

* testsuite/ld-misc/just-symbols-1.dd: Revert last change.

4 years agoAutomatic date update in version.in
GDB Administrator [Tue, 28 Jul 2020 00:00:05 +0000 (00:00 +0000)]
Automatic date update in version.in

4 years agoUse SIGTRAP si_code values for all FreeBSD architectures on 11.3 and later.
John Baldwin [Mon, 27 Jul 2020 15:58:48 +0000 (08:58 -0700)]
Use SIGTRAP si_code values for all FreeBSD architectures on 11.3 and later.

Fixes to set correct si_code values (such as TRAP_BRKPT) were made to
the remaining FreeBSD architectures (MIPS and sparc64) in the head
branch leading up to 12.0 and were merged back between the 11.2 and
11.3 releases.

gdb/ChangeLog:

* fbsd-nat.h: Include <osreldate.h>.  Define USE_SIGTRAP_SIGINFO
for all architectures on FreeBSD 11.3 and later.

4 years agoRemove unused declaration from gcore.h
Tom Tromey [Mon, 27 Jul 2020 15:53:32 +0000 (09:53 -0600)]
Remove unused declaration from gcore.h

gcore.h declares load_corefile, but there are no other mentions of
this in the source.  This patch removes it.  Tested by grep and
rebuilding.

gdb/ChangeLog
2020-07-27  Tom Tromey  <tromey@adacore.com>

* gcore.h (load_corefile): Don't declare.

4 years agoAllow new just-symbols test to run on XCOFF and PE
Alan Modra [Mon, 27 Jul 2020 09:18:57 +0000 (18:48 +0930)]
Allow new just-symbols test to run on XCOFF and PE

* testsuite/ld-misc/just-symbols.exp: Run for x86_64 PE too.
Set LDFLAGS for PE and XCOFF.
* testsuite/ld-misc/just-symbols.ld: Accept XCOFF mapped .data.

4 years agoAccept --just-symbols symbols as absolute for xcoff
Alan Modra [Mon, 27 Jul 2020 08:03:59 +0000 (17:33 +0930)]
Accept --just-symbols symbols as absolute for xcoff

This patch is aimed at curing
    just-symbols-1.o: loader reloc in unrecognized section `*ABS*'
for xcoff by treating symbols defined by --just-symbols objects as
absolute.

* xcofflink.c (xcoff_need_ldrel_p): Accept --just-symbols symbols and
similar as absolute.
(bfd_xcoff_import_symbol): Don't fuss over absolute symbol
redefinitions here.

4 years agoPrevent strange "section mentioned in a -j option but not found"
Alan Modra [Mon, 27 Jul 2020 07:57:23 +0000 (17:27 +0930)]
Prevent strange "section mentioned in a -j option but not found"

"objdump -s -j .bss" results in a message that indicates objdump
couldn't find a .bss section when present.  Fix that.

* objdump.c (dump_section): Don't return without calling
process_section_p.

4 years agoctf test ERROR: $target-cc does not exist
Alan Modra [Mon, 27 Jul 2020 03:50:10 +0000 (13:20 +0930)]
ctf test ERROR: $target-cc does not exist

* testsuite/lib/ld-lib.exp (check_ctf_available): Check first that
target compiler is available.

4 years ago[GOLD] Power10 stub selection
Alan Modra [Thu, 23 Jul 2020 01:05:56 +0000 (10:35 +0930)]
[GOLD] Power10 stub selection

gold version of commit e10a07b32dc1.

* options.h (DEFINE_enum): Add optional_arg__ param, adjust
all uses.
(General_options): Add --power10-stubs and --no-power10-stubs.
* options.cc (General_options::finalize): Handle --power10-stubs.
* powerpc.cc (set_power10_stubs): Don't set when --power10-stubs=no.
(power10_stubs_auto): New.
(struct Plt_stub_ent): Add toc_ and tocoff_.  Don't use a bitfield
for indx_.
(struct Branch_stub_ent): Add toc_and tocoff_.  Use bitfields for
iter_, notoc_ and save_res_.
(add_plt_call_entry): Set toc_.  Adjust resizing conditions for
--power10-stubs=auto.
(add_long_branch_entry): Set toc_.
(add_eh_frame, define_stub_syms): No longer use const_iterators
for plt and long branch stub iteration.
(build_tls_opt_head, build_tls_opt_tail): Change parameters and
return value.  Move tests for __tls_get_addr to callers.
(plt_call_size): Handle --power10-stubs=auto.
(branch_stub_size): Likewise.
(Stub_table::do_write): Likewise.
(relocate): Likewise.

4 years agodoc: Replace preceeded with preceded
H.J. Lu [Mon, 27 Jul 2020 12:52:14 +0000 (05:52 -0700)]
doc: Replace preceeded with preceded

binutils/

* doc/binutils.texi: Replace preceeded with preceded.

gas/

* doc/as.texi: Replace preceeded with preceded.

4 years ago[gdb/build] Fix typo sys/sockets.h -> sys/socket.h
Tom de Vries [Mon, 27 Jul 2020 11:46:27 +0000 (13:46 +0200)]
[gdb/build] Fix typo sys/sockets.h -> sys/socket.h

I'm running into a build breaker:
...
src/gdb/ser-tcp.c:65:13: error: conflicting declaration ‘typedef int
socklen_t’
   65 | typedef int socklen_t;
      |             ^~~~~~~~~
In file included from ../gnulib/import/unistd.h:40,
                 from
/home/vries/gdb_versions/devel/src/gdb/../gnulib/import/pathmax.h:42,
                 from
/home/vries/gdb_versions/devel/src/gdb/../gdbsupport/common-defs.h:120,
                 from src/gdb/defs.h:28,
                 from src/gdb/ser-tcp.c:20:
/usr/include/unistd.h:277:21: note: previous declaration as ‘typedef
__socklen_t socklen_t’
  277 | typedef __socklen_t socklen_t;
      |                     ^~~~~~~~~
...
after commit 05a6b8c28b "Don't unnecessarily redefine 'socklen_t' type in
MinGW builds".

The root cause is a typo in gdb/configure.ac, using sys/sockets.h where
sys/socket.h was meant:
...
AC_CHECK_HEADERS([sys/sockets.h])
...

Fix the typo.

Build and tested on x86_64-linux.

gdb/ChangeLog:

2020-07-27  Tom de Vries  <tdevries@suse.de>

* configure.ac: Fix sys/sockets.h -> sys/socket.h typo.
* config.in: Regenerate.
* configure: Regenerate.

4 years agoAutomatic date update in version.in
GDB Administrator [Mon, 27 Jul 2020 00:00:07 +0000 (00:00 +0000)]
Automatic date update in version.in

4 years agolibctf: compilation failure on MinGW due to missing errno values
Eli Zaretskii [Sun, 26 Jul 2020 23:06:02 +0000 (16:06 -0700)]
libctf: compilation failure on MinGW due to missing errno values

This commit fixes a compilation failure in a couple of libctf files
due to the use of EOVERFLOW and ENOTSUP, which are not defined
when compiling on MinGW.

libctf/ChangeLog:

PR binutils/25155:
* ctf-create.c (EOVERFLOW): If not defined by system header,
redirect to ERANGE as a poor man's substitute.
* ctf-subr.c (ENOTSUP): If not defined, use ENOSYS instead.

(cherry picked from commit 50500ecfefd6acc4c7f6c2a95bc0ae1945103220)

4 years agoDon't unnecessarily redefine 'socklen_t' type in MinGW builds.
Eli Zaretskii [Sun, 26 Jul 2020 16:35:48 +0000 (19:35 +0300)]
Don't unnecessarily redefine 'socklen_t' type in MinGW builds.

The original configure-time tests in gdb/ and gdbserver/ failed to
detect that 'socklen_t' is defined in MinGW headers because the test
program included only sys/socket.h, which is absent in MinGW system
headers.  However on MS-Windows this data type is declared in another
header, ws2tcpip.h.  The modified test programs try using ws2tcpip.h
if sys/socket.h is unavailable.

Thanks to Joel Brobecker who helped me regenerate the configure
scripts and the config.in files.

gdb/ChangeLog:
2020-07-26  Eli Zaretskii  <eliz@gnu.org>

* configure.ac (AC_CHECK_HEADERS): Check for sys/socket.h and
ws2tcpip.h.  When checking whether socklen_t type is defined, use
ws2tcpip.h if it is available and sys/socket.h isn't.
* configure: Regenerate.
* config.in: Regenerate.

gdbserver/ChangeLog:
2020-07-26  Eli Zaretskii  <eliz@gnu.org>

* configure.ac (AC_CHECK_HEADERS): Add ws2tcpip.h.
When checking whether socklen_t type is defined, use ws2tcpip.h if
it is available and sys/socket.h isn't.
* configure: Regenerate.
* config.in: Regenerate.

4 years agoMIPS/binutils/testsuite: Correct mips.exp test ABI/emul/endian arrangement
Maciej W. Rozycki [Sun, 26 Jul 2020 13:43:21 +0000 (14:43 +0100)]
MIPS/binutils/testsuite: Correct mips.exp test ABI/emul/endian arrangement

The binutils testsuite supports involving LD in processing test cases
and with the MIPS target that has the same issues the LD testsuite does.

So to support LD in the MIPS part of the binutils testsuite similarly
to commit 86b24e15c45b ("MIPS/LD/testsuite: Correct comm-data.exp test
ABI/emul/endian arrangement") update the mips.exp test script to:

- correctly select emulations for targets using non-traditional MIPS
  emulations,

- correctly select ABIs for targets that do not support all of them,

- use the default endianness selection where possible to benefit targets
  that support only one,

- simplify test invocation by providing ABI-specific `run_dump_test'
  wrappers, specifically `run_dump_test_o32', `run_dump_test_n32' and
  `run_dump_test_n64', which remove the need to use conditionals across
  the Expect script or to repeat ABI-specific GAS and LD flags with each
  invocation,

borrowing changes from commit 78da84f99405 ("MIPS/LD/testsuite: Correct
mips-elf.exp test ABI/emul/endian arrangement").

As a side effect this disables o32 ABI testing for targets that are not
supposed to support them and do not with LD, but still have such support
with BFD and GAS due to our inflexibility in configuration.  Ultimately
we ought to support having o32 completely disabled.

binutils/
* testsuite/binutils-all/mips/mips.exp (run_dump_test_abi)
(run_dump_test_o32, run_dump_test_n32, run_dump_test_n64): New
procedures.
(has_newabi): Remove variable.
(has_abi, abi_asflags, abi_ldflags): New associative array
variables.
(irixemul): New variable.
Replace `run_dump_test' calls where applicable throughout with
`run_dump_test_o32', `run_dump_test_n32' and `run_dump_test_n64'
as appropriate.  Use `noarch' for tests that require their own
architecture setting.
* testsuite/binutils-all/mips/mips-ase-1.d: Remove GAS flags.
* testsuite/binutils-all/mips/mips-ase-2.d: Likewise.
* testsuite/binutils-all/mips/mips-ase-3.d: Likewise.
* testsuite/binutils-all/mips/mips-note-2-n32.d: Likewise.
* testsuite/binutils-all/mips/mips-note-2-n64.d: Likewise.
* testsuite/binutils-all/mips/mips-note-2.d: Likewise.
* testsuite/binutils-all/mips/mips-note-2r-n32.d: Likewise.
* testsuite/binutils-all/mips/mips-note-2r-n64.d: Likewise.
* testsuite/binutils-all/mips/mips-note-2r.d: Likewise.
* testsuite/binutils-all/mips/mips-reginfo-n32.d: Likewise.
* testsuite/binutils-all/mips/mips-reginfo.d: Likewise.
* testsuite/binutils-all/mips/mips16-extend-noinsn.d: Likewise.
* testsuite/binutils-all/mips/mips16-pcrel.d: Likewise.
* testsuite/binutils-all/mips/mips16-alias.d: Remove `-32' from
GAS flags.
* testsuite/binutils-all/mips/mips16-extend-insn.d: Likewise.
* testsuite/binutils-all/mips/mips16-noalias.d: Likewise.
* testsuite/binutils-all/mips/mips16-undecoded.d: Likewise.
* testsuite/binutils-all/mips/mips16e2-extend-insn.d: Likewise.
* testsuite/binutils-all/mips/mips16e2-undecoded.d: Likewise.
* testsuite/binutils-all/mips/mixed-micromips.d: Likewise.
* testsuite/binutils-all/mips/mixed-mips16.d: Likewise.

4 years agoAutomatic date update in version.in
GDB Administrator [Sun, 26 Jul 2020 00:00:06 +0000 (00:00 +0000)]
Automatic date update in version.in

4 years agogdb/fortran: resolve dynamic types when readjusting after an indirection
Andrew Burgess [Thu, 9 Jul 2020 15:26:23 +0000 (16:26 +0100)]
gdb/fortran: resolve dynamic types when readjusting after an indirection

After dereferencing a pointer (in value_ind) or following a
reference (in coerce_ref) we call readjust_indirect_value_type to
"fixup" the type of the resulting value object.

This fixup handles cases relating to the type of the resulting object
being different (a sub-class) of the original pointers target type.

If we encounter a pointer to a dynamic type then after dereferencing a
pointer (in value_ind) the type of the object created will have had
its dynamic type resolved.  However, in readjust_indirect_value_type,
we use the target type of the original pointer to "fixup" the type of
the resulting value.  In this case, the target type will be a dynamic
type, so the resulting value object, once again has a dynamic type.

This then triggers an assertion later within GDB.

The solution I propose here is that we call resolve_dynamic_type on
the pointer's target type (within readjust_indirect_value_type) so
that the resulting value is not converted back to a dynamic type.

The test case is based on the original test in the bug report.

gdb/ChangeLog:

PR fortran/23051
PR fortran/26139
* valops.c (value_ind): Pass address to
readjust_indirect_value_type.
* value.c (readjust_indirect_value_type): Make parameter
non-const, and add extra address parameter.  Resolve original type
before using it.
* value.h (readjust_indirect_value_type): Update function
signature and comment.

gdb/testsuite/ChangeLog:

PR fortran/23051
PR fortran/26139
* gdb.fortran/class-allocatable-array.exp: New file.
* gdb.fortran/class-allocatable-array.f90: New file.
* gdb.fortran/pointer-to-pointer.exp: New file.
* gdb.fortran/pointer-to-pointer.f90: New file.

4 years agoAutomatic date update in version.in
GDB Administrator [Sat, 25 Jul 2020 00:00:06 +0000 (00:00 +0000)]
Automatic date update in version.in

4 years ago[gdb/symtab] Ignore zero line table entries
Tom de Vries [Fri, 24 Jul 2020 22:23:06 +0000 (00:23 +0200)]
[gdb/symtab] Ignore zero line table entries

The DWARF standard states for the line register in the line number information
state machine the following:
...
An unsigned integer indicating a source line number.  Lines are numbered
beginning at 1.  The compiler may emit the value 0 in cases where an
instruction cannot be attributed to any source line.
...

So, it's possible to have a zero line number in the DWARF line table.

This is currently not handled by GDB.  The zero value is read in as any other
line number, but internally the zero value has a special meaning:
end-of-sequence, so the line table entry ends up having a different
interpretation than intended in some situations.

I've created a test-case where various aspects are tested, which has these 4
interesting tests.

1. Next-step through a zero-line instruction, is_stmt == 1
gdb.dwarf2/dw2-line-number-zero.exp: bar1, 2nd next

2. Next-step through a zero-line instruction, is_stmt == 0
gdb.dwarf2/dw2-line-number-zero.exp: bar2, 2nd next

3. Show source location at zero-line instruction, is_stmt == 1
gdb.dwarf2/dw2-line-number-zero.exp: continue to breakpoint: bar1_label_3

4. Show source location at zero-line instruction, is_stmt == 0
gdb.dwarf2/dw2-line-number-zero.exp: continue to breakpoint: bar2_label_3

And we have the following results:

8.3.1, 9.2:
...
FAIL: gdb.dwarf2/dw2-line-number-zero.exp: bar1, 2nd next
PASS: gdb.dwarf2/dw2-line-number-zero.exp: bar2, 2nd next
PASS: gdb.dwarf2/dw2-line-number-zero.exp: continue to breakpoint: bar1_label_3
FAIL: gdb.dwarf2/dw2-line-number-zero.exp: continue to breakpoint: bar2_label_3
...

commit 8c95582da8 "gdb: Add support for tracking the DWARF line table is-stmt
field":
...
PASS: gdb.dwarf2/dw2-line-number-zero.exp: bar1, 2nd next
PASS: gdb.dwarf2/dw2-line-number-zero.exp: bar2, 2nd next
FAIL: gdb.dwarf2/dw2-line-number-zero.exp: continue to breakpoint: bar1_label_3
FAIL: gdb.dwarf2/dw2-line-number-zero.exp: continue to breakpoint: bar2_label_3
...

commit d8cc8af6a1 "[gdb/symtab] Fix line-table end-of-sequence sorting",
master:
FAIL: gdb.dwarf2/dw2-line-number-zero.exp: bar1, 2nd next
FAIL: gdb.dwarf2/dw2-line-number-zero.exp: bar2, 2nd next
PASS: gdb.dwarf2/dw2-line-number-zero.exp: continue to breakpoint: bar1_label_3
PASS: gdb.dwarf2/dw2-line-number-zero.exp: continue to breakpoint: bar2_label_3
...

The regression in test 2 at commit d8cc8af6a1 was filed as PR symtab/26243,
where clang emits zero line numbers.

The way to fix all tests is to make sure line number zero internally doesn't
clash with special meaning values, and by handling it appropriately
everywhere.  That however looks too intrusive for the GDB 10 release.

Instead, we decide to ensure defined behaviour for line number zero by
ignoring it.  This gives us back the test results from before commit
d8cc8af6a1, fixing PR26243.

We mark the FAILs for tests 3 and 4 as KFAILs.  Test 4 was already failing for
the 9.2 release, and we consider the regression of test 3 from gdb 9.2 to gdb
10 the cost for having defined behaviour.

Build and reg-tested on x86_64-linux.

gdb/ChangeLog:

2020-07-25  Tom de Vries  <tdevries@suse.de>

PR symtab/26243
* dwarf2/read.c (lnp_state_machine::record_line): Ignore zero line
entries.

gdb/testsuite/ChangeLog:

2020-07-25  Tom de Vries  <tdevries@suse.de>

PR symtab/26243
* gdb.dwarf2/dw2-line-number-zero.c: New test.
* gdb.dwarf2/dw2-line-number-zero.exp: New file.