binutils-gdb.git
3 years agolibctf: fix ChangeLog date
Nick Alcock [Tue, 23 Feb 2021 13:41:59 +0000 (13:41 +0000)]
libctf: fix ChangeLog date

I pushed this change without fixing up the date by mistake.

3 years agolibctf: reimplement many _iter iterators in terms of _next
Nick Alcock [Thu, 18 Feb 2021 17:03:28 +0000 (17:03 +0000)]
libctf: reimplement many _iter iterators in terms of _next

Ever since the generator-style _next iterators were introduced, there
have been separate implementations of the functional-style _iter
iterators that do the same thing as _next.

This is annoying and adds more dependencies on the internal guts of the
file format.  Rip them all out and replace them with the corresponding
_next iterators.  Only ctf_archive_raw_iter and ctf_label_iter survive,
the former because there is no access to the raw binary data of archives
via any _next iterator, and the latter because ctf_label_next hasn't
been implemented (because labels are currently not used for anything).

Tested by reverting the change (already applied) that reimplemented
ctf_member_iter in terms of ctf_member_next, then verifying that the
_iter and _next iterators produced the same results for every iterable
entity within a large type archive.

libctf/ChangeLog
2021-03-02  Nick Alcock  <nick.alcock@oracle.com>

* ctf-types.c (ctf_member_iter): Move 'rc' to an inner scope.
(ctf_enum_iter): Reimplement in terms of ctf_enum_next.
(ctf_type_iter): Reimplement in terms of ctf_type_next.
(ctf_type_iter_all): Likewise.
(ctf_variable_iter): Reimplement in terms of ctf_variable_next.
* ctf-archive.c (ctf_archive_iter_internal): Remove.
(ctf_archive_iter): Reimplement in terms of ctf_archive_next.

3 years agolibctf: ctf_archive_next should set the parent name consistently
Nick Alcock [Thu, 18 Feb 2021 16:56:23 +0000 (16:56 +0000)]
libctf: ctf_archive_next should set the parent name consistently

The top level of CTF containers is a "CTF archive", which contains a
collection of named members (each a CTF dictionary).  In the serialized
file format, this is optional and skipped if the archive would have only
one member, as when no ambiguous types are present: so it is commonplace
to have a simple ctf_dict_t written out, with no archive container
wrapped around it.

But, unlike ctf_archive_iter, ctf_archive_next didn't quite handle this
case right.  It should set the name of this fake "member" to
_CTF_SECTION, i.e. ".ctf", but it was failing to do so, so callers got
an unintialized variable back instead and were understandably confused.

So set the name properly.

libctf/ChangeLog
2021-03-02  Nick Alcock  <nick.alcock@oracle.com>

* ctf-archive.c (ctf_archive_next): Set the name of parents in
single-member archives.

3 years agoPR27451, -z start_stop_gc for powerpc64
Alan Modra [Tue, 2 Mar 2021 10:55:20 +0000 (21:25 +1030)]
PR27451, -z start_stop_gc for powerpc64

PowerPC64 has its own gc_mark_dynamic_ref.

bfd/
PR 27451
* elf64-ppc.c (ppc64_elf_gc_mark_dynamic_ref): Ignore synthesized
linker defined start/stop symbols when start_stop_gc.
ld/
* testsuite/ld-powerpc/startstop.d,
* testsuite/ld-powerpc/startstop.r,
* testsuite/ld-powerpc/startstop.s: New test.
* testsuite/ld-powerpc/powerpc.exp: Run it.

3 years agoPowerPC64 undefined weak visibility vs GOT optimisation
Alan Modra [Tue, 2 Mar 2021 10:52:31 +0000 (21:22 +1030)]
PowerPC64 undefined weak visibility vs GOT optimisation

Undefined weak symbols with non-default visibility are seen as local
by SYMBOL_REFERENCES_LOCAL.  This stops a got indirect to relative
optimisation for them, so that pies and dlls don't get non-zero values
when loading somewhere other than the address they are linked at
(which always happens).  The optimisation could be allowed for pdes,
but I thought it best not to allow it there too.

bfd/
* elf64-ppc.c (ppc64_elf_relocate_section): Don't optimise got
indirect to pc-relative or toc-relative for undefined symbols.
ld/
* testsuite/ld-powerpc/weak1.d,
* testsuite/ld-powerpc/weak1.r,
* testsuite/ld-powerpc/weak1.s,
* testsuite/ld-powerpc/weak1so.d,
* testsuite/ld-powerpc/weak1so.r: New tests.
* testsuite/ld-powerpc/powerpc.exp: Run them.

3 years agoAutomatic date update in version.in
GDB Administrator [Tue, 2 Mar 2021 00:00:18 +0000 (00:00 +0000)]
Automatic date update in version.in

3 years agoAdd DWARF-5 section names to PE and PEP linker scripts.
Nick Clifton [Mon, 1 Mar 2021 16:25:06 +0000 (16:25 +0000)]
Add DWARF-5 section names to PE and PEP linker scripts.

PR 27268
* scripttempl/pe.sc: Add DWARF-5 section names.
* scripttempl/pep.sc: Likewise.

3 years agoWarn for missing separate debug files only if needed
H.J. Lu [Mon, 1 Mar 2021 13:34:34 +0000 (05:34 -0800)]
Warn for missing separate debug files only if needed

We shouldn't warn missing separate debug files when debug info isn't
needed.

PR binutils/27486
* dwarf.c (load_separate_debug_info): Issue warning only if
do_debug_links is set.
* testsuite/binutils-all/compress.exp: Run objdump and readelf
with missing debug file.

3 years agoPR27451, -z start_stop_gc
Alan Modra [Sun, 28 Feb 2021 21:52:49 +0000 (08:22 +1030)]
PR27451, -z start_stop_gc

When --gc-sections is in effect, a reference from a retained section
to __start_SECNAME or __stop_SECNAME causes all input sections named
SECNAME to also be retained, if SECNAME is representable as a C
identifier and either __start_SECNAME or __stop_SECNAME is synthesized
by the linker.  Add an option to disable that feature, effectively
ignoring any relocation that references a synthesized linker defined
__start_ or __stop_ symbol.

PR 27451
include/
* bfdlink.h (struct bfd_link_info): Add start_stop_gc.
bfd/
* elflink.c (_bfd_elf_gc_mark_rsec): Ignore synthesized linker
defined start/stop symbols when start_stop_gc.
(bfd_elf_gc_mark_dynamic_ref_symbol): Likewise.
(bfd_elf_define_start_stop): Don't modify ldscript_def syms.
* linker.c (bfd_generic_define_start_stop): Likewise.
ld/
* emultempl/elf.em: Handle -z start-stop-gc and -z nostart-stop-gc.
* lexsup.c (elf_static_list_options): Display help for them.  Move
help for -z stack-size to here from elf_shlib_list_options. Add
help for -z start-stop-visibility and -z undefs.
* ld.texi: Document -z start-stop-gc and -z nostart-stop-gc.
* NEWS: Mention -z start-stop-gc.
* testsuite/ld-gc/start2.s,
* testsuite/ld-gc/start2.d: New test.
* testsuite/ld-gc/gc.exp: Run it.

3 years agoWeak references to __start_/__stop_ symbols
Alan Modra [Mon, 1 Mar 2021 01:10:51 +0000 (11:40 +1030)]
Weak references to __start_/__stop_ symbols

If a weak reference to a __start_foo or __stop_foo symbol ends up
having no definition due to all the foo sections being removed for
some reason, undef_start_stop currently makes the symbol strong
undefined.  That risks a linker undefined symbol error.  Fix that by
making the symbol undefweak and also undo some dynamic symbol state.

Note that saving the state of the symbol type at the time
lang_init_start_stop runs is not sufficient.  The linker may have
merged in a shared library reference by that point and made what was
an undefweak in regular objects, a strong undefined.  So it is
necessary to look at the ELF symbol flags to decide whether an
undefweak is the proper resolution.

Something probably should be done for COFF/PE too, but I'm unsure how
to do go about that.

* ldlang.c (undef_start_stop): For ELF make undefined start/stop
symbols undefweak if that was how they were referenced.  Undo
dynamic state too.

3 years agoPR27128, nm -P portable output format regression
Alan Modra [Sat, 27 Feb 2021 05:09:05 +0000 (15:39 +1030)]
PR27128, nm -P portable output format regression

Add nm --without-symbol-versions.

binutils/
PR 27128
* doc/binutils.texi: Add nm --with-symbol-versions and
--without-symbol-versions documentation.
* nm.c (with_symbol_versions): New variable.
(enum long_option_values): Delete OPTION_WITH_SYMBOL_VERSIONS.
(long_options): Make --with-symbol-versions entry twiddle the flag.
Add --without-symbol-versions.
(print_symname): Strip version when !with_symbol_versions.  Add
dynamic version info under control of with_symbol_versions.
(main): Remove OPTION_WITH_SYMBOL_VERSIONS case.
ld/
* testsuite/ld-elf/pr25708.d: Add --with-symbol-versions to nm.
* testsuite/ld-elf/pr27128a.d: Likewise.
* testsuite/ld-elf/pr27128b.d: Likewise.
* testsuite/ld-elf/pr27128c.d: Likewise.
* testsuite/ld-elf/pr27128d.d: Likewise.
* testsuite/ld-elf/pr27128e.d: Likewise.

3 years agoAutomatic date update in version.in
GDB Administrator [Mon, 1 Mar 2021 00:00:19 +0000 (00:00 +0000)]
Automatic date update in version.in

3 years agoAdd missing changes to Makefile.tpl
H.J. Lu [Sun, 28 Feb 2021 12:39:38 +0000 (04:39 -0800)]
Add missing changes to Makefile.tpl

Update Makefile.tpl to add missing changes in

commit af019bfde9b13d628202fe58054ec7ff08d92a0f
Author: H.J. Lu <hjl.tools@gmail.com>
Date:   Sat Jan 9 06:51:15 2021 -0800

    Support the PGO build for binutils+gdb

"autogen Makefile.def" showed no changes in Makefile.in.

PR binutils/26766
* Makefile.tpl (PGO_BUILD_TRAINING_FLAGS_TO_PASS): Add
PGO_BUILD_TRAINING=yes.
(PGO_BUILD_TRAINING_MFLAGS): New.
(all): Pass $(PGO_BUILD_TRAINING_MFLAGS) to the PGO build.

3 years agosim: igen: drop config.h & header checking
Mike Frysinger [Mon, 22 Feb 2021 05:51:34 +0000 (00:51 -0500)]
sim: igen: drop config.h & header checking

While the configure script was checking for a bunch of headers, only
one of them was conditionally included in the source (unistd.h).  The
rest were always included.  Based on those usage this whole time, we
can reasonably assume that the build also has unistd.h.

All the other files including config.h never actually used any defines
from the header.

3 years agosim: igen: delete more unused toolchain settings
Mike Frysinger [Mon, 22 Feb 2021 05:50:59 +0000 (00:50 -0500)]
sim: igen: delete more unused toolchain settings

This package doesn't build any archives or install programs.

3 years agosim: igen: delete unused FOR_BUILD vars
Mike Frysinger [Mon, 22 Feb 2021 03:52:00 +0000 (22:52 -0500)]
sim: igen: delete unused FOR_BUILD vars

3 years agosim: set up build-time compiler settings
Mike Frysinger [Mon, 22 Feb 2021 03:15:03 +0000 (22:15 -0500)]
sim: set up build-time compiler settings

Some sim dirs were already setting up CFLAGS_FOR_BUILD in inconsistent
ways.  Move it to a common place for reuse.

3 years agosim: use AC_CHECK_TOOL to find ar
Mike Frysinger [Mon, 22 Feb 2021 00:26:47 +0000 (19:26 -0500)]
sim: use AC_CHECK_TOOL to find ar

Rather than require $AR be set and then default to `ar`, use the
standard AC_CHECK_TOOL helper to find a good prefixed tool.  In
practice this shouldn't change much as we seem to have macros in
the tree that were already setting it up, but we shouldn't rely
on that implicitly.

3 years agosim: require AC_PROG_CPP explicitly
Mike Frysinger [Mon, 22 Feb 2021 00:24:10 +0000 (19:24 -0500)]
sim: require AC_PROG_CPP explicitly

All the scripts were using this implicitly already, so there's no real
change for them, but we want to call it explicitly as the CPP tool is
used to generate nltvals.def.

3 years agosim: delete unused SIM_EXTRA_LIBDEPS
Mike Frysinger [Mon, 22 Feb 2021 00:08:14 +0000 (19:08 -0500)]
sim: delete unused SIM_EXTRA_LIBDEPS

This was last used 15 years ago, so clearly not important enough to
keep around.  Punt it.

3 years agosim: delete redundant SIM_EXTRA_ALL
Mike Frysinger [Mon, 22 Feb 2021 00:02:47 +0000 (19:02 -0500)]
sim: delete redundant SIM_EXTRA_ALL

We don't need a variable to add a dependency to the "all" target, and
having one doesn't really add value.  Switch to the target directly for
the few ports that actually use this.

3 years agoAutomatic date update in version.in
GDB Administrator [Sun, 28 Feb 2021 00:00:13 +0000 (00:00 +0000)]
Automatic date update in version.in

3 years ago[PR gdb/27393] set directories: handle empty dirs.
Lancelot SIX [Thu, 25 Feb 2021 00:30:49 +0000 (00:30 +0000)]
[PR gdb/27393] set directories: handle empty dirs.

As reported in gdb/27393, the 'directory' and 'set directories' commands
fail when parsing an empty dir name:

    (gdb) set directories ""
    /home/lsix/dev/gnu/binutils-gdb/gdbsupport/pathstuff.cc:132: internal-error: gdb::unique_xmalloc_ptr<char> gdb_abspath(const char*): Assertion `path != NULL && path[0] != '\0'' failed.

or

    (gdb) dir :
    /home/lsix/dev/gnu/binutils-gdb/gdbsupport/pathstuff.cc:132: internal-error: gdb::unique_xmalloc_ptr<char> gdb_abspath(const char*): Assertion `path != NULL && path[0] != '\0'' failed.

This patch fixes this issue by ignoring any attempt to add an empty
name to the source directories list.  'set dir ""' will reset the
directories list the same way 'set dir' would do it.

Tested on x86_64.

3 years agoMinor fix in skip_ctf_tests
Tom Tromey [Sat, 27 Feb 2021 00:25:38 +0000 (17:25 -0700)]
Minor fix in skip_ctf_tests

I noticed an oddity in skip_ctf_tests -- for me it ends up caching the
string "!0", because it ends with 'return ![...]'.  In Tcl, this is
just string concatenation.

The result works because the users of this function have unbraced if
conditions, like:

    if [skip_ctf_tests] {

... which works because "if" re-parses the returned string as an
expression, and evaluates that.

There's only a latent bug here, but this is also un-idiomatic, so I am
checking in this patch to fix it.  This way, if someone in the future
uses a braced condition (which is what I normally recommend), it will
continue to work.

gdb/testsuite/ChangeLog
2021-02-26  Tom Tromey  <tom@tromey.com>

* lib/gdb.exp (skip_ctf_tests): Use expr on result.

3 years agoAutomatic date update in version.in
GDB Administrator [Sat, 27 Feb 2021 00:00:21 +0000 (00:00 +0000)]
Automatic date update in version.in

3 years agonm: Add --quiet to suppress "no symbols" diagnostic
Fangrui Song [Fri, 26 Feb 2021 17:25:45 +0000 (09:25 -0800)]
nm: Add --quiet to suppress "no symbols" diagnostic

PR binutils/27408
* readelf.c (quiet): New option flag.
(enum long_option_values): New enum to hold long option value.
(long_options): Add --quiet.
(usage): Mention --quiet.
(display_rel_file): If quiet is enabled, suppress "no symbols".
(main): Handle the new option.
* NEWS: Mention --quiet.
* docs/binutils.texi: Document --quiet.

3 years agoCorrect an error message in the ARM assembler.
Nick Clifton [Fri, 26 Feb 2021 16:37:30 +0000 (16:37 +0000)]
Correct an error message in the ARM assembler.

PR 27411
* config/tc-arm.c (do_t_add_sub): Correct error message.
* testsuite/gas/arm/pr27411.s: New test.
* testsuite/gas/arm/pr27411.d: New test driver.
* testsuite/gas/arm/pr27411.l: Expected error output for new test.

3 years agoAdd support for decoding DWARF v5 DW_AT_addr_base tags.
Tom de Vries [Fri, 26 Feb 2021 15:52:39 +0000 (15:52 +0000)]
Add support for decoding DWARF v5 DW_AT_addr_base tags.

* dwarf.c (display_debug_addr): Handle dwarf-5 .debug_addr bits.

3 years agotestsuite: Remove extra \n from expected output of tsv notifications
Jan Vrany [Fri, 26 Feb 2021 14:34:04 +0000 (14:34 +0000)]
testsuite: Remove extra \n from expected output of tsv notifications

Commit 2450ad54 removed extra trailing \n from tsv notifications but
did not update gdb.trace/mi-tsv-changed.exp accordingly. This commit
removes the extra \n from expected output so gdb.trace/mi-tsv-changed.exp
passes again.

gdb/testsuite/ChangeLog:

* gdb.trace/mi-tsv-changed.exp (test_create_delete_modify_tsv):
Remove trailing \n from expected output.

3 years agoAdd support for the split DWARF forms.
Tom de Vries [Fri, 26 Feb 2021 13:30:10 +0000 (13:30 +0000)]
Add support for the split DWARF forms.

PR 27390
* dwarf.c: (skip_attr_bytes): Add support for DW_FORM_str* and
DW_FORM_addrx*.
(read_and_display_attr_value): Likewise.

3 years agotestsuite: note on use_gdb_stub usage
Markus Metzger [Mon, 21 Dec 2020 07:14:55 +0000 (08:14 +0100)]
testsuite: note on use_gdb_stub usage

Add a note to the comment on use_gdb_stub explaining the use of this check
for skipping tests that spawn new inferiors as discussed here:

    https://sourceware.org/pipermail/gdb-patches/2020-December/174186.html

3 years agoAdd PR27441 testcase
Alan Modra [Fri, 26 Feb 2021 02:56:19 +0000 (13:26 +1030)]
Add PR27441 testcase

PR 27441
* testsuite/ld-plugin/pr27441a.c,
* testsuite/ld-plugin/pr27441b.c,
* testsuite/ld-plugin/pr27441c.c,
* testsuite/ld-plugin/pr27441c.d: New test.
* testsuite/ld-plugin/lto.exp: Run it.

3 years agolibctf regen for NEWS
Alan Modra [Wed, 24 Feb 2021 08:06:34 +0000 (18:36 +1030)]
libctf regen for NEWS

The previous regen was done on a tree without the new NEWS file.

* Makefile.in: Regenerate.

3 years agoAutomatic date update in version.in
GDB Administrator [Fri, 26 Feb 2021 00:00:18 +0000 (00:00 +0000)]
Automatic date update in version.in

3 years agoFix date in ChangeLog
Kevin Buettner [Thu, 25 Feb 2021 23:00:43 +0000 (16:00 -0700)]
Fix date in ChangeLog

3 years agoAdd comment regarding include order of <sys/ptrace.h> and <asm/ptrace.h>
Kevin Buettner [Thu, 25 Feb 2021 22:25:49 +0000 (15:25 -0700)]
Add comment regarding include order of <sys/ptrace.h> and <asm/ptrace.h>

I added the same comment for nat/aarch64-linux-hw-point.c yesterday.
Christian suggested adding the comment for the other file that I had
identified as including both <sys/ptrace.h> and <asm/ptrace.h>.

I searched the sources in gdb/, but found no other files which include
both of these headers.

If possible, I would prefer to see us use <sys/ptrace.h> when possible,
however, from past experience, I've found that this file does not always
contain all of the constants, etc. required by the particular source
file.

gdb/ChangeLog:

* nat/aarch64-sve-linux-ptrace.h: Add comment regarding include
order for <sys/ptrace.h> and <asm/ptrace.h>.

3 years agogdb: relax assertion in target_mourn_inferior
Simon Marchi [Thu, 25 Feb 2021 20:52:29 +0000 (15:52 -0500)]
gdb: relax assertion in target_mourn_inferior

As reported in PR 26861, when killing an inferior on macOS, we hit the
assert:

    ../../gdb-10.1/gdb/target.c:2149: internal-error: void target_mourn_inferior(ptid_t): Assertion `ptid == inferior_ptid' failed.

This is because darwin_nat_target::kill passes a pid-only ptid to
target_mourn_inferior, with the pid of the current inferior:

    target_mourn_inferior (ptid_t (inf->pid));

... which doesn't satisfy the assert in target_mourn_inferior:

    gdb_assert (ptid == inferior_ptid);

The reason for this assertion is that target_mourn_inferior is a
prototype shared between GDB and GDBserver, so that shared code in
gdb/nat (used in both GDB and GDBserver) can call target_mourn_inferior.
In GDB's implementation, it is likely that some targets still rely on
inferior_ptid being set to "the current thread we are working on".  So
until targets are completely decoupled from inferior_ptid (at least
their mourn_inferior implementations), we need to ensure the passed in
ptid matches inferior_ptid, to ensure the calling code called
target_mourn_inferior with the right global context.

However, I think the assert is a bit too restrictive.  The
mourn_inferior operation works on an inferior, not a specific thread.
And by the time we call mourn_inferior, the threads of the inferior
don't exist anymore, the process is gone, so it doesn't really make
sense to require inferior_ptid to point a specific thread.

I looked at all the target_ops::mourn_inferior implementations, those
that read inferior_ptid only care about the pid field, which supports
the idea that only the inferior matters.  Other implementations look at
the current inferior (call `current_inferior ()`).

I think it would make sense to change target_mourn_inferior to accept
only a pid rather than a ptid.  It would then assert that the pid is the
same as the current inferior's pid.  However, this would be a quite
involved change, so I'll keep it for later.

To fix the macOS issue immediately, I propose to relax the assert to
only compare the pids, as is done in this patch.

Another solution would obviously be to make darwin_nat_target::kill pass
inferior_ptid to target_mourn_inferior.  However, the solution I propose
is more in line with where I think we want to go (passing a pid to
target_mourn_inferior).

gdb/ChangeLog:

PR gdb/26861
* target.c (target_mourn_inferior): Only compare pids in
target_mourn_inferior.

Change-Id: If2439ccc5aa67272ea16148a43c5362ef23fb2b8

3 years agoFix initial thread state of non-threaded remote targets
Jan Matyas [Thu, 25 Feb 2021 07:27:09 +0000 (08:27 +0100)]
Fix initial thread state of non-threaded remote targets

This change fixes the initial state of the main thread of remote
targets which have no concept of threading. Such targets are
treated as single-threaded by gdb, and this single thread needs
to be initially set to the "resumed" state, in the same manner as
threads in thread-aware remote targets (see remote.c,
remote_target::remote_add_thread).

Without this fix, the following assert was triggered on thread-
unaware remote targets:

    remote_target::select_thread_for_ambiguous_stop_reply(const target_waitstatus*): Assertion `first_resumed_thread != nullptr' failed.

The bug can be reproduced using gdbserver

    * by disabling packets 'T' and 'qThreadInfo', or
    * by disabling all thread-related packets.

The test suite has been updated to include these two scenarios, see
gdb.server/stop-reply-no-thread.exp.

Change-Id: I2c39c9de17e8d6922a8c1b9e259eb316a554a43d

3 years agoAdd initial support for .debug_sup sections.
Nick Clifton [Thu, 25 Feb 2021 17:50:44 +0000 (17:50 +0000)]
Add initial support for .debug_sup sections.

* dwarf.c (get_type_abbrev_from_form): Accept but ignore sup
forms.
(read_and_display_attr_value): Handle sup forms.
(display_debug_sup): New function.  Displays the contents of a
.debug_sup section.
(load_debug_sup_file): New function.  Loads the contents of a file
referenced by a .debug_sup section.
(check_for_and_load_links): Call load_debug_sup_file.
(debug_displays): Add entry for .debug_sup.
* dwarf.h (enum dwarf_section_display_enum): Add debug_sup.
* readelf.c (process_section_headers): Add support for debug_sup.
* doc/debug.options.texi: Note that the =links option will display
the contents of .debug_sup sections.
* NEWS: Mention the new support.

3 years agogdb/testsuite: Add a missing -wrap in gdb_test_multiple
Andrew Burgess [Thu, 25 Feb 2021 16:06:25 +0000 (16:06 +0000)]
gdb/testsuite: Add a missing -wrap in gdb_test_multiple

In commit:

  commit faeb9f13c179a4c78bc295a0d0bbd788239704d9
  Date:   Wed Feb 24 12:50:00 2021 +0000

      gdb/fortran: add support for ASSOCIATED builtin

A test was added that fails to process the trailing gdb prompt inside
a gdb_test_multiple call, this will cause a failure if the tests are
run with READ1=1, or randomly at other times depending on how the
expect buffers are read in.

Fixed by adding a -wrap argument.

gdb/testsuite/ChangeLog:

* gdb.fortran/associated.exp: Add missing '-wrap' argument.

3 years agogdb/mi: Remove extra \n from tsv and and traceframe notifications
Jan Vrany [Thu, 25 Feb 2021 16:22:13 +0000 (16:22 +0000)]
gdb/mi: Remove extra \n from tsv and and traceframe notifications

An extra \n in calls to fprintf_unfiltered() caused invalid MI records
to be emitted:

   > gdb -i mi3 -ex "target remote :7000"
   =thread-group-added,id="i1"
   ~"GNU gdb (GDB) 11.0.50.20201019-git\n"
   ~"Copyright (C) 2020 Free Software Foundation, Inc.\n"
   ...
   ~"Remote debugging using :7001\n"
   =tsv-created,name="trace_timestamp",initial="0"\n
   =thread-group-started,id="i1",pid="304973"

This commit fixes the problem.

gdb/ChangeLog:

        * gdb/mi/mi-interp.c (mi_traceframe_changed): Remove trailing \n from output.
        (mi_tsv_created): Likewise.
        (mi_tsv_deleted): Likewise.

3 years ago[gdb/symtab] Fix wrong unit_type Dwarf Error
Tom de Vries [Thu, 25 Feb 2021 14:41:49 +0000 (15:41 +0100)]
[gdb/symtab] Fix wrong unit_type Dwarf Error

When running test-case gdb.dwarf2/fission-mix.exp using gcc-11 (and using the
tentative fix for PR27353 to get past that assertion failure), I run into:
...
(gdb) file fission-mix^M
Reading symbols from fission-mix...^M
Dwarf Error: wrong unit_type in compilation unit header \
  (is DW_UT_split_compile (0x05), should be DW_UT_type (0x02)) \
  [in module fission-mix2.dwo]^M
(No debugging symbols found in fission-mix)^M
...

The compilation unit that is complained about is:
...
Contents of the .debug_info.dwo section (loaded from fission-mix2.dwo):

  Compilation Unit @ offset 0x0:
   Length:        0x57 (32-bit)
   Version:       5
   Unit Type:     DW_UT_split_compile (5)
   Abbrev Offset: 0x0
   Pointer Size:  8
   DWO ID:        0x3e3930d3cc1805df
 <0><14>: Abbrev Number: 1 (DW_TAG_compile_unit)
...

And the dwarf error is triggered here in read_comp_unit_head:
...
        case DW_UT_split_compile:
          if (section_kind != rcuh_kind::COMPILE)
            error (_("Dwarf Error: wrong unit_type in compilation unit header "
                   "(is %s, should be %s) [in module %s]"),
                   dwarf_unit_type_name (cu_header->unit_type),
                   dwarf_unit_type_name (DW_UT_type), filename);
          break;
...
due to passing rcuh_kind::TYPE here in open_and_init_dwo_file:
...
      create_debug_type_hash_table (per_objfile, dwo_file.get (),
                                    &dwo_file->sections.info, dwo_file->tus,
                                    rcuh_kind::TYPE);
...

Fix this by changing the section_kind argument to create_debug_type_hash_table
to rcuh_kind::COMPILE, to reflect that we're passing &dwo_file->sections.info
rather than &dwo_file->sections.types.

Tested on x86_64-linux.

gdb/ChangeLog:

2021-02-25  Tom de Vries  <tdevries@suse.de>

PR symtab/27354
* dwarf2/read.c (open_and_init_dwo_file): Use rcuh_kind::COMPILE as
section_kind for &dwo_file->sections.info.

3 years agold: correct description of behavior for symbols redefined by script
Jan Beulich [Thu, 25 Feb 2021 13:35:29 +0000 (14:35 +0100)]
ld: correct description of behavior for symbols redefined by script

Prior to 89753bbf8102 ("Warn when a script redefines a symbol") there
was no diagnostic at all. As of that commit, it's a warning, not an
error.

3 years agogdb/fortran: don't access non-existent type fields
Andrew Burgess [Fri, 13 Nov 2020 10:39:23 +0000 (10:39 +0000)]
gdb/fortran: don't access non-existent type fields

When attempting to call a Fortran function for which there is no debug
information we currently trigger undefined behaviour in GDB by
accessing non-existent type fields.

The reason is that in order to prepare the arguments, for a call to a
Fortran function, we need to know the type of each argument.  If the
function being called has no debug information then obviously GDB
doesn't know about the argument types and we should either give the
user an error or pick a suitable default.  What we currently do is
just assume the field exist and access undefined memory, which is
clearly wrong.

The reason GDB needs to know the argument type is to tell if the
argument is artificial or not, artificial arguments will be passed by
value while non-artificial arguments will be passed by reference.

An ideal solution for this problem would be to allow the user to cast
the function to the correct type, we already do this to some degree
with the return value, for example:

  (gdb) print some_func_ ()
  'some_func_' has unknown return type; cast the call to its declared return type
  (gdb) print (integer) some_func_ ()
  $1 = 1

But if we could extend this to allow casting to the full function
type, GDB could figure out from the signature what are real
parameters, and what are artificial parameters.  Maybe something like
this:

  (gdb) print ((integer () (integer, double)) some_other_func_ (1, 2.3)

Alas, right now the Fortran expression parser doesn't seem to support
parsing function signatures, and we certainly don't have support for
figuring out real vs artificial arguments from a signature.

Still, I think we can prevent GDB from accessing undefined memory and
provide a reasonable default behaviour.

In this commit I:

  - Only ask if the argument is artificial if the type of the argument
  is actually known.

  - Unknown arguments are assumed to be artificial and passed by
  value (non-artificial arguments are pass by reference).

  - If an artificial argument is prefixed with '&' by the user then we
  treat the argument as pass-by-reference.

With these three changes we avoid undefined behaviour in GDB, and
allow the user, in most cases, to get a reasonably natural default
behaviour.

gdb/ChangeLog:

PR fortran/26155
* f-lang.c (fortran_argument_convert): Delete declaration.
(fortran_prepare_argument): New function.
(evaluate_subexp_f): Move logic to new function
fortran_prepare_argument.

gdb/testsuite/ChangeLog:

PR fortran/26155
* gdb.fortran/call-no-debug-func.f90: New file.
* gdb.fortran/call-no-debug-prog.f90: New file.
* gdb.fortran/call-no-debug.exp: New file.

3 years agogdb/fortran: add support for ASSOCIATED builtin
Andrew Burgess [Wed, 24 Feb 2021 12:50:00 +0000 (12:50 +0000)]
gdb/fortran: add support for ASSOCIATED builtin

This commit adds support for the ASSOCIATED builtin to the Fortran
expression evaluator.  The ASSOCIATED builtin takes one or two
arguments.

When passed a single pointer argument GDB returns a boolean indicating
if the pointer is associated with anything.

When passed two arguments the second argument should either be some a
pointer could point at or a second pointer.

If the second argument is a pointer target, then the result from
associated indicates if the pointer is pointing at this target.

If the second argument is another pointer, then the result from
associated indicates if the two pointers are pointing at the same
thing.

gdb/ChangeLog:

* f-exp.y (f77_keywords): Add 'associated'.
* f-lang.c (fortran_associated): New function.
(evaluate_subexp_f): Handle FORTRAN_ASSOCIATED.
(operator_length_f): Likewise.
(print_unop_or_binop_subexp_f): New function.
(print_subexp_f): Make use of print_unop_or_binop_subexp_f for
FORTRAN_ASSOCIATED, FORTRAN_LBOUND, and FORTRAN_UBOUND.
(dump_subexp_body_f): Handle FORTRAN_ASSOCIATED.
(operator_check_f): Likewise.
* std-operator.def: Add FORTRAN_ASSOCIATED.

gdb/testsuite/ChangeLog:

* gdb.fortran/associated.exp: New file.
* gdb.fortran/associated.f90: New file.

3 years agogdb/fortran: add support for legacy .xor. operator
Andrew Burgess [Wed, 24 Feb 2021 17:35:18 +0000 (17:35 +0000)]
gdb/fortran: add support for legacy .xor. operator

gfortran supports .xor. as an alias for .neqv., see:

  https://gcc.gnu.org/onlinedocs/gfortran/_002eXOR_002e-operator.html

this commit adds support for this operator to GDB.

gdb/ChangeLog:

* f-exp.y (fortran_operators): Add ".xor.".

gdb/testsuite/ChangeLog:

* gdb.fortran/dot-ops.exp (dot_operations): Test ".xor.".

3 years agoPR27441, inconsistency in weak definitions
Alan Modra [Wed, 24 Feb 2021 07:31:16 +0000 (18:01 +1030)]
PR27441, inconsistency in weak definitions

This makes IR objects use the same logic as normal objects with
respect to what sort of ref/def makes an as-needed library needed.
Testing the binding of the definition is just plain wrong.  What
matters is the binding of the reference.

PR 27441
* elf-bfd.h (struct elf_link_hash_entry): Add ref_ir_nonweak.
* elflink.c (elf_link_add_object_symbols): Set ref_ir_nonweak and
use when deciding an as-needed library should be loaded instead
of using the binding of the library definition.

3 years agoAutomatic date update in version.in
GDB Administrator [Thu, 25 Feb 2021 00:00:20 +0000 (00:00 +0000)]
Automatic date update in version.in

3 years agoRe: Use make_tempname file descriptor in smart_rename
Alan Modra [Wed, 24 Feb 2021 23:16:02 +0000 (09:46 +1030)]
Re: Use make_tempname file descriptor in smart_rename

PR 27456
* rename.c (simple_copy): Mark target_stat ATTRIBUTE_UNUSED.

3 years ago[gdb/symtab] Handle DW_AT_decl_file with form DW_FORM_implicit_const
Tom de Vries [Wed, 24 Feb 2021 22:58:42 +0000 (23:58 +0100)]
[gdb/symtab] Handle DW_AT_decl_file with form DW_FORM_implicit_const

With test-case gdb.cp/temargs.exp on target board \
unix/gdb:debug_flags=-gdwarf-5 I run into:
...
(gdb) info addr I^M
ERROR: GDB process no longer exists
GDB process exited with wait status 32286 exp19 0 0 CHILDKILLED SIGABRT SIGABRT
UNRESOLVED: gdb.cp/temargs.exp: test address of I in templ_m
...

This is a regression since commit 529908cbd0a "Remove DW_UNSND".

The problem is that this DW_AT_decl_file:
...
 <1><221>: Abbrev Number: 4 (DW_TAG_structure_type)
    <222>   DW_AT_name        : Base<double, 23, (& a_global), &S::f>
    <226>   DW_AT_byte_size   : 1
    <226>   DW_AT_decl_file   : 1
    <226>   DW_AT_decl_line   : 30
    <227>   DW_AT_sibling     : <0x299>
...
is not read by this code in new_symbol:
....
      attr = dwarf2_attr (die,
                          inlined_func ? DW_AT_call_file : DW_AT_decl_file,
                          cu);
      if (attr != nullptr && attr->form_is_unsigned ())
...
because DW_AT_decl_file has form DW_FORM_implicit_const:
...
   4      DW_TAG_structure_type    [has children]
    DW_AT_name         DW_FORM_strp
    DW_AT_byte_size    DW_FORM_implicit_const: 1
    DW_AT_decl_file    DW_FORM_implicit_const: 1
    DW_AT_decl_line    DW_FORM_data1
    DW_AT_sibling      DW_FORM_ref4
    DW_AT value: 0     DW_FORM value: 0
...
which is a signed LEB128, so attr->form_is_unsigned () returns false.

Fix this by introducing new functions is_nonnegative and as_nonnegative, and
use these instead of form_is_unsigned and as_unsigned.

Tested on x86_64-linux.

gdb/ChangeLog:

2021-02-24  Tom de Vries  <tdevries@suse.de>

PR symtab/27336
* dwarf2/attribute.c (attribute::form_is_signed): New function
factored out of ...
* dwarf2/attribute.h (attribute::as_signed): ... here.
(attribute::is_nonnegative, attribute::as_nonnegative): New function.
(attribute::form_is_signed): Declare.
* dwarf2/read.c (new_symbol): Use is_nonnegative and as_nonnegative
for DW_AT_decl_file.

3 years agoAdd comment regarding include order of <sys/ptrace.h> and <asm/ptrace.h>
Kevin Buettner [Wed, 24 Feb 2021 21:35:07 +0000 (14:35 -0700)]
Add comment regarding include order of <sys/ptrace.h> and <asm/ptrace.h>

gdb/ChangeLog:

* nat/aarch64-linux-hw-point.c: Add comment regarding include
order for <sys/ptrace.h> and <asm/ptrace.h>.

3 years agoFix aarch64-linux-hw-point.c build problem
Kevin Buettner [Wed, 24 Feb 2021 18:48:04 +0000 (11:48 -0700)]
Fix aarch64-linux-hw-point.c build problem

Due to a recent glibc header file change, the file
nat/aarch64-linux-hw-point.c no longer builds on Fedora rawhide.

An enum for PTRACE_SYSEMU is now provided by <sys/ptrace.h>.  In the
past, PTRACE_SYSEMU was defined only in <asm/ptrace.h>.  This is
what it looks like...

In <asm/ptrace.h>:

 #define PTRACE_SYSEMU   31

In <sys/ptrace.h>:

enum __ptrace_request
{
  ...
  PTRACE_SYSEMU = 31,
 #define PT_SYSEMU PTRACE_SYSEMU

  ...
}

When <asm/ptrace.h> and <sys/ptrace.h> are both included in a source
file, we run into the following build problem when the former is
included before the latter:

In file included from nat/aarch64-linux-hw-point.c:26:
/usr/include/sys/ptrace.h:86:3: error: expected identifier before numeric constant
   86 |   PTRACE_SYSEMU = 31,
      |   ^~~~~~~~~~~~~

(There are more errors after this one too.)

The file builds without error when <asm/ptrace.h> is included after
<sys/ptrace.h>.  I found that this is already done in
nat/aarch64-sve-linux-ptrace.h (which is included by
nat/aarch64-linux-ptrace.c).

I've tested this change on Fedora rawhide and Fedora 33, both
running on an aarch64 machine.

gdb/ChangeLog:

* nat/aarch64-linux-hw-point.c: Include <asm/ptrace.h> after
<sys/ptrace.h>.

3 years agogdb: use std::string instead of a fixed size buffer
Andrew Burgess [Fri, 19 Feb 2021 17:39:18 +0000 (17:39 +0000)]
gdb: use std::string instead of a fixed size buffer

The 'section' command uses a fixed size buffer into which a section
name is copied.  This commit replaces this with a use of std::string
so we can now display very long section names.

The expected results of one test need to be updated.

gdb/ChangeLog:

* exec.c (set_section_command): Move variable declarations into
the function body, and use std::string instead of a fixed size
buffer.

gdb/testsuite/ChangeLog:

* gdb.base/sect-cmd.exp: Update expected results.

3 years agogdb: move get_section_table from exec_target to dummy_target
Andrew Burgess [Fri, 12 Feb 2021 11:39:31 +0000 (11:39 +0000)]
gdb: move get_section_table from exec_target to dummy_target

The only target that implements target_ops::get_section_table in a
meaningful way is exec_target.  This target calls back into the
program space to return the current global section_table.

The global section table is populated whenever the user provides GDB
with an executable, or when a symbol file is loaded, e.g. when a
dynamic library is loaded, or when the user does add-symbol-file.

I recently ran into a situation where a user, debugging a remote
target, was not supplying GDB with a main executable at all.  Instead
the user attached to the target then did add-symbol-file, and then
proceeded to debug the target.

This works fine, but it was noticed that even when
trust-readonly-sections was on GDB was still accessing the target to
get the contents of readonly sections.

The problem is that by not providing an executable there was no
exec_target in the target stack, and so when GDB calls the
target_ops::get_section_table function GDB ends up in
dummy_target::get_section_table, which just returns NULL.

What I want is that even when GDB doesn't have an exec_target in the
target stack, a call to target_ops::get_section_table will still
return the section_table from the current program space.

When considering how to achieve this my first though was, why is the
request for the section table going via the target stack at all?  The
set of sections loaded is a property of the program space, not the
target.  This is, after all, why the data is being stored in the
program space.

So I initially tried changing target_get_section_table so that,
instead of calling into the target it just returns
current_program_space->target_sections ().

This would be fine except for one issue, target_bfd (from
bfd-target.c).  This code is used from solib-svr4.c to create a
temporary target_ops structure that implements two functions
target_bfd::xfer_partial and target_bfd::get_section_table.

The purpose behind the code is to enable two targets, ppc64 and frv to
decode function descriptors from the dynamic linker, based on the
non-relocated addresses from within the dynamic linker bfd object.

Both of the implemented functions in target_bfd rely on the target_bfd
object holding a section table, and the ppc64 target requires that the
target_bfd implement ::get_section_table.

The frv target doesn't require ::get_section_table, instead it
requires the ::xfer_partial.  We could in theory change the ppc64
target to use the same approach as frv, however, this would be a bad
idea.  I believe that the frv target approach is broken.  I'll
explain:

The frv target calls get_target_memory_unsigned to read the function
descriptor.  The address being read is the non-relocated address read
from the dynamic linker in solib-srv4.c:enable_break.  Calling
get_target_memory_unsigned eventually ends up in target_xfer_partial
with an object type of TARGET_OBJECT_RAW_MEMORY.  This will then call
memory_xfer_check_region.  I believe that it is quite possible that a
the non-relocated addresses pulled from the dynamic linker could be in
a memory region that is not readable, while the relocated addresses
are in a readable memory region.  If this was ever the case for the
frv target then GDB would reject the attempt to read the non-relocated
function pointer.

In contrast the ppc64 target calls target_section_by_addr, which calls
target_get_section_table, which then calls the ::get_section_table
function on the target.

Thus, when reflecting on target_bfd we see two functions,
::xfer_partial and ::get_section_table.  The former is required by the
frv target, but that target is (I think) potentially broken.  While
the latter is required by the ppc64 target, but this forces
::get_section_table to exist as a target_ops member function.

So my original plan, have target_get_section_table NOT call a
target_ops member function appears to be flawed.

My next idea was to remove exec_target::get_section_table, and instead
move the implementation into dummy_target::get_section_table.
Currently the dummy_target implementation always returns NULL
indicating no section table, but plenty of other dummy_target member
functions do more than just return null values.

So now, dummy_target::get_section_table returns the section table from
the current program space.  This allows target_bfd to remain
unchanged, so ppc64 and frv should not be affected.

Making this change removes the requirement for the user to provide an
executable, GDB can now always access the section_table, as the
dummy_target always exists in the target stack.

Finally, there's a test that the target_section table is not empty in
the case where the user does add-symbol-file without providing an
executable.

gdb/ChangeLog:

* exec.c (exec_target::get_section_table): Delete member function.
(section_table_read_available_memory): Use current_top_target, not
just the exec_ops target.
* target-delegates.c: Regenerate.
* target.c (default_get_section_table): New function.
* target.h (target_ops::get_section_table): Change default
behaviour to call default_get_section_table.
(default_get_section_table): Declare.

3 years agogdb: make the target_sections table private within program_space
Andrew Burgess [Fri, 12 Feb 2021 12:06:15 +0000 (12:06 +0000)]
gdb: make the target_sections table private within program_space

Following on from earlier commits which made access to the
target_sections table more 'const', this commit makes the table
private within the program_space class and provides member functions
to access the table.

Ideally I would have liked for the new target_sections member
function (on program_space) to return a 'const' reference to the table
within the program_space.  Unfortunately, there are two places in
solib-*.c, where code outside of the program_space class modifies the
target_sections table, and so to support this we need to return a
non-const reference.

There should be no user visible changes after this commit.

gdb/ChangeLog:

* exec.c (exec_target::close): Call new clear_target_sections
function.
(program_space::add_target_sections): Update name of member
variable.
(program_space::foreach_target_section): New function.
(program_space::add_target_sections): Update name of member
variable.
(program_space::remove_target_sections): Likewise.
(exec_one_fork): Use new target_sections member function.
(exec_target::get_section_table): Likewise.
(exec_target::files_info): Likewise.
(set_section_command): Use new foreach_target_section member
function.
(exec_set_section_address): Likewise.
(exec_target::has_memory): Use new target_sections member
function.
* progspace.h (program_space::clear_target_sections): New member
function.
(program_space::target_sections): Rename member variable to
m_target_sections, replace with a new member function.
(program_space::foreach_target_section): Declare new member
function.
(program_space::m_target_sections): New member variable.
* solib-dsbt.c (scan_dyntag): Use new member function.
* solib-svr4.c (scan_dyntag): Likewise.

3 years agogdb/testsuite: enable gdb.base/sect-cmd.exp test for all targets
Andrew Burgess [Fri, 19 Feb 2021 16:57:05 +0000 (16:57 +0000)]
gdb/testsuite: enable gdb.base/sect-cmd.exp test for all targets

During review of the next patch (which changes the 'section' command),
a bug was pointed out.  I wondered why no tests spotted this bug and I
found that the 'section' command test (sect-cmd.exp) is only run on
hppa targets!

In this commit I have given this test script a bit of a spring clean,
bringing it up to date with current testsuite style.  I have made some
of the patterns a little more robust, but in general my intention was
not to change the underlying meaning of any of these tests.

gdb/testsuite/ChangeLog:

* gdb.base/sect-cmd.exp: Rewrite using modern testsuite
techniques.  Enable the test for all targets.

3 years agogdb: spread a little 'const' through the target_section_table code
Andrew Burgess [Fri, 12 Feb 2021 11:39:23 +0000 (11:39 +0000)]
gdb: spread a little 'const' through the target_section_table code

The code to access the target section table can be made more const, so
lets do that.  There should be no user visible changes after this
commit.

gdb/ChangeLog:

* gdb/bfd-target.c (class target_bfd) <get_section_table>: Make
return type const.
* gdb/exec.c (struct exec_target) <get_section_table>: Likewise.
(section_table_read_available_memory): Make local const.
(exec_target::xfer_partial): Make local const.
(print_section_info): Make parameter const.
* gdb/exec.h (print_section_info): Likewise.
* gdb/ppc64-tdep.c (ppc64_convert_from_func_ptr_addr): Make local
const.
* gdb/record-btrace.c (record_btrace_target::xfer_partial):
Likewise.
* gdb/remote.c (remote_target::remote_xfer_live_readonly_partial):
Likewise.
* gdb/s390-tdep.c (s390_load): Likewise.
* gdb/solib-dsbt.c (scan_dyntag): Likewise.
* gdb/solib-svr4.c (scan_dyntag): Likewise.
* gdb/target-debug.h (target_debug_print_target_section_table_p):
Rename to...
(target_debug_print_const_target_section_table_p): ...this.
* gdb/target-delegates.c: Regenerate.
* gdb/target.c (target_get_section_table): Make return type const.
(target_section_by_addr): Likewise.  Also make some locals const.
(memory_xfer_partial_1): Make some locals const.
* gdb/target.h (struct target_ops) <get_section_table>: Make
return type const.
(target_section_by_addr): Likewise.
(target_get_section_table): Likewise.

3 years agogdb: add a new 'maint info target-sections' command
Andrew Burgess [Fri, 12 Feb 2021 16:10:56 +0000 (16:10 +0000)]
gdb: add a new 'maint info target-sections' command

We already have a command 'maint info sections', this command prints
all sections from all known object files.

However, GDB maintains a second section table internally.  This
section table is used when GDB wants to read directly from an object
file rather than actually reading memory on the target.  As such only
some sections (the allocatable ones) are added to this secondary
section table.

I recently ran into a situation where some of GDB's optimisations for
reading directly from the files were not working.  In 'maint info
sections' I could see that GDB knew about the object file, and did
know about the sections that it _should_ have been reading from.  But
I couldn't ask GDB which sections it had copied into its secondary
section table.

This commit adds a new command 'maint info target-sections' that fills
this gap.  This command lists only those sections that GDB has copied
into its secondary table.

You'll notice that the testsuite includes a comment indicating that
there's a bug in GDB.  Normally this is not something I would add to
the testsuite, instead we should raise an actual bugzilla bug and then
mark an xfail, however, a later patch in this series will remove this
comment once the actual bug in GDB is fixed.

gdb/ChangeLog:

* NEWS: Mention new 'maint info target-sections' command.
* maint.c (maintenance_info_target_sections): New function.
(_initialize_maint_cmds): Register new command.

gdb/doc/ChangeLog:

* gdb.texinfo (Files): Document new 'maint info target-sections'
command.

gdb/testsuite/ChangeLog:

* gdb.base/maint-info-sections.exp: Add new tests.
(check_maint_info_target_sections_output): New proc.

3 years agogdb/riscv: select rv32 target by default when requested
Andrew Burgess [Thu, 4 Feb 2021 18:34:13 +0000 (18:34 +0000)]
gdb/riscv: select rv32 target by default when requested

GDB for RISC-V always uses target descriptions.  When the target
doesn't provide a target description then a default is selected.
Usually this default is selected based on the properties of the
executable being debugged.  However, when there is no executable being
debugged we currently fallback to the riscv:rv64 target description as
the default.  This leads to strange behaviour like this:

  $ gdb
  (gdb) set architecture riscv:rv32
  (gdb) p sizeof ($pc)
  $1 = 8

Despite the users specifically setting the architecture to riscv:rv32
GDB still thinks that the target has riscv:rv64 register sizes.

The above is a bit of a contrived situation.  I actually ran into this
situation while trying to connect to a running riscv:rv32 target
without supplying an executable (the target didn't provide a target
description).  When I tried to set a register on the target I ran into
errors because GDB was passing 8 bytes to the target rather than the
expected 4.  Even when I manually specified the architecture (as
above) I couldn't convince GDB to only send 4 bytes.

This patch fixes this issue.  Now, when we selected a default target
description we will make use of the user selected architecture to
guide our choice.  In the above example we now get:

  $ gdb
  (gdb) set architecture riscv:rv32
  (gdb) p sizeof ($pc)
  $1 = 4

And my real world example of connecting to a remote without an
executable works fine.

I've used the fact that we can ask GDB about $pc even when no
executable is loaded as the basis for a test to cover this situation.

gdb/ChangeLog:

* riscv-tdep.c (riscv_features_from_gdbarch_info): Rename to...
(riscv_features_from_bfd): ...this.  Change parameter type to
'bfd*', and update as required.
(riscv_find_default_target_description): Update call to
riscv_features_from_bfd.  Select a default xlen based on
info.bfd_arch_info.
(riscv_gdbarch_init): Update call to riscv_features_from_bfd.

gdb/testsuite/ChangeLog:

* gdb.arch/riscv-default-tdesc.exp: New file.

3 years agogdb: call value_ind for pointers to dynamic types in UNOP_IND evaluation
Andrew Burgess [Fri, 8 Jan 2021 14:00:45 +0000 (14:00 +0000)]
gdb: call value_ind for pointers to dynamic types in UNOP_IND evaluation

When evaluating and expression containing UNOP_IND in mode
EVAL_AVOID_SIDE_EFFECTS, GDB currently (mostly) returns the result of
a call to value_zero meaning we get back an object with the correct
type, but its contents are all zero.

If the target type contains fields with dynamic type then in order to
resolve these dynamic fields GDB will need to read the value of the
field from within the parent object.  In this case the field value
will be zero as a result of the call to value_zero mentioned above.

The idea behind EVAL_AVOID_SIDE_EFFECTS is to avoid the chance that
doing something like `ptype` will modify state within the target, for
example consider: ptype i++.

However, there is already precedence within GDB that sometimes, in
order to get accurate type results, we can't avoid reading from the
target, even when EVAL_AVOID_SIDE_EFFECTS is in effect.  For example I
would point to eval.c:evaluate_var_value, the handling of OP_REGISTER,
the handling of value_x_unop in many places.  I believe the Ada
expression evaluator also ignore EVAL_AVOID_SIDE_EFFECTS in some
cases.

I am therefor proposing that, in the case where a pointer points at a
dynamic type, we allow UNOP_IND to perform the actual indirection.
This allows accurate types to be displayed in more cases.

gdb/ChangeLog:

* eval.c (evaluate_subexp_standard): Call value_ind for points to
dynamic types in UNOP_IND.

gdb/testsuite/ChangeLog:

* gdb.fortran/pointer-to-pointer.exp: Additional tests.

3 years agoFix a potential integer overflow when adding together section sizes for the AVR port...
Nick Clifton [Wed, 24 Feb 2021 14:14:45 +0000 (14:14 +0000)]
Fix a potential integer overflow when adding together section sizes for the AVR port of objdump.

PR 27285
* od-elf32_avr.c (elf32_avr_get_memory_usage): Check for overflows
when adding together the section sizes.

3 years agoRemove support for old v1 & v2 style GNU build notes.
Nick Clifton [Wed, 24 Feb 2021 10:08:56 +0000 (10:08 +0000)]
Remove support for old v1 & v2 style GNU build notes.

* objcopy.c (merge_gnu_build_notes): Remove support for v1/v2 GNU
build notes.
* readelf.c (print_gnu_build_attribute_description): Likewise.

3 years agoPR27459, segmentation fault in go32exe_check_format
Alan Modra [Wed, 24 Feb 2021 00:22:47 +0000 (10:52 +1030)]
PR27459, segmentation fault in go32exe_check_format

PR 27459
* coff-stgo32.c (go32exe_check_format): Sanity check size of
header to avoid a buffer overflow.

3 years agoAutomatic date update in version.in
GDB Administrator [Wed, 24 Feb 2021 00:00:15 +0000 (00:00 +0000)]
Automatic date update in version.in

3 years agoPR23691, gas .y files vs. automatic make dependencies
Alan Modra [Tue, 23 Feb 2021 11:24:25 +0000 (21:54 +1030)]
PR23691, gas .y files vs. automatic make dependencies

A number of targets, bfin, rl78, rx, can show odd failures when
bfd/reloc.c changes BFD_RELOC_* enum values, if recompiling over a
build dir with existing objects.  The problem is caused by
bfin-parse.o and similar not being recompiled and so using stale
BFD_RELOC_* values.  This isn't fixed by making bfin-parse.c depend on
bfd/reloc.c, which isn't necessary anyway.  bfin-parse.o should have
been recompiled due to bfd/bfd.h changing when extracted bfd/reloc.c
BFD_RELOC_* values change, but that wasn't happening.  The problem is
that automake generates a makefile that loads gas/config/.deps/
dependency file for objects with corresponding sources mentioned in
EXTRA_as_new_SOURCES.  Unless we want to mess around generating
explicit dependencies, I think that mean moving some object files to
the build gas/config/.  This patch does that, removing some hacks for
m68k-parse.c that should no longer be necessary, and removes some
rules that catered to old bison producing code that triggers compiler
warnings.

PR 23691
* Makefile.am (TARGET_CPU_CFILES): Split off config/xtensa-relax.c..
(TARGET_CPU_HFILES): ..and config/xtensa-relax.h..
(TARGET_EXTRA_FILES): ..to here.  Add config/bfin-lex-wrapper.c,
and use alongside TARGET_CPU_CFILES.
(EXTRA_DIST): Update location of generated .c files.
(config/m68k-parse.c): New rule replacing m68k-parse.c rule.
(config/bfin-parse.c, config/rl78-parse.cm config/rx-parse.c),
(config/bfin-lex.c, config/bfin-lex-wrapper.@OBJEXT@): Similarly.
(itbl-lex-wrapper.@OBJEXT@): Simplify to just the needed
dependencies.
(itbl-parse.@OBJEXT@): Delete rule using NO_WERROR.
(itbl-parse.c, itbl-parse.h): Tidy.
* config/bfin-lex-wrapper.c: Include config/bfin-lex.c.
* config/bfin-lex.l: Include config/bfin-parse.h.
* configure.ac (extra_objects): Move object files corresponding
to .y and .l files now in config/ to config/.
* Makefile.in: Regenerate.
* configure: Regenerate.
* po/POTFILES.in: Regenerate.

3 years agoUse make_tempname file descriptor in smart_rename
Alan Modra [Tue, 23 Feb 2021 01:40:58 +0000 (12:10 +1030)]
Use make_tempname file descriptor in smart_rename

This patch makes use of the temp file descriptor in smart_rename
rather than reopening the file.  I don't believe there is a security
issue in reopening the file, but this way is one less directory
operation.  The patch also attempts to preserve S_ISUID and S_ISGID.

PR 27456
* bucomm.h (smart_rename): Update prototype.
* rename.c (smart_rename): Add fromfd and preserve_dates params.
Pass fromfd and target_stat to simple_copy.  Call set_times
when preserve_dates.
(simple_copy): Accept fromfd rather than from filename.  Add
target_stat param.  Rewind fromfd rather than opening.  Open
"to" file without O_CREAT.  Try to preserve S_ISUID and S_ISGID.
* ar.c (write_archive): Rename ofd to tmpfd.  Dup tmpfd before
closing output temp file, and pass tmpfd to smart_rename.
* arsup.c (temp_fd): Rename from real_fd.
(ar_save): Dup temp_fd and pass to smart_rename.
* objcopy.c (strip_main, copy_main): Likewise, and pass
preserve_dates.

3 years agoPR27456, lstat in rename.c on MinGW
Alan Modra [Mon, 22 Feb 2021 23:07:39 +0000 (09:37 +1030)]
PR27456, lstat in rename.c on MinGW

PR 27456
* rename.c: Tidy throughout.
(smart_rename): Always copy.  Remove windows specific code.

3 years agogdb/dwarf: create and destroy dwarf2_per_bfd's CUs-to-expand queue
Simon Marchi [Tue, 23 Feb 2021 18:37:44 +0000 (13:37 -0500)]
gdb/dwarf: create and destroy dwarf2_per_bfd's CUs-to-expand queue

As described in the log of patch "gdb/dwarf: add assertion in
maybe_queue_comp_unit", it would happen that a call to
maybe_queue_comp_unit would enqueue a CU in the to-expand queue while
nothing up the stack was processing the queue.  This is not desirable,
as items are then left lingering in the queue when we exit the
dwarf2/read code.  This is an inconsistent state.

The normal case of using the queue is when we go through
dw2_do_instantiate_symtab and process_queue.  As depended-on CUs are
found, they get added to the queue.  process_queue expands CUs until the
queue is empty.

To catch these cases where things are enqueued while nothing up the
stack is processing the queue, change dwarf2_per_bfd::queue to be an
optional.  The optional is instantiated in dwarf2_queue_guard, just
before where we call process_queue.  In the dwarf2_queue_guard
destructor, the optional gets reset.  Therefore, the queue object is
instantiated only when something up the stack is handling it.  If
another entry point tries to enqueue a CU for expansion, an assertion
will fail and we know we have something to fix.

dwarf2_queue_guard sounds like the good place for this, as it's
currently responsible for making sure the queue gets cleared if we exit
due to an error.

This also allows asserting that when age_comp_units or remove_all_cus
run, the queue is not instantiated, and gives us one more level of
assurance that we won't free the DIEs of a CU that is in the
CUs-to-expand queue.

gdb/ChangeLog:

PR gdb/26828
* dwarf2/read.c (dwarf2_queue_guard) <dwarf2_queue_guard>:
Instantiate queue.
(~dwarf2_queue_guard): Clear queue.
(queue_comp_unit): Assert that queue is
instantiated.
(process_queue): Adjust.
* dwarf2/read.h (struct dwarf2_per_bfd) <queue>: Make optional.

Change-Id: I8fe3d77845bb4ad3d309eac906acebe79d9f0a9d

3 years agogdb/dwarf: don't enqueue CU in maybe_queue_comp_unit if already expanded
Simon Marchi [Tue, 23 Feb 2021 17:07:10 +0000 (12:07 -0500)]
gdb/dwarf: don't enqueue CU in maybe_queue_comp_unit if already expanded

The previous commit log described how items could be left lingering in
the dwarf2_per_bfd::queue and how that could cause trouble.

This patch fixes the issue by changing maybe_queue_comp_unit so that it
doesn't put a CU in the to-expand queue if that CU is already expanded.
This will make it so that when dwarf2_fetch_die_type_sect_off calls
follow_die_offset and maybe_queue_comp_unit, it won't enqueue the target
CU, because it will see the CU is already expanded.

This assumes that if a CU is dwarf2_fetch_die_type_sect_off's target CU,
it will have previously been expanded.  I think it is the case, but I
can't be 100% sure.  If that's not true, the assertions added in the
following patch will catch it, and it means we'll have to re-think a bit
more how things work (it wouldn't be well handled at all today anyway).

This fixes something else in maybe_queue_comp_unit that looks wrong.
Imagine the DIEs of a CU are loaded in memory, but that CU is not
expanded.  In that case, maybe_queue_comp_unit will use this early
return:

  /* If the compilation unit is already loaded, just mark it as
     used.  */
  dwarf2_cu *cu = per_objfile->get_cu (per_cu);
  if (cu != nullptr)
    {
      cu->last_used = 0;
      return 0;
    }

... so the CU won't be queued for expansion.  Whether the DIEs of a CU
are loaded in memory and whether that CU is expanded are two orthogonal
things, but that function appears to mix them.  So, move the queuing
above that check / early return, so that if the CU's DIEs are loaded in
memory but the CU is not expanded yet, it gets enqueued.

I tried to improve maybe_queue_comp_unit's documentation to clarify what
the return value means.  By clarifying this, I noticed that two callers
(follow_die_offset and follow_die_sig_1) access the CU's DIEs after
calling maybe_queue_comp_unit, only relying on maybe_queue_comp_unit's
return value to tell whether DIEs need to be loaded first or not.  As
explained in the new comment, this is problematic:
maybe_queue_comp_unit's return value doesn't tell whether DIEs are
currently loaded, it means whether maybe_queue_comp_unit requires the
caller to load them.  If the CU is already expanded but the DIEs to have
been freed, maybe_queue_comp_unit returns 0, meaning "I don't need you
to load the DIEs".  So if these two functions (follow_die_offset and
follow_die_sig_1) need to access the DIEs in any case, for their own
usage, they should make sure to load them if they are not loaded
already.  I therefore added an extra check to the condition they use,
making it so they will always load the DIEs if they aren't already.

From what I found, other callers don't care for the CU's DIEs, they call
maybe_queue_comp_unit to ensure the CU gets expanded eventually, but
don't care for it after that.

gdb/ChangeLog:

PR gdb/26828
* dwarf2/read.c (maybe_queue_comp_unit): Check if CU is expanded
to decide whether or not to enqueue it for expansion.
(follow_die_offset, follow_die_sig_1): Ensure we load the DIEs
after calling maybe_queue_comp_unit.

Change-Id: Id98c6b60669f4b4b21b9be16d0518fc62bdf686a

3 years agogdbserver: linux-low: make linux_process_target::filter_event return void
Simon Marchi [Tue, 23 Feb 2021 15:56:56 +0000 (10:56 -0500)]
gdbserver: linux-low: make linux_process_target::filter_event return void

Same as the previous patch, but for GDBserver.  The return value of this
method is never used, change it to return void.

gdbserver/ChangeLog:

* linux-low.cc (linux_process_target::filter_event): Return
void.
* linux-low.h (class linux_process_target) <filter_event>:
Return void.

Change-Id: I79e5dc04d9b21b9f01c6d675fa463d1b1a703b3a

3 years agogdb: linux-nat: make linux_nat_filter_event return void
Simon Marchi [Tue, 23 Feb 2021 15:56:41 +0000 (10:56 -0500)]
gdb: linux-nat: make linux_nat_filter_event return void

I noticed that linux_nat_filter_event returns a value, but its caller
doesn't use it.  This has been since 9c02b52532ac ("linux-nat.c: better
starvation avoidance, handle non-stop mode too").  Before that commit,
the return value was used to tell the caller whether to continue
processing that event or not.  But since then, the model is that we pull
all events from the kernel and linux_nat_filter_event just saves the
status to the lwp_info structure if it thinks it's relevant.  And the
caller, linux_nat_wait_1, selects a status at random amongst the threads
with a pending status.  So essentially, the return value of
linux_nat_filter_event does not have a reason to be anymore.  Change it
so it returns void.

gdb/ChangeLog:

* linux-nat.c (linux_nat_filter_event): Return void.

Change-Id: I35662868910f5122772ed92a512adfbf4da12d87

3 years agoAutomatic date update in version.in
GDB Administrator [Tue, 23 Feb 2021 00:00:07 +0000 (00:00 +0000)]
Automatic date update in version.in

3 years agoChange target_bfd_reopen to take a gdb_bfd_ref_ptr
Tom Tromey [Mon, 22 Feb 2021 16:47:37 +0000 (09:47 -0700)]
Change target_bfd_reopen to take a gdb_bfd_ref_ptr

While looking at Andrew's recent target sections series, I saw that
target_bfd_reopen took a "bfd *", leading to a call to new_reference.
However, because the only caller of target_bfd_reopen is already using
gdb_bfd_ref_ptr, this code can be simplified and the explicit call to
new_reference can be removed.

gdb/ChangeLog
2021-02-22  Tom Tromey  <tromey@adacore.com>

* solib-svr4.c (enable_break): Update.
* bfd-target.c (class target_bfd) <target_bfd>: Change parameter
type.
(target_bfd_reopen): Change parameter type.
* bfd-target.h (target_bfd_reopen): Change parameter type.

3 years agogdb: add asserts in thread code
Simon Marchi [Mon, 22 Feb 2021 16:42:03 +0000 (11:42 -0500)]
gdb: add asserts in thread code

Unlike the previous patch, I don't propose that we take this patch into
gdb-10-branch.

This patch adds two asserts, prompted by investigating and fixing the
bug fixed by the previous patch.

The assert in find_thread_ptid would have caught the original issue
before the segfault (I think it's slightly more use friendly).

The assert in add_thread_silent would have made it clear that the
solution proposed in [1] isn't the right one.  The solution ended up
passing nullptr as a target to add_thread.  We don't want that, because
add_thread_silent uses it to look up the inferior to which to add the
thread.  If the target is nullptr, we could find an inferior with the
same pid, but belonging to an unrelated target.  So we always want a
non-nullptr target in add_thread_silent.

gdb/ChangeLog:

* thread.c (add_thread_silent): Add assert.
(find_thread_ptid): Add assert.

[1] https://sourceware.org/pipermail/gdb-patches/2021-February/176202.html

Change-Id: Ie593ee45c5eb02235e8e9fbcda612d48ce883852

3 years agogdb: push target earlier in procfs_target::attach (PR 27435)
Simon Marchi [Mon, 22 Feb 2021 16:41:32 +0000 (11:41 -0500)]
gdb: push target earlier in procfs_target::attach (PR 27435)

Since this is a GDB 9 -> 10 regression, I would like to push it to
gdb-10-branch.

This is a follow-up to:

  https://sourceware.org/pipermail/gdb-patches/2021-February/176202.html

This patch fixes a segfault seen when attaching to a process on Solaris.
The steps leading to the segfault are:

 - procfs_target::attach calls do_attach, at this point the inferior's
   process slot in the target stack is empty.
 - do_attach adds a thread with `add_thread (&the_procfs_target, ptid)`
 - in add_thread_silent, the passed target (&the_procfs_target) is
   passed to find_inferior_ptid
 - find_inferior_ptid returns nullptr, as there is no inferior with this
   ptid that has &the_procfs_target as its process target
 - the nullptr `inf` is passed to find_thread_ptid, which dereferences
   it, causing a segfault
 - back in procfs_target::attach, after do_attach, we push the
   the_procfs_target on the inferior's target stack, although we never
   reach this because the segfault happens before.

To fix this, I think we need to do the same as is done in
inf_ptrace_target::attach: push the target early and unpush it in case
the attach fails (and keep it if the attach succeeds).

Implement it by moving target_unpush_up to target.h, so it can be
re-used here.  Make procfs_target::attach use it.  Note that just like
is mentioned in inf_ptrace_target::attach, we should push the target
before calling target_pid_to_str, so that calling target_pid_to_str ends
up in procfs_target::pid_to_str.

Tested by trying to attach on a process on gcc211 on the gcc compile
farm.

gdb/ChangeLog:

PR gdb/27435
* inf-ptrace.c (struct target_unpusher): Move to target.h.
(target_unpush_up): Likewise.
* procfs.c (procfs_target::attach): Push target early.  Use
target_unpush_up to unpush target in case of error.
* target.h (struct target_unpusher): Move here.
(target_unpush_up): Likewise.

Change-Id: I88aff8b20204e1ca1d792e27ac6bc34fc1aa0d52

3 years agoDon't handle BFD_RELOC_16 in XCOFF reloc_type_lookup
Alan Modra [Mon, 22 Feb 2021 03:29:34 +0000 (13:59 +1030)]
Don't handle BFD_RELOC_16 in XCOFF reloc_type_lookup

It's not needed for sizing fixups since 0e2779e98dc, and wrong to emit
this reloc to the object file.

* coff-rs6000.c (_bfd_xcoff_reloc_type_lookup): Remove BFD_RELOC_16.
* coff64-rs6000.c (xcoff64_reloc_type_lookup): Likewise.

3 years agoAutomatic date update in version.in
GDB Administrator [Mon, 22 Feb 2021 00:00:14 +0000 (00:00 +0000)]
Automatic date update in version.in

3 years agosim: common: split up acinclude.m4 into individual m4 files
Mike Frysinger [Sun, 7 Feb 2021 03:51:30 +0000 (22:51 -0500)]
sim: common: split up acinclude.m4 into individual m4 files

This file is quite large and is getting unmanageable.  Split it apart
to follow aclocal best practices by putting one-macro-per-file.  There
shouldn't be any real functional changes here as can be seen in the
configure script regens.

3 years agoWarn when a script redefines a symbol
Alan Modra [Sat, 20 Feb 2021 05:15:44 +0000 (15:45 +1030)]
Warn when a script redefines a symbol

Note that we don't even warn if scripts adjust a symbol as in
ld-elf/var1 and ld-scripts/pr14962.

include/
* bfdlink.h (struct bfd_link_info): Add warn_multiple_definition.
ld/
* ldexp.c (exp_fold_tree_1): Warn on script defining a symbol
defined in an object file.
* ldmain.c (multiple_definition): Heed info->warn_multiple_definition.
* testsuite/ld-scripts/defined5.d: Expect a warning.

3 years agolibctf AC_CANONICAL_TARGET
Alan Modra [Sat, 20 Feb 2021 07:35:20 +0000 (18:05 +1030)]
libctf AC_CANONICAL_TARGET

AC_CANONICAL_TARGET is needed for @target@ substitution in the
makefile.  AC_CANONICAL_HOST and AC_CANONICAL_BUILD are alread invoked
indirectly, make them explicit.

* configure.ac: Invoke AC_CANONICAL_TARGET, AC_CANONICAL_HOST
and AC_CANONICAL_BUILD.
* configure: Regenerate.
* Makefile.in: Regenerate.

3 years agoAutomatic date update in version.in
GDB Administrator [Sun, 21 Feb 2021 00:00:15 +0000 (00:00 +0000)]
Automatic date update in version.in

3 years agolibctf: add a NEWS
Nick Alcock [Wed, 17 Feb 2021 17:02:02 +0000 (17:02 +0000)]
libctf: add a NEWS

I'm dividing this into three groups for now: new features, bugfixes,
and bugfixes also present on a stable branch.

Only user-visible bugfixes, not build-system fixes, are listed.

3 years agolibctf, include: find types of symbols by name
Nick Alcock [Wed, 17 Feb 2021 15:21:12 +0000 (15:21 +0000)]
libctf, include: find types of symbols by name

The existing ctf_lookup_by_symbol and ctf_arc_lookup_symbol functions
suffice to look up the types of symbols if the caller already has a
symbol number.  But the caller often doesn't have one of those and only
knows the name of the symbol: also, in object files, the caller might
not have a useful symbol number in any sense (and neither does libctf:
the 'symbol number' we use in that case literally starts at 0 for the
lexicographically first-sorted symbol in the symtypetab and counts those
symbols, so it corresponds to nothing useful).

This means that even though object files have a symtypetab (generated by
the compiler or by ld -r), the only way we can look up anything in it is
to iterate over all symbols in turn with ctf_symbol_next until we find
the one we want.

This is unhelpful and pointlessly inefficient.

So add a pair of functions to look up symbols by name in a dict and in a
whole archive: ctf_lookup_by_symbol_name and ctf_arc_lookup_symbol_name.
These are identical to the existing functions except that they take
symbol names rather than symbol numbers.

To avoid insane repetition, we do some refactoring in the process, so
that both ctf_lookup_by_symbol and ctf_arc_lookup_symbol turn into thin
wrappers around internal functions that do both lookup by symbol index
and lookup by name.  This massively reduces code duplication because
even the existing lookup-by-index stuff wants to use a name sometimes
(when looking up in indexed sections), and the new lookup-by-name stuff
has to turn it into an index sometimes (when looking up in non-indexed
sections): doing it this way lets us share most of that.

The actual name->index lookup is done by ctf_lookup_symbol_idx.  We do
not anticipate this lookup to be as heavily used as ld.so symbol lookup
by many orders of magnitude, so using the ELF symbol hashes would
probably take more time to read them than is saved by using the hashes,
and it adds a lot of complexity.  Instead, do a linear search for the
symbol name, caching all the name -> index mappings as we go, so that
future searches are likely to hit in the cache.  To avoid having to
repeat this search over and over in a CTF archive when
ctf_arc_lookup_symbol_name is used, have cached archive lookups (the
sort done by ctf_arc_lookup_symbol* and the ctf_archive_next iterator)
pick out the first dict they cache in a given archive and store it in a
new ctf_archive field, ctfi_crossdict_cache.  This can be used to store
cross-dictionary cached state that depends on things like the ELF symbol
table rather than the contents of any one dict.  ctf_lookup_symbol_idx
then caches its name->index mappings in the dictionary named in the
crossdict cache, if any, so that ctf_lookup_symbol_idx in other dicts
in the same archive benefit from the previous linear search, and the
symtab only needs to be scanned at most once.

(Note that if you call ctf_lookup_by_symbol_name in one specific dict,
and then follow it with a ctf_arc_lookup_symbol_name, the former will
not use the crossdict cache because it's only populated by the dict
opens in ctf_arc_lookup_symbol_name. This is harmless except for a small
one-off waste of memory and time: it's only a cache, after all.  We can
fix this later by using the archive caching machinery more
aggressively.)

In ctf-archive, we do similar things, turning ctf_arc_lookup_symbol into
a wrapper around a new function that does both index -> ID and name ->
ID lookups across all dicts in an archive.  We add a new
ctfi_symnamedicts cache that maps symbol names to the ctf_dict_t * that
it was found in (so that linear searches for symbols don't need to be
repeated): but we also *remove* a cache, the ctfi_syms cache that was
memoizing the actual ctf_id_t returned from every call to
ctf_arc_lookup_symbol.  This is pointless: all it saves is one call to
ctf_lookup_by_symbol, and that's basically an array lookup and nothing
more so isn't worth caching.  (Equally, given that symbol -> index
mappings are cached by ctf_lookup_by_symbol_name, those calls are nearly
free after the first call, so there's no point caching the ctf_id_t in
that case either.)

We fix up one test that was doing manual symbol lookup to use
ctf_arc_lookup_symbol instead, and enhance it to check that the caching
layer is not totally broken: we also add a new test to do lookups in a
.o file, and another to do lookups in an archive with conflicted types
and make sure that sort of multi-dict lookup is actually working.

include/ChangeLog
2021-02-17  Nick Alcock  <nick.alcock@oracle.com>

* ctf-api.h (ctf_arc_lookup_symbol_name): New.
(ctf_lookup_by_symbol_name): Likewise.

libctf/ChangeLog
2021-02-17  Nick Alcock  <nick.alcock@oracle.com>

* ctf-impl.h (ctf_dict_t) <ctf_symhash>: New.
<ctf_symhash_latest>: Likewise.
(struct ctf_archive_internal) <ctfi_crossdict_cache>: New.
<ctfi_symnamedicts>: New.
<ctfi_syms>: Remove.
(ctf_lookup_symbol_name): Remove.
* ctf-lookup.c (ctf_lookup_symbol_name): Propagate errors from
parent properly.  Make static.
(ctf_lookup_symbol_idx): New, linear search for the symbol name,
cached in the crossdict cache's ctf_symhash (if available), or
this dict's (otherwise).
(ctf_try_lookup_indexed): Allow the symname to be passed in.
(ctf_lookup_by_symbol): Turn into a wrapper around...
(ctf_lookup_by_sym_or_name): ... this, supporting name lookup too,
using ctf_lookup_symbol_idx in non-writable dicts.  Special-case
name lookup in dynamic dicts without reported symbols, which have
no symtab or dynsymidx but where name lookup should still work.
(ctf_lookup_by_symbol_name): New, another wrapper.
* ctf-archive.c (enosym): Note that this is present in
ctfi_symnamedicts too.
(ctf_arc_close): Adjust for removal of ctfi_syms.  Free the
ctfi_symnamedicts.
(ctf_arc_flush_caches): Likewise.
(ctf_dict_open_cached): Memoize the first cached dict in the
crossdict cache.
(ctf_arc_lookup_symbol): Turn into a wrapper around...
(ctf_arc_lookup_sym_or_name): ... this.  No longer cache
ctf_id_t lookups: just call ctf_lookup_by_symbol as needed (but
still cache the dicts those lookups succeed in).  Add
lookup-by-name support, with dicts of successful lookups cached in
ctfi_symnamedicts.  Refactor the caching code a bit.
(ctf_arc_lookup_symbol_name): New, another wrapper.
* ctf-open.c (ctf_dict_close): Free the ctf_symhash.
* libctf.ver (LIBCTF_1.2): New version.  Add
ctf_lookup_by_symbol_name, ctf_arc_lookup_symbol_name.
* testsuite/libctf-lookup/enum-symbol.c (main): Use
ctf_arc_lookup_symbol rather than looking up the name ourselves.
Fish it out repeatedly, to make sure that symbol caching isn't
broken.
(symidx_64): Remove.
(symidx_32): Remove.
* testsuite/libctf-lookup/enum-symbol-obj.lk: Test symbol lookup
in an unlinked object file (indexed symtypetab sections only).
* testsuite/libctf-writable/symtypetab-nonlinker-writeout.c
(try_maybe_reporting): Check symbol types via
ctf_lookup_by_symbol_name as well as ctf_symbol_next.
* testsuite/libctf-lookup/conflicting-type-syms.*: New test of
lookups in a multi-dict archive.

3 years agosim: merge configure.tgt into configure.ac
Mike Frysinger [Sat, 16 Jan 2021 05:03:32 +0000 (00:03 -0500)]
sim: merge configure.tgt into configure.ac

One fewer file to worry about & manage.

3 years agoreadelf: Replace procesor with processor
H.J. Lu [Sat, 20 Feb 2021 13:55:42 +0000 (05:55 -0800)]
readelf: Replace procesor with processor

binutils/

PR binutils/27445
* readelf.c (print_gnu_property_note): Replace procesor with
processor.

ld/

PR binutils/27445
* testsuite/ld-i386/property-x86-isa1.d: Replace procesor with
processor.
* testsuite/ld-x86-64/property-x86-isa1-x32.d: Likewise.
* testsuite/ld-x86-64/property-x86-isa1.d: Likewise.

3 years agoFail run_dump_test when an error is expected but not seen
Alan Modra [Sat, 20 Feb 2021 05:12:22 +0000 (15:42 +1030)]
Fail run_dump_test when an error is expected but not seen

* testsuite/lib/binutils-common.exp: Whitespace fixes throughout.
(run_dump_test): Fail if expecting errors from a file like we do
for error strings, if no error is seen.

3 years agoInclude ld-lib.exp from ctf-lib.exp
Alan Modra [Thu, 18 Feb 2021 10:18:16 +0000 (20:48 +1030)]
Include ld-lib.exp from ctf-lib.exp

* testsuite/config/default.exp (ld_L_opt): Define.
* testsuite/lib/ctf-lib.exp (load_common_lib): Delete.  Instead load
ld-lib.exp.
(run_host_cmd, run_host_cmd_yesno, check_compiler_available): Delete.
(compile_one_cc, check_ctf_available): Delete.

3 years agoAutomatic date update in version.in
GDB Administrator [Sat, 20 Feb 2021 00:00:18 +0000 (00:00 +0000)]
Automatic date update in version.in

3 years agoFix compile time warnings when building riscv assembler.
Nick Clifton [Fri, 19 Feb 2021 10:14:09 +0000 (10:14 +0000)]
Fix compile time warnings when building riscv assembler.

* config/tc-riscv.c (riscv_ip): Fix compile time warnings about
misleading indentation.

3 years agoamd64-linux-siginfo.c: Adjust include order to avoid gnulib error
Kevin Buettner [Fri, 19 Feb 2021 05:46:58 +0000 (22:46 -0700)]
amd64-linux-siginfo.c: Adjust include order to avoid gnulib error

On Fedora rawhide, after updating to glibc-2.33, I'm seeing the
following build failure:

  CXX    nat/amd64-linux-siginfo.o
In file included from /usr/include/bits/sigstksz.h:24,
                 from /usr/include/signal.h:315,
                 from ../gnulib/import/signal.h:52,
                 from /ironwood1/sourceware-git/rawhide-gnulib/bld/../../worktree-gnulib/gdbserver/../gdb/nat/amd64-linux-siginfo.c:20:
../gnulib/import/unistd.h:663:3: error: #error "Please include config.h first."
  663 |  #error "Please include config.h first."
      |   ^~~~~

glibc-2.33 has changed signal.h to now include <bits/sigstksz.h> which,
in turn, includes <unistd.h>. For a gdb build, this causes the gnulib
version of unistd.h to be pulled in first.  The build failure shown
above happens because gnulib's config.h has not been included before
the include of <signal.h>.

The fix is simple - we just rearrange the order of the header file
includes to make sure that gdbsupport/commondefs.h is included before
attempting to include signal.h.  Note that gdbsupport/commondefs.h
includes <gnulib/config.h>.

Build and regression tested on Fedora 33.  On Fedora rawhide, GDB
builds again.

gdb/ChangeLog:

* nat/amd64-linux-siginfo.c: Include "gdbsupport/common-defs.h"
(which in turn includes <gnulib/config.h>) before include
of <signal.h>.

3 years agoRISC-V: PR27158, fixed UJ/SB types and added CSS/CL/CS types for .insn.
Nelson Chu [Tue, 26 Jan 2021 10:02:38 +0000 (18:02 +0800)]
RISC-V: PR27158, fixed UJ/SB types and added CSS/CL/CS types for .insn.

* Renamed obsolete UJ/SB types and RVC types, also added CSS/CL(CS) types,

[VALID/EXTRACT/ENCODE macros]
BTYPE_IMM:            Renamed from SBTYPE_IMM.
JTYPE_IMM:            Renamed from UJTYPE_IMM.
CITYPE_IMM:           Renamed from RVC_IMM.
CITYPE_LUI_IMM:       Renamed from RVC_LUI_IMM.
CITYPE_ADDI16SP_IMM:  Renamed from RVC_ADDI16SP_IMM.
CITYPE_LWSP_IMM:      Renamed from RVC_LWSP_IMM.
CITYPE_LDSP_IMM:      Renamed from RVC_LDSP_IMM.
CIWTYPE_IMM:          Renamed from RVC_UIMM8.
CIWTYPE_ADDI4SPN_IMM: Renamed from RVC_ADDI4SPN_IMM.
CSSTYPE_IMM:          Added for .insn without special encoding.
CSSTYPE_SWSP_IMM:     Renamed from RVC_SWSP_IMM.
CSSTYPE_SDSP_IMM:     Renamed from RVC_SDSP_IMM.
CLTYPE_IMM:           Added for .insn without special encoding.
CLTYPE_LW_IMM:        Renamed from RVC_LW_IMM.
CLTYPE_LD_IMM:        Renamed from RVC_LD_IMM.
RVC_SIMM3:            Unused and removed.
CBTYPE_IMM:           Renamed from RVC_B_IMM.
CJTYPE_IMM:           Renamed from RVC_J_IMM.

* Added new operands and removed the unused ones,

C5: Unsigned CL(CS) immediate, added for .insn directive.
C6: Unsigned CSS immediate, added for .insn directive.
Ci: Unused and removed.
C<: Unused and removed.

bfd/
    PR 27158
    * elfnn-riscv.c (perform_relocation): Updated encoding macros.
    (_bfd_riscv_relax_call): Likewise.
    (_bfd_riscv_relax_lui): Likewise.
    * elfxx-riscv.c (howto_table): Likewise.
gas/
    PR 27158
    * config/tc-riscv.c (riscv_ip): Updated encoding macros.
    (md_apply_fix): Likewise.
    (md_convert_frag_branch): Likewise.
    (validate_riscv_insn): Likewise.  Also arranged operands, including
    added C5 and C6 operands, and removed unused Ci and C< operands.
    * doc/c-riscv.texi: Updated and added CSS/CL/CS types.
    * testsuite/gas/riscv/insn.d: Added CSS/CL/CS instructions.
    * testsuite/gas/riscv/insn.s: Likewise.
gdb/
    PR 27158
    * riscv-tdep.c (decode_ci_type_insn): Updated encoding macros.
    (decode_j_type_insn): Likewise.
    (decode_cj_type_insn): Likewise.
    (decode_b_type_insn): Likewise.
    (decode): Likewise.
include/
    PR 27158
    * opcode/riscv.h: Updated encoding macros.
opcodes/
    PR 27158
    * riscv-dis.c (print_insn_args): Updated encoding macros.
    * riscv-opc.c (MASK_RVC_IMM): defined to ENCODE_CITYPE_IMM.
    (match_c_addi16sp): Updated encoding macros.
    (match_c_lui): Likewise.
    (match_c_lui_with_hint): Likewise.
    (match_c_addi4spn): Likewise.
    (match_c_slli): Likewise.
    (match_slli_as_c_slli): Likewise.
    (match_c_slli64): Likewise.
    (match_srxi_as_c_srxi): Likewise.
    (riscv_insn_types): Added .insn css/cl/cs.
sim/
    PR 27158
    * riscv/sim-main.c (execute_i): Updated encoding macros.

3 years agoWrong ELF class plugin vs. gcc ld version
Alan Modra [Thu, 18 Feb 2021 04:13:14 +0000 (14:43 +1030)]
Wrong ELF class plugin vs. gcc ld version

When building 32-bit binutils with CC="gcc -m32" CXX="g++ -m32" we can
fail the gcc ld version test due to an error attempting to load a
64-bit plugin into 32-bit ld-new.  This results in bogus errors about
"Your compiler driver ignores -B when choosing ld."

* testsuite/lib/ld-lib.exp: Whitespace.
(load_common_lib): Expand single use and delete this proc.
(run_host_cmd): Use -fno-lto when getting gcc's ld version.
Use -B for clang too.

3 years agopr26548 test
Alan Modra [Thu, 18 Feb 2021 03:19:42 +0000 (13:49 +1030)]
pr26548 test

I forgot that .sleb128 handles bignums, so this test should run fine
for 32-bit targets on 32-bit hosts.

* testsuite/binutils-all/readelf.exp (pr26548): Run for 32-bit too.

3 years agobinutils: Avoid renaming over existing files
Siddhesh Poyarekar [Fri, 19 Feb 2021 02:35:33 +0000 (08:05 +0530)]
binutils: Avoid renaming over existing files

Renaming over existing files needs additional care to restore
permissions and ownership, which may not always succeed.
Additionally, other properties of the file such as extended attributes
may be lost, making the operation flaky.

For predictable results, resort to rename() only if the file does not
exist, otherwise copy the file contents into the existing file.  This
ensures that no additional tricks are needed to retain file
properties.

This also allows dropping of the redundant set_times on the tmpfile in
objcopy/strip since now we no longer rename over existing files.

binutils/

* ar.c (write_archive): Remove TARGET_STAT.  Adjust call to
SMART_RENAME.
* arsup.c (ar_save): Likewise.
* objcopy (strip_main): Don't copy TMPFD.  Don't set times on
temporary file and adjust call to SMART_RENAME.
(copy_main): Likewise.
* rename.c [!S_ISLNK]: Remove definitions.
(try_preserve_permissions): Remove function.
(smart_rename): Remove FD, PRESERVE_DATES arguments.  Use
rename system call only if TO does not exist.
* bucomm.h (smart_rename): Adjust declaration.

3 years agoAutomatic date update in version.in
GDB Administrator [Fri, 19 Feb 2021 00:00:13 +0000 (00:00 +0000)]
Automatic date update in version.in

3 years agoIntroduce expression::evaluate
Tom Tromey [Thu, 18 Feb 2021 18:23:33 +0000 (11:23 -0700)]
Introduce expression::evaluate

This introduces a new method, expression::evaluate, and changes the
top-level expression-evaluation functions to use it.  Stack temporary
handling is moved into this new method, which makes sense because that
handling was only done when "*pos == 0".

This patch avoids some temporary regressions related to stack
temporary in the larger expression rewrite series.  I've pulled it out
separately because it seems like a reasonable change in its own right,
and because it's better to avoid making that series even longer.

Regression tested on x86-64 Fedora 32.

gdb/ChangeLog
2021-02-18  Tom Tromey  <tom@tromey.com>

* expression.h (struct expression) <evaluate>: Declare method.
* eval.c (evaluate_subexp): Simplify.
(expression::evaluate): New method.
(evaluate_expression, evaluate_type): Use expression::evaluate.

3 years agoFix a problem merging empty annobin notes on ppc64le targets.
Nick Clifton [Thu, 18 Feb 2021 11:43:26 +0000 (11:43 +0000)]
Fix a problem merging empty annobin notes on ppc64le targets.

* objcopy.c (merge_gnu_build_notes): Handle notes with a start
address that is higher than the end address.

3 years agogdb/testsuite: only run gdb.arch/i386-biarch-core.exp on suitable targets
Andrew Burgess [Thu, 4 Feb 2021 20:36:30 +0000 (20:36 +0000)]
gdb/testsuite: only run gdb.arch/i386-biarch-core.exp on suitable targets

Restrict the test gdb.arch/i386-biarch-core.exp to only run on
suitable targets.

gdb/testsuite/ChangeLog:

* gdb.arch/i386-biarch-core.exp: Add target check.

3 years agold: remove stray debug fprintf
Andrew Burgess [Wed, 3 Feb 2021 10:03:01 +0000 (10:03 +0000)]
ld: remove stray debug fprintf

In this commit:

  commit ace667e59aede65c400381f1cff704b61e8ccb0b
  Date:   Mon Jul 18 21:00:00 2016 +0100

      ld: Restore file offset after a plugin fails to claim a file

I inadvertently left in a stray fprintf call.  Removed in this commit.

ld/ChangeLog:

* testplugin.c (record_read_length): Remove debug fprintf.

3 years agogdb: add missing full stops in --help
Marco Barisione [Thu, 18 Feb 2021 09:15:14 +0000 (09:15 +0000)]
gdb: add missing full stops in --help

The descriptions for most options printed by gdb --help end with a full
stop but, before this patch, not the ones for --args and --interpreter.

This makes the line containing --args a bit longer but still not longer
than the previously longest line, that is the one for the --tty option.

gdb/ChangeLog:

* main.c (print_gdb_help): Add full stops at the end of the
descriptions for the --args and --interpreter options.