Now that all ports have opted in to this, we can require it in the
core.  It guarantees that new ports have them turned on, and defaults
to -Werror in the hopes that new ports keep their code clean from the
start.  We do this as a sep commit to make it clear that there are no
changes to existing ports as they've all explicitly called it already.

We want all ports to opt into extra warnings as the default compiler
settings lets a lot slide.  Opt all the ports that haven't already in
to the warning system.  None of them build with -Werror, so disable
that by default.  Hopefully someone finds these important enough to
start fixing at some point.

Make sure config.h is included before C library headers otherwise the
later libiberty.h include gets confused about asprintf state leading
to warnings like:
common/sim-utils.c:330:9:
	warning: implicit declaration of function 'vasprintf';
	did you mean 'xvasprintf'? [-Wimplicit-function-declaration]

For 32-bit targets, %x happens to work for unsigned_word.  But for
64-bit targets, it's too small, and gcc throws an error.  Use the
right printf format define for them.

This port declares its pc variable in a header and then includes
it multiple times.  This causes linker errors with newer gcc due
to the change in -fno-common behavior.  Move the storage to a C
file so we only have one instance of it in the final program.

Since we require C11 now, we can assume many headers exist, and
clean up all of the conditional includes.  It's not like any of
this code actually accounted for the headers not existing, just
whether we could include them.

The strings.h cleanup is a little nuanced: it isn't in C11, but
every use of it in the codebase will include strings.h only if
string.h doesn't exist.  Since we now assume the C11 string.h
exists, we'll never include strings.h, so we can delete it.

PR 23672 points out a crash in compile_to_object.  This crash came in
during a C++-ization.  This patch avoids the crash.

The PR also points out another weird behavior in this code, but that
one requires some setup that I don't have here, and it seems to date
back to the introduction of the compile feature.  So, it isn't
addressed here.  I will leave the PR open so this bug isn't forgotten.

gdb/ChangeLog
2021-01-09  Tom Tromey  <tom@tromey.com>

	PR compile/23672
	* compile/compile.c (compile_to_object): Avoid crash when
	osabi_triplet_regexp returns NULL.

The tracepoint code uses print_expression to reconstruct an expression
string.  However, the original expression is already available -- it
was just parsed a bit earlier in the same function.  This patch
changes this code to simply save the already-parsed expression, rather
than attempt to reconstruct it.

gdb/ChangeLog
2021-01-09  Tom Tromey  <tom@tromey.com>

	* tracepoint.h (class collection_list) <append_exp>: Take a
	std::string.
	* tracepoint.c (collection_list::append_exp): Take a std::string.
	(encode_actions_1): Update.

Testing of the expression rewrite revealed a buglet in ax.exp.  One
test does:

    gdb_test "maint agent (unsigned char)1L" ".*ext 8.*"

However, zero extension is not actually needed in this case -- a
simple "const8 1" is also correct here.

This patch changes the test to look for a push of any width of the
constant 1.

gdb/testsuite/ChangeLog
2021-01-09  Tom Tromey  <tom@tromey.com>

	* gdb.trace/ax.exp: Do not require an "ext".

Add the --enable-pgo-build[=lto] configure option.  When binutils+gdb
is not built together with GCC, --enable-pgo-build enables the PGO build:

1. First build with -fprofile-generate.
2. Use "make maybe-check-*" to generate profiling data and pass -i to make
to ignore errors when generating profiling data.
3. Use "make clean" to remove the previous build.
4. Rebuild with -fprofile-use.

With --enable-pgo-build=lto, -flto=jobserver -ffat-lto-objects are used
together with -fprofile-generate and -fprofile-use.  Add '+' to the command
line for recursive make to support -flto=jobserver -ffat-lto-objects.

NB: --enable-pgo-build=lto enables the PGO build with LTO while
--enable-lto enables LTO support in toolchain.

	PR binutils/26766
	* Makefile.tpl (BUILD_CFLAGS): New.
	(CFLAGS): Append $(BUILD_CFLAGS).
	(CXXFLAGS): Likewise.
	(PGO_BUILD_GEN_FLAGS_TO_PASS): New.
	(PGO_BUILD_TRAINING_CFLAGS): Likewise.
	(PGO_BUILD_TRAINING_CXXFLAGS): Likewise.
	(PGO_BUILD_TRAINING_FLAGS_TO_PASS): Likewise.
	(PGO_BUILD_TRAINING_MFLAGS): Likewise.
	(PGO_BUILD_USE_FLAGS_TO_PASS): Likewise.
	(PGO-TRAINING-TARGETS): Likewise.
	(PGO_BUILD_TRAINING): Likewise.
	(all): Add '+' to the command line for recursive make.  Support
	the PGO build.
	* configure.ac: Add --enable-pgo-build[=lto].
	AC_SUBST PGO_BUILD_GEN_CFLAGS, PGO_BUILD_USE_CFLAGS and
	PGO_BUILD_LTO_CFLAGS.  Enable the PGO build in Makefile.
	* Makefile.in: Regenerated.
	* configure: Likewise.

Detect GCC LTO plugin.  Pass --plugin to AR and RANLIB to support LTO
build.

bfd/

	* configure: Regenerated.

binutils/

	* configure: Regenerated.

gas/

	* configure: Regenerated.

gprof/

	* configure: Regenerated.

ld/

	* configure: Regenerated.

libctf/

	* configure: Regenerated.

opcodes/

	* configure: Regenerated.

Detect GCC LTO plugin.  Pass --plugin to AR and RANLIB to support LTO
build.

	* Makefile.tpl (AR): Add @AR_PLUGIN_OPTION@
	(RANLIB): Add @RANLIB_PLUGIN_OPTION@.
	* configure.ac: Include config/gcc-plugin.m4.
	AC_SUBST AR_PLUGIN_OPTION and RANLIB_PLUGIN_OPTION.
	* libtool.m4 (_LT_CMD_OLD_ARCHIVE): Pass --plugin to AR and
	RANLIB if possible.
	* Makefile.in: Regenerated.
	* configure: Likewise.

config/

	* gcc-plugin.m4 (GCC_PLUGIN_OPTION): New.

libiberty/

	* Makefile.in (AR): Add @AR_PLUGIN_OPTION@
	(RANLIB): Add @RANLIB_PLUGIN_OPTION@.
	(configure_deps): Depend on ../config/gcc-plugin.m4.
	* aclocal.m4: Include ../config/gcc-plugin.m4.
	* configure.ac: AC_SUBST AR_PLUGIN_OPTION and
	RANLIB_PLUGIN_OPTION.
	* configure: Regenerated.

zlib/

	* configure: Regenerated.

These ports declare their State variable in a header and then include
multiple times.  This causes linker errors with newer gcc due to the
change in -fno-common behavior.  Move the storage to a C file so we
only have one instance of it in the final program.

Delete stale prototypes that libiberty.h already provides, and add
missing libiberty.h includes to files that use those functions.

Support for sh64 was dropped from bfd et al in 2018.  Without
that, the sim port is useless.  So clean up this code too.

This was purged from the tree when we upgraded to autoconf-2.69,
but a few references in the sim tree were missed.

We've had this off for a long time because the sim code was way too
full of warnings for it to be feasible.  However, I've cleaned things
up significantly from when this was first merged, and we can start to
turn this around.

Change the macro to enable -Werror by default, and allow ports to opt
out.  New ports will get it automatically (and we can push back on
them if they try to turn it off).

Also turn it off for the few ports that still hit warnings for me.
All the rest will get the new default, and we'll wait for feedback
if/when new issues come up.

Properly merge GNU properties for LAM_U48 and LAM_U57.

bfd/

	PR ld/27166
	* elfxx-x86.c (_bfd_x86_elf_merge_gnu_properties): Handle
	-z lam-u48 and -z lam-u57.

ld/

	PR ld/27166
	* testsuite/ld-x86-64/lam-u48.rd: New file.
	* testsuite/ld-x86-64/lam-u57.rd: Likewise.
	* testsuite/ld-x86-64/x86-64.exp: Add PR ld/27166 tests.

Make sure config.h is included before C library headers otherwise the
later libiberty.h include gets confused about asprintf state leading
to warnings like:
common/sim-utils.c:330:9:
	warning: implicit declaration of function 'vasprintf';
	did you mean 'xvasprintf'? [-Wimplicit-function-declaration]

Newer gcc thinks we might return a pointer to a stack buffer, but
we don't -- we strdup it before returning.  Rework the code to just
malloc the buffer from the start and avoid the stack+strdup.

Since LAM_U48 implies LAM_U57, also set LAM_U57 when setting LAM_U48.

bfd/

	* elfxx-x86.c (_bfd_x86_elf_link_setup_gnu_properties): Also set
	LAM_U57 when setting LAM_U48.

ld/

	* ld-x86-64/property-x86-lam-u48-4.d: Updated.
	* ld-x86-64/property-x86-lam-u48-5.d: Likewise.

When fixing up SHF_LINK_ORDER, issue a fatal error if the output section
size is increased.  Otherwise, bfd_set_section_contents will fail later
when attempting to write contents past the end of the output section.

	PR ld/26256
	PR ld/27160
	* elflink.c (elf_fixup_link_order): Verify that fixing up
	SHF_LINK_ORDER doesn't increase the output section size.

POWER10 adds some return-oriented programming (ROP) instructions and
this patch adds support for them.  You will notice that they are enabled
for POWER8 and later, not just POWER10 and later.  This is on purpose.
This allows the instructions to be added to POWER8 binaries that can be
run on POWER8, POWER9 and POWER10 cpus.  On POWER8 and POWER9, these
instructions just act as nop's.

opcodes/
	* ppc-opc.c (insert_dw, (extract_dw): New functions.
	(DW, (XRC_MASK): Define.
	(powerpc_opcodes) <hashchk, hashchkp, hashst, haststp>: New mnemonics.
gas/
	* testsuite/gas/ppc/rop-checks.d,
	* testsuite/gas/ppc/rop-checks.l,
	* testsuite/gas/ppc/rop-checks.s,
	* testsuite/gas/ppc/rop.d,
	* testsuite/gas/ppc/rop.s: New tests.
	* testsuite/gas/ppc/ppc.exp: Run them.

commit f4782128 did the regen by hand, missed a change in
ld/configure and didn't update line numbers.  Fix that, and an old
regen of ld/Makefile.in with the wrong automake.

bfd/
	* configure: Regenerate.
binutils/
	* configure: Regenerate.
gas/
	* configure: Regenerate.
gprof/
	* configure: Regenerate.
ld/
	* Makefile.in: Regenerate.
	* configure: Regenerate.
libctf/
	* configure: Regenerate.
opcodes/
	* configure: Regenerate.
zlib/
	* configure: Regenerate.

With GDB requiring a C++11 compiler now, this hopefully shouldn't
be a big deal.  It's been 10 years since C11 came out, so should
be plenty of time to upgrade.

This will allow us to start cleaning up random header logic and
many of our non-standard custom types.

An earlier patch pointed out that nothing in GDB sets void_context_p
when parsing an expression.  This patch fixes this omission.

"print" and "call" differ in that the former will print a value that
has void type, while the latter will not.  AdaCore has had a patch for
a long time that uses this distinction to help with overload
resolution.  In particular, in a "call" context, a procedure will be
chosen, while in a "print" context, a zero-argument function will be
chosen instead.

Regression tested on x86-64 Fedora 32.

gdb/ChangeLog
2021-01-08  Tom Tromey  <tromey@adacore.com>

	* parse.c (parse_expression): Add void_context_p parameter.  Use
	parse_exp_in_context.
	* printcmd.c (print_command_1): Change voidprint to bool.  Pass to
	parse_expression.
	(print_command, call_command): Update.
	* expression.h (parse_expression): Add void_context_p parameter.

gdb/testsuite/ChangeLog
2021-01-08  Tom Tromey  <tromey@adacore.com>

	* gdb.ada/voidctx/pck.adb: New file.
	* gdb.ada/voidctx/pck.ads: New file.
	* gdb.ada/voidctx/voidctx.adb: New file.
	* gdb.ada/voidctx.exp: New file.

As reported in PR 27157, if some environment variables read at startup
by GDB are defined but empty, we hit the assert in gdb_abspath:

    $ XDG_CACHE_HOME= ./gdb -nx --data-directory=data-directory -q
    AddressSanitizer:DEADLYSIGNAL
    =================================================================
    ==2007040==ERROR: AddressSanitizer: SEGV on unknown address 0x0000000001b0 (pc 0x5639d4aa4127 bp 0x7ffdac232c00 sp 0x7ffdac232bf0 T0)
    ==2007040==The signal is caused by a READ memory access.
    ==2007040==Hint: address points to the zero page.
        #0 0x5639d4aa4126 in target_stack::top() const /home/smarchi/src/binutils-gdb/gdb/target.h:1334
        #1 0x5639d4aa41f1 in inferior::top_target() /home/smarchi/src/binutils-gdb/gdb/inferior.h:369
        #2 0x5639d4a70b1f in current_top_target() /home/smarchi/src/binutils-gdb/gdb/target.c:120
        #3 0x5639d4b00591 in gdb_readline_wrapper_cleanup::gdb_readline_wrapper_cleanup() /home/smarchi/src/binutils-gdb/gdb/top.c:1046
        #4 0x5639d4afab31 in gdb_readline_wrapper(char const*) /home/smarchi/src/binutils-gdb/gdb/top.c:1104
        #5 0x5639d4ccce2c in defaulted_query /home/smarchi/src/binutils-gdb/gdb/utils.c:893
        #6 0x5639d4ccd6af in query(char const*, ...) /home/smarchi/src/binutils-gdb/gdb/utils.c:985
        #7 0x5639d4ccaec1 in internal_vproblem /home/smarchi/src/binutils-gdb/gdb/utils.c:373
        #8 0x5639d4ccb3d1 in internal_verror(char const*, int, char const*, __va_list_tag*) /home/smarchi/src/binutils-gdb/gdb/utils.c:439
        #9 0x5639d5151a92 in internal_error(char const*, int, char const*, ...) /home/smarchi/src/binutils-gdb/gdbsupport/errors.cc:55
        #10 0x5639d5162ab4 in gdb_abspath(char const*) /home/smarchi/src/binutils-gdb/gdbsupport/pathstuff.cc:132
        #11 0x5639d5162fac in get_standard_cache_dir[abi:cxx11]() /home/smarchi/src/binutils-gdb/gdbsupport/pathstuff.cc:228
        #12 0x5639d3e76a81 in _initialize_index_cache() /home/smarchi/src/binutils-gdb/gdb/dwarf2/index-cache.c:325
        #13 0x5639d4dbbe92 in initialize_all_files() /home/smarchi/build/binutils-gdb/gdb/init.c:321
        #14 0x5639d4b00259 in gdb_init(char*) /home/smarchi/src/binutils-gdb/gdb/top.c:2344
        #15 0x5639d4440715 in captured_main_1 /home/smarchi/src/binutils-gdb/gdb/main.c:950
        #16 0x5639d444252e in captured_main /home/smarchi/src/binutils-gdb/gdb/main.c:1229
        #17 0x5639d44425cf in gdb_main(captured_main_args*) /home/smarchi/src/binutils-gdb/gdb/main.c:1254
        #18 0x5639d3923371 in main /home/smarchi/src/binutils-gdb/gdb/gdb.c:32
        #19 0x7fa002d3f0b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
        #20 0x5639d392314d in _start (/home/smarchi/build/binutils-gdb/gdb/gdb+0x4d414d)

gdb_abspath doesn't handle empty strings, so handle this case in the
callers.  If a variable is defined but empty, I think it's reasonable in
this case to just ignore it, as if it was not defined.

Note that this sometimes also lead to a segfault, because the failed
assertion happens very early during startup, before things are fully
initialized.

gdbsupport/ChangeLog:

	PR gdb/27157
	* pathstuff.cc (get_standard_cache_dir, get_standard_config_dir,
	find_gdb_home_config_file): Add empty string check.

gdb/testsuite/ChangeLog:

	PR gdb/27157
	* gdb.base/empty-host-env-vars.exp: New test.

Change-Id: I8654d8e97e74e1dff6d308c111ae4b1bbf07bef9

This commit:

  commit 3df8c6af
  Date:   Fri Nov 27 10:46:07 2020 +0000

      gdb: fix potentially uninitialised variable

Was pushed with no test.  Naughty!

The new test checks how GDB behaves when completing an invalid /FMT
string.

Currently GDB does no validation of the /FMT string during tab
completion, and just assumes that any /FMT string is valid and
complete when the user hits TAB. So:

  (gdb) p/@@<TAB>

Will give:

  (gdb) p/@@ <CURSOR IS HERE>

We already had a test in place for completion on a valid /FMT string,
but the above commit fixed a bug in the logic for completing invalid
/FMT strings.  Now we have a test for this too.

gdb/testsuite/ChangeLog:

	* gdb.base/completion.exp: Add a new test.

Consider this Fortran type:

  type :: some_type
     integer, allocatable :: array_one (:,:)
     integer :: a_field
     integer, allocatable :: array_two (:,:)
  end type some_type

And a variable declared:

  type(some_type) :: some_var

Now within GDB we try this:

  (gdb) set $a = some_var
  (gdb) p $a
  $1 = ( array_one =
  ../../src/gdb/value.c:3968: internal-error: Unexpected lazy value type.

Normally, when an internalvar ($a in this case) is created, it is
non-lazy, the value is immediately copied out of the inferior into
GDB's memory.

When printing the internalvar ($a) GDB will extract each field in
turn, so in this case `array_one`.  As the original internalvar is
non-lazy then the extracted field will also be non-lazy, with its
contents immediately copied from the parent internalvar.

However, when the field has a dynamic type this is not the case, in
value_primitive_field we see that any field with dynamic type is
always created lazy.  Further, the content of this field will usually
not have been captured in the contents buffer of the original value, a
field with dynamic location is effectively a pointer value contained
within the parent value, with rules in the DWARF for how to
dereference the pointer.

So, we end up with a lazy lval_internalvar_component representing a
field within an lval_internalvar.  This eventually ends up in
value_fetch_lazy, which currently does not support
lval_internalvar_component, and we see the error above.

My original plan for how to handle this involved extending
value_fetch_lazy to handle lval_internalvar_component.  However, when
I did this I ran into another error:

  (gdb) set $a = some_var
  (gdb) p $a
  $1 = ( array_one = ((1, 1) (1, 1) (1, 1)), a_field = 5, array_two = ((0, 0, 0) (0, 0, 0)) )
  (gdb) p $a%array_one
  $2 = ((1, 1) (1, 1) (1, 1))
  (gdb) p $a%array_one(1,1)
  ../../src/gdb/value.c:1547: internal-error: void set_value_address(value*, CORE_ADDR): Assertion `value->lval == lval_memory' failed.

The problem now is inside set_value_component_location, where we
attempt to set the address for a component if the original parent
value has a dynamic location.  GDB does not expect to ever set the
address on anything other than an lval_memory value (which seems
reasonable).

In order to resolve this issue I initially thought about how an
internalvar should "capture" the value of a program variable at the
moment the var is created.  In an ideal world (I think) GDB would be
able to do this even for values with dynamic type.  So in our above
example doing `set $a = some_var` would capture the content of
'some_var', but also the content of 'array_one', and also 'array_two',
even though these content regions are not contained within the region
of 'some_var'.

Supporting this would require GDB values to be able to carry around
multiple non-contiguous regions of memory as content in some way,
which sounds like a pretty huge change to a core part of GDB.

So, I wondered if there was some other solution that wouldn't require
such a huge change.

What if values with a dynamic location were though of like points with
automatic dereferencing?  Given this C structure:

  struct foo_t {
    int *val;
  }

  struct foo_t my_foo;

Then in GDB:

  (gdb) $a = my_foo

We would expect GDB to capture the pointer value in '$a', but not the
value pointed at by the pointer.  So maybe it's not that unreasonable
to think that given a dynamically typed field GDB will capture the
address of the content, but not the actual content itself.

That's what this patch does.

The approach is to catch this case in set_value_component_location.
When we create a component location (of an lval_internalvar) that has
a dynamic data location, the lval_internalvar_component is changed
into an lval_memory.  After this, both of the above issues are
resolved.  In the first case, the lval_memory is still lazy, but
value_fetch_lazy knows how to handle that.  In the second case, when
we access an element of the array we are now accessing an element of
an lval_memory, not an lval_internalvar_component, and calling
set_value_address on an lval_memory is fine.

gdb/ChangeLog:

	* value.c (set_value_component_location): Adjust the VALUE_LVAL
	for internalvar components that have a dynamic location.

gdb/testsuite/ChangeLog:

	* gdb.fortran/intvar-dynamic-types.exp: New file.
	* gdb.fortran/intvar-dynamic-types.f90: New file.

	PR 27129
	* aarch64-dis.c (determine_disassembling_preference): Move call to
	aarch64_match_operands_constraint outside of the assertion.
	* aarch64-asm.c (aarch64_ins_limm_1): Remove call to assert.
	Replace with a return of FALSE.