gdb: add gdbarch::displaced_step_buffer_length

The gdbarch::max_insn_length field is used mostly to support displaced
stepping; it controls the size of the buffers allocated for the
displaced-step instruction, and is also used when first copying the
instruction, and later, when fixing up the instruction, in order to
read in and parse the instruction being stepped.

However, it has started to be used in other places in GDB, for
example, it's used in the Python disassembler API, and it is used on
amd64 as part of branch-tracing instruction classification.

The problem is that the value assigned to max_insn_length is not
always the maximum instruction length, but sometimes is a multiple of
that length, as required to support displaced stepping, see rs600,
ARM, and AArch64 for examples of this.

It seems to me that we are overloading the meaning of the
max_insn_length field, and I think that could potentially lead to
confusion.

I propose that we add a new gdbarch field,
gdbarch::displaced_step_buffer_length, this new field will do
exactly what it says on the tin; represent the required displaced step
buffer size.  The max_insn_length field can then do exactly what it
claims to do; represent the maximum length of a single instruction.

As some architectures (e.g. i386, and amd64) only require their
displaced step buffers to be a single instruction in size, I propose
that the default for displaced_step_buffer_length will be the
value of max_insn_length.  Architectures than need more buffer space
can then override this default as needed.

I've updated all architectures to setup the new field if appropriate,
and I've audited all calls to gdbarch_max_insn_length and switched to
gdbarch_displaced_step_buffer_length where appropriate.

There should be no user visible changes after this commit.

Approved-By: Simon Marchi <simon.marchi@efficios.com>

gdbarch: make invalid=True the default for all Components

This commit switches the default value for the 'invalid' field from
False to True.  All components that previous set the invalid field to
True explicitly have had the field removed.

I think that True is a good choice for the default, this means that we
now get the validity checks by default, and if anyone adds a new
Component they need to make a choice to add an 'invalid=False' line
and disable the validation.

The flip side of this is that 'invalid=False' seems to be far more
common than 'invalid=True'.  But I don't see a huge problem with this,
we shouldn't be aiming to reduce our typing, rather we should choose
based on which is least likely to introduce bugs.  I think assuming
that we should do a validity check will achieve that.

Some additional components need to have an 'invalid=False' line added
to their definition, these are components that have a predefault
value, which is sufficient; the tdep code doesn't need to replace this
value if it doesn't want to.

Without adding the 'invalid=False' these components would be
considered to be invalid if they have not changed from their
predefault value -- but the predefault is fine.

There's no change in the generated code after this commit, so there
will be no user visible changes after this commit.

Approved-By: Simon Marchi <simon.marchi@efficios.com>

gdbarch: remove some unneeded predefault="0" from gdbarch_components.py

I noticed that there are a bunch of 'predefault="0"' lines in
gdbarch_components.py, and that some (just some, not all) of these are
not needed.

The gdbarch is already zero initialized, but these lines seem to
exists so that we can know when to compare against "0" and when to
compare against "NULL".  At least, this seems to be useful in some
places in the generated code.

Specifically, if we remove the predefault="0" line from the
max_insn_length component then we end up generating a line like:

  gdb_assert (gdbarch->max_insn_length != NULL);

which doesn't compile as we compare a ULONGEST to NULL.

In this commit I remove all the predefault="0" lines that I claim are
obviously not needed.  These are lines for components that are not
Values (i.e. the component holds a function pointer anyway), or for
Value components that hold a pointer type, in which case using NULL is
fine.

The only changes after this commit are some fields that have nullptr
as their initial value, and gcore_bfd_target now compares to NULL not
0 in gdbarch_gcore_bfd_target_p, which, given the field is of type
'const char *', seems like an improvement.

Approved-By: Simon Marchi <simon.marchi@efficios.com>

gdbarch: improve generation of validation in gdbarch getters

We currently generate some validation code within the gdbarch getter
methods.

This commit adjusts the algorithm used to generate this validation
slightly to make the gdbarch.py code (I think) clearer; there's no
significant changes to what is generated.

The validation algorithm for gdbarch values is now:

  - If the Value has an 'invalid' field that is a string, use that for
    validation,

  - If the Value has its 'predicate' field set to true, then check the
    predicate returns true, this ensures the predicate has been
    called,

  - If the Value has its 'invalid' field set to True, or the Value has
    'postdefault' field, then check the fields has changed from its
    initial value,

  - Otherwise no validation is performed.

The only changes after this commit are:

  - Some comments change slightly, and

  - For 'gcore_bfd_target' and 'max_insn_length' we now validate by
    calling the predicate rather than checking the field value
    directly, the underlying check being performed is unchanged
    though.

There should be no user visible changes after this commit.

Approved-By: Simon Marchi <simon.marchi@efficios.com>

gdbarch: use predefault for more value components within gdbarch

For some reason the following value components of gdbarch:

  bfloat16_format
  half_format
  float_format
  double_format
  long_double_format
  so_ops

All use a postdefault but no predefault to set the default value for
the component.

As the postdefault values for these components are all constant
pointers that don't depend on other fields within the gdbarch, then I
don't see any reason why we couldn't use a predefault instead.

So lets do that.

Approved-By: Simon Marchi <simon.marchi@efficios.com>

gdb/gdbarch: remove the 'invalid=None' state from gdbarch_components.py

This commit ensures that the 'invalid' property of all components is
either True, False, or a string.

Additionally, this commit allows a component to have both a predicate
and for the 'invalid' property to be a string.

Removing the option for 'invalid' to be None allows us to simplify the
algorithms in gdbarch.py a little.

Allowing a component to have both a predicate and an 'invalid' string
means that we can validate the value that a tdep sets into a field,
but also allow a predicate to ensure that the field has changed from
the default.

This functionality isn't going to be used in this series, but I have
tested it locally and believe that it would work, and this might make
it easier for others to add new components in the future.

In gdbarch_types.py, I've updated the type annotations to show that
the 'invalid' field should not be None, and I've changed the default
for this field from None to False.

The change to using False as the default is temporary.  Later in this
series I'm going to change the default to True, but we need more fixes
before that can be done.

Additionally, in gdbarch_types.py I've removed an assert from
Component.get_predicate.  This assert ensured that we didn't have the
predicate field set to True and the invalid field set to a string.
However, no component currently uses this configuration, and after
this commit, that combination is now supported, so the assert can be
removed.

As a consequence of the gdbarch_types.py changes we see some
additional comments generated in gdbarch.c about verification being
skipped due to the invalid field being False.  This comment is inline
with plenty of other getters that also have a similar comment.  Plenty
of the getters do have validation, so I think it is reasonable to have
a comment noting that the validation has been skipped for a specific
reason, rather than due to some bug.

In gdbarch_components.py I've had to add 'invalid=True' for two
components: gcore_bfd_target and max_insn_length, without this the
validation in the gdbarch getter would disappear.

And in gdbarch.py I've reworked the logic for generating the
verify_gdbarch function, and for generating the getter functions.

The logic for generating the getter functions is still not ideal,  I
ended up having to add this additional logic block:

  elif c.postdefault is not None and c.predefault is not None:
      print("  /* Check variable changed from pre-default.  */", file=f)
      print(f"  gdb_assert (gdbarch->{c.name} != {c.predefault});", file=f)

which was needed to ensure we continued to generate the same code as
before, without this the fact that invalid is now False when it would
previously have been None, meant that we dropped the gdb_assert in
favour of a comment like:

  print(f"  /* Skip verify of {c.name}, invalid_p == 0 */", file=f)

which is clearly not a good change.  We could potentially look at
improving this in a later commit, but I don't plan to do that in this
series.

Approved-By: Simon Marchi <simon.marchi@efficios.com>

gdb/gdbarch: split postdefault setup from invalid check in gdbarch.py

Restructure how gdbarch.py generates the verify_gdbarch function.
Previously the postdefault handling was bundled together with the
validation.  This means that a field can't have both a postdefault,
and set its invalid attribute to a string.

This doesn't seem reasonable to me, I see no reason why a field can't
have both a postdefault (used when the tdep doesn't set the field),
and an invalid expression, which can be used to validate the value
that a tdep might set.

In this commit I restructure the verify_gdbarch generation code to
allow the above, there is no change in the actual generated code in
this commit, that will come in later commit.

Approved-By: Simon Marchi <simon.marchi@efficios.com>

gdb/gdbarch: remove yet more 'invalid=True' from gdbarch_components.py

Following on from the previous commit, this commit removes yet more
'invalid=True' lines from gdbarch_components.py where the invalid
setting has no effect.

Due to the algorithm used in gdbarch.py for generated verify_gdbarch,
if a component has a postdefault value then no invalid check will ever
be generated for the component, as such setting 'invalid=True' on the
component is pointless.  This commit removes the setting of invalid.

There is no change in the generated code after this commit.

Approved-By: Simon Marchi <simon.marchi@efficios.com>

gdb/gdbarch: remove unused 'invalid=True' from gdbarch_components.py

Due to the algorithm used to generate verify_gdbarch in gdbarch.py, if
a component has a predicate, then a validation check will never be
generated.

There are a bunch of components that are declared with both a
predicate AND have 'invalid=True' set.  The 'invalid=True' has no
effect.

In this commit I clean things up by removing all these additional
'invalid=True' lines.  There's no change in any of the generated files
after this commit.

Approved-By: Simon Marchi <simon.marchi@efficios.com>

Fix crash in inside_main_func

gdb 13.1 crashes while running the rust compiler's debugger tests.
The crash has a number of causes.

First, the rust compiler still uses the C++-like _Z mangling, but with
its own twist -- some hex digits added to the end of a symbol.  So,
while gdb finds the correct name of "main":

(top-gdb) p name
$13 = 0x292e0c0 "rustc_gdb_1031745::main"

It isn't found in the minsyms, because C++ demangling yields:

[99] t 0x90c0 _ZN17rustc_gdb_10317454main17h5b5be7fe16a97225E section .text  rustc_gdb_1031745::main::h5b5be7fe16a97225  zko06yobckx336v

This could perhaps be fixed.  I also filed a new PR to suggest
preferring the linkage name of the main program.

Next, the rust compiler emits both a DW_TAG_subprogram and a
DW_TAG_namespace for "main".  This happens because the file is named
"main.rs" -- i.e., the bug is specific to the source file name.  The
crash also seems to require the nested function inside of 'main', at
least for me.  The namespace always is generated, but perhaps this
changes the ordering in the DWARF.

When inside_main_func looks up the main symbol, it finds the namespace
symbol rather than the function.  (I filed a bug about fixing gdb's
symbol tables -- long overdue.)

Meanwhile, as I think it's important to fix this crash sooner rather
than later, this patch changes inside_main_func to check that the
symbol that is found is LOC_BLOCK.  This perhaps should have been done
in the first place, anyway.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30158

[gdb/testsuite] Fix gdb.python/tui-window-factory.exp for remote host

When running gdb.python/tui-window.exp with host board
local-remote-host-notty and target board native-gdbserver, I get:
...
FAIL: gdb.python/tui-window-factory.exp: msg_2: \
  check test_window box (box check: ul corner is l, not +)
...

The problem is that the result of Term::prepare_for_tui is not checked.

Fix this by adding the missing check.

Tested on x86_64-linux.

[gdb/testsuite] Fix gdb.python/tui-window.exp for remote host

When running gdb.python/tui-window.exp with host board
local-remote-host-notty and target board native-gdbserver, I get:
...
UNSUPPORTED: gdb.python/tui-window.exp: TUI not supported
FAIL: gdb.python/tui-window.exp: test title
...

Fix this by adding the missing return after the unsupported.

Tested on x86_64-linux.

[gdb/testsuite] Fix gdb.tui/completion.exp for local-remote-host-notty

When running test-case gdb.tui/completion.exp with host board
local-remote-host-notty and target board native-gdbserver, I get:
...
FAIL: gdb.tui/completion.exp: completion of layout names: \
  tab completion (timeout)
...

The test-case contains a few tests that do tab completion, which requires
readline, which is unavailable with host board local-remote-host-notty.

Fix this by adding the missing check for readline_is_used.

Tested on x86_64-linux.

[gdb/testsuite] Fix gdb.tui/tui-layout.exp for remote host

When running test-case gdb.tui/tui-layout.exp with host board
local-remote-host-notty and target board native-gdbserver, I get:
...
FAIL: gdb.tui/tui-layout.exp: terminal=dumb: execution=false: layout=asm: \
  layout asm (timeout)
...

The problem is that the test-case expects that the default "setenv TERM dumb"
has effect, which is not the case for remote host.

Fix this by skipping the test for remote host.

Tested on x86_64-linux.

[gdb/testsuite] Fix gdb.tui/tui-nl-filtered-output.exp for remote host

When running test-case gdb.tui/tui-nl-filtered-output.exp with host board
local-remote-host-notty and target board native-gdbserver, I get:
...
FAIL: gdb.tui/tui-nl-filtered-output.exp: check printf output
...

The problem is that Term::enter_tui is returning 0, but the test-case doesn't
check for this, and consequently runs unsupported tests.

Fix this by adding the missing check.

Tested on x86_64-linux.

[gdb/testsuite] Require ![is_remote host] for TUI

When running test-case gdb.tui/corefile-run.exp with both host and target board
local-remote-host-native.exp, we run into:
...
FAIL: gdb.tui/corefile-run.exp: load corefile
...
while this passes with USE_TUI=0.

The problem is that the TUI setup code uses "setenv TERM ansi", which has no
effect on remote host.

I can confirm this analysis by working around this problem in
local-remote-host-native.exp like this:
...
-    spawn $RSH -t -l $username $remote $cmd
+    spawn $RSH -t -l $username $remote "export TERM=ansi; $cmd"
...

For now, simply make TUI unsupported for remote host, by returning 0 in
prepare_for_tui.

Tested on x86_64-linux.

[gdb/testsuite] Handle USE_TUI in gdb.tui/corefile-run.exp

Once in a while I find myself rewriting a TUI test-case into a non-TUI
test-case, to better understand whether the problem I'm looking at is
related to the TUI or not.

I've got the impression that I've done this sufficiently often that it's worth
committing the non-TUI version, so having just written a non-TUI version of
gdb.tui/corefile-run.exp, let's commit it.

The non-TUI version can be enabled by doing:
...
$ make check "RUNTESTFLAGS=gdb.tui/corefile-run.exp USE_TUI=0"
...

Also remove hard-coding of a source line number.

Tested on x86_64-linux.

[gdb/testsuite] Fix untested message in gdb.tui/corefile-run.exp

In test-case gdb.tui/corefile-run.exp, we have this bit:
...
require !use_gdb_stub
if { [target_info gdb_protocol] == "extended-remote" } {
    untested "not supported"
    return
}
...

So with target board native-gdbserver we get:
...
UNSUPPORTED: gdb.tui/corefile-run.exp: require failed: !use_gdb_stub
...
and with target board native-extended-gdbserver instead:
...
UNTESTED: gdb.tui/corefile-run.exp: not supported
...

Fix this by:
- adding an optional argument target_description to proc
  target_can_use_run_cmd
- handling the target_description == core &&
  [target_info gdb_protocol] == "extended-remote" case in the proc
- using require {target_can_use_run_cmd core}
such that now in both cases we have:
...
UNSUPPORTED: gdb.tui/corefile-run.exp: require failed: \
  target_can_use_run_cmd core
...

Tested on x86_64-linux.

[gdb/testsuite] Fix gdb.threads/step-bg-decr-pc-switch-thread.exp for native-gdbserver

With test-case gdb.threads/step-bg-decr-pc-switch-thread.exp and target board
native-gdbserver, I run into:
...
(gdb) UNSUPPORTED: gdb.threads/step-bg-decr-pc-switch-thread.exp: \
  switch to main thread
Remote debugging from host ::1, port 43914^M
monitor exit^M
Cannot execute this command while the target is running.^M
Use the "interrupt" command to stop the target^M
and then try again.^M
(gdb) WARNING: Timed out waiting for EOF in server after monitor exit
...

Fix this by following the advice and issuing an interrupt command, allowing
the following monitor exit command to succeed.

Tested on x86_64-linux.

[gdb/obvious]: fix python formatting for test gdb.python/py-typeprint.py

python black formatter was complaining about the formatting of
gdb.python/py-typeprint.py, so this commit corrects it.

gdb/testsuite: add regression test for per-objfile typeprinters

PR python/17136 reported an unhandled exception when using typeprinters
only valid on some objfiles, rather than being a global typeprinter. The
fix was accepted without a regression test, and we've been carrying one
out-of-tree for a while but I think it's worth upstreaming. The code
itself was developed by Jan Kratochvil.

Co-Authored-By: Jan Kratochvil <jkratochvil@azul.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17136
Reviewed-By: Andrew Burgess <aburgess@redhat.com>
Approved-By: Tom Tromey <tom@tromey.com>

Remove dead code from scalar_binop

scalar_binop has code for "&&" and "||", but I think this code can't
currently be run -- and, furthermore, it doesn't make sense to have
this code here, as the point of these operators is to short-circuit
evaluation.

This patch removes the dead code.

Regression tested on x86-64 Fedora 36.

Approved-by: Kevin Buettner <kevinb@redhat.com>

aarch64: Expand documentation of XML features

Similar to the arm target documentation situation, the documentation of the
XML features for AArch64 targets is rather brief.  I have received the same
feedback that what gdb carries in the documentation is quite unclear from the
perspective of what debugging servers should define in the XML features, how and
what the outcome is in gdb.

This patch attempts to clarify a bit more what all the possible features are.

arm: Expand documentation of XML features

The documentation of the XML features for Arm targets is very brief.  I have
received feedback saying it is quite unclear from the perspective of the
debugging servers what should be defined in the XML features, how and
what the outcome is in gdb.

This patch attempts to clarify a bit more what all the possible features are.

Automatic date update in version.in

Automatic date update in version.in

gprofng: fix the Dwarf reader

gprofng/ChangeLog
2023-03-10  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

gprofng/src/DwarfLib.cc (DwrLineRegs::getPath): Add a DW_AT_comp_dir
string if the directoty table has relative names.

Change linetable_entry::is_stmt to bool

This changes linetable_entry::is_stmt to type bool, rather than
unsigned.

Approved-By: Simon Marchi <simon.marchi@efficios.com>

Remove extra scopes from objfile_relocate1

objfile_relocate1 introduces new scopes that aren't necessary.  I
noticed this while working on an earlier patch in this series.  This
patch removes these.

Approved-By: Simon Marchi <simon.marchi@efficios.com>

Constify linetables

Linetables no longer change after they are created.  This patch
applies const to them.

Note there is one hack to cast away const in mdebugread.c.  This code
allocates a linetable using 'malloc', then later copies it to the
obstack.  While this could be cleaned up, I chose not to do so because
I have no way of testing it.

Approved-By: Simon Marchi <simon.marchi@efficios.com>

Change linetables to be objfile-independent

This changes linetables to not add the text offset to the addresses
they contain.  I did this in a few steps, necessarily combined
together in one patch: I renamed the 'pc' member to 'm_pc', added the
appropriate accessors, and then recompiled.  Then I fixed all the
errors.  Where possible I generally chose to use the raw_pc accessor,
as it is less expensive.

Note that this patch discounts the possibility that the text section
offset might cause wraparound in the addresses in the line table.
However, this was already discounted -- in particular,
objfile_relocate1 did not re-sort the table in this scenario.  (There
was a bug open about this, but as far as I can tell this has never
happened, it's not even clear what inspired that bug.)

Approved-By: Simon Marchi <simon.marchi@efficios.com>

Add operator< and operator== to linetable_entry

This adds a couple of comparison operators to linetable_entry, and
simplifies both the calls to sort and one other spot that checks for
equality.

Approved-By: Simon Marchi <simon.marchi@efficios.com>

Automatic date update in version.in

gprofng: PR30195 [display text] Source code location can not be found

gprofng/ChangeLog
2023-03-10  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

PR gprofng/30195
gprofng/src/DwarfLib.cc (DwrLineRegs::reset): Set 'file = 1;'.

PR gdb/30214: Prefer local include paths to system include paths

Some systems may install binutils headers into a system location
(e.g. /usr/local/include on FreeBSD) which may also include headers
for other external packages used by GDB such as zlib or zstd.  If a
system include path such as /usr/local/include is added before local
include paths to directories within a clone or release tarball, then
headers from the external binutils package are used which can result
in build failures if the external binutils package is out of sync with
the version of GDB being built.

To fix, sort the include paths in INTERNAL_CFLAGS_BASE to add CFLAGS
for "local" componenets before external components.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30214
Reviewed-By: Tom Tromey <tom@tromey.com>

ld: Allow R_386_GOT32 for call *__tls_get_addr@GOT(%reg)

Similar to d58854b6dd88e05dbf2a5d1c32c5acb7bd6ea274 for x86_64.

_Thread_local int a;
int main() { return a; }

% gcc -m32 -fno-plt -fpic a.c -fuse-ld=bfd -Wa,-mrelax-relocations=no
/usr/bin/ld.bfd: /tmp/ccR8Yexy.o: TLS transition from R_386_TLS_GD to R_386_TLS_IE_32 against `a' at 0x15 in section `.text' failed
/usr/bin/ld.bfd: failed to set dynamic section sizes: bad value
collect2: error: ld returned 1 exit status

This commit fixes the issue.

There is an argument that the -fno-plt TLS sequence was added after
R_386_GOT32X was required for call *func@GOT(%ebx), so R_386_GOT32 was
intended to be unsupported.

Unfortunately this standpoint has caused interop difficulty: some
projects specify -mrelax-relocations=no to build relocatable object
files compatible with older linkers (e.g.
https://github.com/IHaskell/IHaskell/issues/636) or do so by accident
(e.g. https://github.com/rust-lang/rust/pull/106511 not addressed as of
today).  Many uses have not been cleaned up in practice, and compiling
with -fno-plt will lead to the `TLS transition from R_386_TLS_GD ...`
error which is hard to reason about.

It seems easier to apply this simple change to prevent the footgun.

    PR ld/24784
    * bfd/elf32-i386.c (elf_i386_check_tls_transition): Allow R_386_GOT32.

ld: Allow R_X86_64_GOTPCREL for call *__tls_get_addr@GOTPCREL(%rip)

_Thread_local int a;
int main() { return a; }

% gcc -fno-plt -fpic a.c -fuse-ld=bfd -Wa,-mrelax-relocations=no
/usr/bin/ld.bfd: /tmp/ccSSBgrg.o: TLS transition from R_X86_64_TLSGD to R_X86_64_GOTTPOFF against `a' at 0xd in section `.text' failed
/usr/bin/ld.bfd: failed to set dynamic section sizes: bad value
collect2: error: ld returned 1 exit status

This commit fixes the issue.

There is an argument that the -fno-plt TLS sequence was added after
R_X86_64_GOTPCRELX was required for call, so R_X86_64_GOTPCREL was
intended to be unsupported.

Unfortunately this standpoint has caused interop difficulty: some
projects specify -mrelax-relocations=no to build relocatable object
files compatible with older linkers (e.g.
https://github.com/IHaskell/IHaskell/issues/636) or do so by accident
(e.g. https://github.com/rust-lang/rust/pull/106511 not addressed as of
today).  Many uses have not been cleaned up in practice, and compiling
with -fno-plt will lead to the `TLS transition from R_X86_64_TLSGD ...`
error which is hard to reason about.

There is another argument which may be weaker but relevant to the
necessity of -mrelax-relocations=no: HWAddressSanitizer x86-64 will
likely need some assembler support to disable relaxation.  Without the
support and if the compiler needs to support many gas version, the
simplest solution would be to use -Wa,-mrelax-relocations=no.

    PR ld/24784
    * bfd/elf64-x86-64.c (elf_x86_64_check_tls_transition): Allow
      R_X86_64_GOTPCREL.

[gdb/testsuite] Fix gdb.python/py-completion.exp

With test-case gdb.python/py-completion.exp and target board
native-extended-gdbserver I get this warning:
...
(gdb) PASS: gdb.python/py-completion.exp: discard #2
completefilecommandcond $outputs/gdb.python/py-completion/py-completion-t^G\
  PASS: gdb.python/py-completion.exp: completefilecommandcond completion
Remote debugging from host ::1, port 53346^M
monitor exit^M
not implemented^M
(gdb) WARNING: Timed out waiting for EOF in server after monitor exit
...

Fix this by adding the missing "discard #3", such that we have instead:
...
(gdb) PASS: gdb.python/py-completion.exp: discard #2
completefilecommandcond $outputs/gdb.python/py-completion/py-completion-t^G\
  PASS: gdb.python/py-completion.exp: completefilecommandcond completion
 ^M
not implemented^M
(gdb) PASS: gdb.python/py-completion.exp: discard #3
Remote debugging from host ::1, port 36278^M
monitor exit^M
(gdb)
...

Tested on x86_64-linux.

[gdb/testsuite] Fix gdb.python/py-cmd.exp

[ Using $pp as shorthand for the pagination prompt
"--Type <RET> for more, q to quit, c to continue without paging--". ]

The test-case gdb.python/py-cmd.exp passes, but the handling of the
test_multiline command output looks a bit odd:
...
(gdb) test_multiline
test_multiline output
  ...
test_multiline output
$ppPASS: gdb.python/py-cmd.exp: verify pagination from test_multiline
q
test_multiline
Quit
(gdb) test_multiline
test_multiline output
  ...
test_multiline output
$ppPASS: gdb.python/py-cmd.exp: verify pagination from test_multiline: q
...

What happens is:
- a test_multiline command is issued
- some output is printed, followed by a pagination prompt
- the test-case concludes that pagination occurred, and produces a PASS
- "q\n" is replied to the pagination prompt
- without waiting for response to the "q\n", another test_multiline command is
  issued
- in response to the "q\n" we get "Quit\n(gdb) "
- some output is printed, followed by a pagination prompt
- the test-case concludes that there's a valid response to the "q\n", and
  produces a PASS, consuming the second pagination prompt, but without a reply.

My conclusion is that the second test_multiline command is unintentional, so fix
this by removing it.

Without it, we have the more straightforward:
...
(gdb) test_multiline
test_multiline output
  ...
test_multiline output
$ppPASS: gdb.python/py-cmd.exp: verify pagination from test_multiline
q
Quit
(gdb) PASS: gdb.python/py-cmd.exp: verify pagination from test_multiline: q
...

This also fixes the following warning with target board native-gdbserver:
...
WARNING: Timed out waiting for EOF in server after monitor exit
...

Tested on x86_64-linux.

[gdb/testsuite] Fix py-autoloaded-pretty-printers-in-newobjfile-event.exp for remote target

With test-case gdb.python/py-autoloaded-pretty-printers-in-newobjfile-event.exp
and target board remote-gdbserver-on-localhost, I run into:
...
FAIL: $exp: runto: run to main
...

I can easily fix this using "gdb_load_shlib $binfile_lib", but then run into:
...
(gdb) print all_good^M
$1 = false^M
(gdb) FAIL: $exp: print all_good
info pretty-printer^M
...

Sysroot is set to "target:", so gdb downloads the shared library from the target
(Using $so as shorthand for
libpy-autoloaded-pretty-printers-in-newobjfile-event.so):
...
Reading /home/remote-target/$so from remote target...^M
...
and internally refers to it as "target:/home/remote-target/$so".

In load_auto_scripts_for_objfile, gdb gives up trying to auto-load scripts
for $so once it checks for is_target_filename.

Fix this by declaring auto-load unsupported if sysroot starts with "target:".

Tested on x86_64-linux.

[gdb/testsuite] Fix gdb.python/py-event-load.exp for remote target

Fix test-case gdb.python/py-event-load.exp for target board
remote-gdbserver-on-localhost using gdb_download_shlib.

Tested on x86_64-linux.

Use require with test_compiler_info

One spot that checks test_compiler_info can be switched to use
'require'.

More uses of require with istarget

I found a few more spots that check istarget that can be switched to
use 'require'.

Use require with gdb_skip_stdio_test

One use of gdb_skip_stdio_test can use 'require'.

Use require with target_info

This changes many tests to use 'require' when checking target_info.
In a few spots, the require is hoisted to the top of the file, to
avoid doing any extra work when the test is going to be skipped
anyway.

Move allocate_stub_method to stabsread.c

allocate_stub_method is only called from stabsread.c, and I don't
think it will be needed anywhere else.  So, move it and make it
static.  Tested by rebuilding.

Revert ld ASCII support

Revert "Prevent the ASCII linker script directive from generating huge amounts of padding if the size expression is not a constant."
This reverts commit adbe951fc95943016325af08d677f18e8c177ac1.

Revert "ld test asciz and ascii fails"
This reverts the ascii.d part of commit 5f497256bee624f0fa470949aa41534093bc5b25.

Revert "Add support for the ASCII directive inside linker scripts."
This mostly reverts commit 9fe129a4105bb59398f73ce96938a94f19265b79
leaving the asciz.d and asciz.t changes in place.

Revert ld DIGEST support

This is a hopefully temporary reversion of new ld features for
embedded processors by Ulf Samuelsson, plus some followup patches.

Squashed together from the following:

Revert "lddigest 32-bit support and gcc-4 compile errors"
This reverts commit d7ee19be87110a8f5342cec6e323d83d01c641d1.

Revert "ld: Use correct types for crc64 calculations"
This reverts commit 9a534b9f8e3d0f3cdb5a20f19ff165693fbb84d2.

Revert "Re: DIGEST: testsuite"
This reverts commit c8e85484d8a0fe9f7b88e00a6b9ae63bcb53ba32.

Revert "Regen potfiles"
This reverts commit 4d98c966f8bf305ab25badd34cb295631873cf7c.

Revert "DIGEST: Makefile.*"
This reverts commit 78ef6ab03f56ce83a606d974bb8a9f34b5d6e0b7.

Revert "DIGEST: calculation"
This reverts commit 5243990191e683d5066d3dd622c76deaba0bf15c.

Revert "DIGEST: ldlang.*: add timestamp"
This reverts commit bd9466d4aa277a469a9d8b12f0a6e6fa51678e36.

Revert "DIGEST: ldmain.c"
This reverts commit c8f8653fa7eeb3dc0769ac23039eadb5c5f09dff.

Revert "DIGEST: ldgram.y"
This reverts commit d73c01be2669e9c5267fab669a269f95a32048c9.

Revert "DIGEST: ldlex.l"
This reverts commit 48b5163a9dd5759cc87171331bbd6e902c547b5a.

Revert "DIGEST: testsuite"
This reverts commit a4135d1a4886400ea29af2da782dd8dd40ccad23.

Revert "DIGEST: Documentation"
This reverts commit 3ec28966c3e4c63704212778f96c517cbf2e0090.

Revert "DIGEST: NEWS"
This reverts commit 099bf2927d446424e8585a60cf4ce63209999aa2.

Revert "DIGEST: LICENSING"
This reverts commit 5c8a0c6654fb55926985edf3b360b62d4f20691d.

Arm64/gas: drop redundant feature prereqs

Logic exists to deal with prereqs or prereqs, and in many cases
transitive prereqs are already not spelled out explicitly. Drop further
ones:
- FP is already a prereq to F16,
- SIMD and F16 are already prereqs to COMPNUM, and
- SVE2 and BFLOAT16 are already prereqs to SME.

Arm64/gas: add missing prereq features

A number of newer features are really SIMD or FP extensions, but don't
have this properly specified.

x86: decouple broadcast type and bytes fields

Keep both representing exclusively what was parsed from input, to avoid
the need for (potentially bogus) calculations when processing .insn.

x86-64: adjust REX-prefix part of SSE2AVX test

Before altering how build_modrm_byte() works, arrange for this part of
the testcase to actually use distinguishable source and destination
register numbers, such that incorrect propagation of, in particular, the
high bit encodings (from REX to VEX) can be noticed (in turn
specifically assertions [not] triggering in the respective code).

x86: move more disp processing out of md_assemble()

Put it in optimize_disp() such that it can then be re-used by .insn
handling. The movement makes it necessary (or at least very desirable,
to avoid introducing a fragile cast) to convert to local variable to
"unsigned", which in turn requires an adjustment to the pre-existing
loop header.

Having the caller pass in the specific template under consideration has
another benefit then: We can replace the two uses of current_templates
in the function as well, thus no longer looking at some merely "related"
template. (This may allow further tightening, but if so that's to be the
subject of another change.)

x86: use set_rex_vrex() also for short-form handling

This is benign for all existing insns, but is going to be needed for
handling of .insn operands. The earlier use requires moving up the
function, to avoid the need for a forward declaration.

eh static data

Fix another case of oss-fuzz tripping over gas static state,
ie. starting over testing another input file with rubbish left
uncleared in bss.  size_end_sym pointed at garbage.

* ehopt.c (get_cie_info): Delete forward declaration.
(struct frame_data): Move to file scope.
(frame): New static, packaged..
(check_eh_frame): ..eh_frame_data and debug_frame_data.
(eh_begin): New function.
* as.c (gas_init): Call eh_begin.
* as.h (eh_begin): Declare.

Automatic date update in version.in

gdb, gdbserver, gdbsupport: fix whitespace issues

Replace spaces with tabs in a bunch of places.

Change-Id: If0f87180f1d13028dc178e5a8af7882a067868b0

[gdb/testsuite] Fix gdb.threads/pending-fork-event-detach.exp for remote target

Fix test-case gdb.threads/pending-fork-event-detach.exp for target board
remote-gdbserver-on-localhost using gdb_remote_download for $touch_file_bin.

Then, fix the test-case for target board remote-stdio-gdbserver with
REMOTE_TMPDIR=~/tmp.remote-stdio-gdbserver by creating $touch_file_path
on target using remote_download, and using the resulting path.

Tested on x86_64-linux.

objdump: report no section contents

objdump's read_section is never used for bss-style sections, so to
plug a hole that fuzzers have found, exclude sections without
SEC_HAS_CONTENTS.

* objdump.c (read_section): Report and return an error on
a no contents section.

gas: allow frag address wrapping in absolute section

This:
 .struct -1
x:
 .fill 1
y:
results in an internal error in frag_new due to abs_section_offset
wrapping from -1 to 0.  Frags in the absolute section don't do much so
I think we can allow the address wrap.

* frags.c (frag_new): Allow address wrap in absolute section.

[gdb/testsuite] Fix gdb.threads/multiple-successive-infcall.exp on native-gdbserver

With test-case gdb.threads/multiple-successive-infcall.exp and target board
native-gdbserver I run into:
...
(gdb) continue^M
Continuing.^M
[New Thread 758.759]^M
^M
Thread 1 "multiple-succes" hit Breakpoint 2, main () at \
  multiple-successive-infcall.c:97^M
97            thread_ids[tid] = tid + 2; /* prethreadcreationmarker */^M
(gdb) FAIL: gdb.threads/multiple-successive-infcall.exp: thread=5: \
  created new thread
...

The problem is that the new thread message doesn't match the regexp, which
expects something like this instead:
...
[New Thread 0x7ffff746e700 (LWP 570)]^M
...

Fix this by accepting this form of new thread message.

Tested on x86_64-linux.

[gdb/testsuite] Fix gdb.threads/thread-specific-bp.exp on native-gdbserver

With test-case gdb.threads/thread-specific-bp.exp and target board
native-gdbserver I run into:
...
(gdb) PASS: gdb.threads/thread-specific-bp.exp: non_stop=off: thread 1 selected
continue^M
Continuing.^M
Thread-specific breakpoint 3 deleted - thread 2 no longer in the thread list.^M
^M
Thread 1 "thread-specific" hit Breakpoint 4, end () at \
  thread-specific-bp.c:29^M
29      }^M
(gdb) FAIL: gdb.threads/thread-specific-bp.exp: non_stop=off: \
  continue to end (timeout)
...

The problem is that the test-case tries to match the "[Thread ... exited]"
message which we do see with native testing:
...
Continuing.^M
[Thread 0x7ffff746e700 (LWP 7047) exited]^M
Thread-specific breakpoint 3 deleted - thread 2 no longer in the thread list.^M
...

The fact that the message is missing was reported as PR remote/30129.

We could add a KFAIL for this, but the functionality the test-case is trying
to test has nothing to do with the message, so it should pass.  I only added
matching of the message in commit 2e5843d87c4 ("[gdb/testsuite] Fix
gdb.threads/thread-specific-bp.exp") to handle a race, not realizing doing so
broke testing on native-gdbserver.

Fix this by matching the "Thread-specific breakpoint $decimal deleted" message
instead.

Tested on x86_64-linux.

[gdb/testsuite] Fix gdb.server/*.exp for remote target

Fix test-cases for target board remote-gdbserver-on-localhost by using
gdb_remote_download.

Tested on x86_64-linux.

[gdb/testsuite] Fix gdb.server/unittest.exp for remote target

With test-case gdb.server/unittest.exp and a build with --disable-unit-tests I
get:
...
(gdb) builtin_spawn /data/vries/gdb/leap-15-4/build/gdbserver/gdbserver \
  --selftest^M
Selftests have been disabled for this build.^M
UNSUPPORTED: gdb.server/unittest.exp: unit tests
...
but with target board remote-stdio-gdbserver I get instead:
...
(gdb) builtin_spawn /usr/bin/ssh -t -l vries localhost \
  /data/vries/gdb/leap-15-4/build/gdbserver/gdbserver --selftest^M
Selftests have been disabled for this build.^M
Connection to localhost closed.^M^M
FAIL: gdb.server/unittest.exp: unit tests
...

Fix this by making the regexp less strict.

Tested on x86_64-linux.

[gdb/testsuite] Fix gdbserver path in remote-stdio-gdbserver.exp

With test-case gdb.server/unittest.exp and target board remote-stdio-gdbserver
I run into:
...
(gdb) builtin_spawn /usr/bin/ssh -t -l vries localhost /usr/bin/gdbserver \
  --selftest^M
Selftests have been disabled for this build.^M
UNSUPPORTED: gdb.server/unittest.exp: unit tests
...
due to using the system gdbserver /usr/bin/gdbserver rather than the one from
the build.

Fix this by removing the hard-coding of /usr/bin/gdbserver in
remote-stdio-gdbserver, allowing find_gdbserver to do its work, such that we
have instead:
...
(gdb) builtin_spawn /usr/bin/ssh -t -l vries localhost \
  /data/vries/gdb/leap-15-4/build/gdbserver/gdbserver --selftest^M
Running selftest remote_memory_tagging.^M
Ran 1 unit tests, 0 failed^M
Connection to localhost closed.^M^M
PASS: gdb.server/unittest.exp: unit tests
...

Tested on x86_64-linux.

[gdb/testsuite] Fix gdb.server/sysroot.exp for remote target

Fix test-case gdb.server/sysroot.exp with target board
remote-gdbserver-on-localhost, by:
- using gdb_remote_download, and
- disabling the "local" scenario for remote host.

Tested on x86_64-linux.

[gdb/testsuite] Fix gdb.server/multi-ui-errors.exp for remote target

Test-case gdb.server/multi-ui-errors.exp fails for target board
remote-gdbserver-on-localhost with REMOTE_TARGET_USERNAME=remote-target:
...
(gdb) PASS: gdb.server/multi-ui-errors.exp: interact with GDB's main UI
Executing on target: kill -9 6447    (timeout = 300)
builtin_spawn [open ...]^M
XYZ1ZYX
sh: line 0: kill: (6447) - Operation not permitted
...

The problem is that the kill command:
...
remote_exec target "kill -9 $gdbserver_pid"
...
intended to kill gdbserver instead tries to kill the ssh client session in
which the gdbserver runs, and fails because it's trying as the remote target
user (remote-target on localhost) to kill a pid owned by the the build user
($USER on localhost).

Fix this by getting the gdbserver pid using the ppid trick from
server-kill.exp.

Likewise in gdb.server/server-kill-python.exp.

Tested on x86_64-linux.

[gdb/testsuite] Fix gdb.server/server-kill.exp for remote target

In commit 80dc83fd0e7 ("gdb/remote: handle target dying just before a stepi")
an observation is made that test-case gdb.server/server-kill.exp claims to
kill gdbserver, but actually kills the inferior.  Consequently, the commit
adds testing of killing gdbserver alongside.

The problem is that:
- the original observation is incorrect (possibly caused by misreading getppid
  as getpid)
- consequently, the test-case doesn't test killing the inferior, instead it
  tests killing gdbserver twice
- the method to get the gdbserver PID added in the commit doesn't work
  for target board remote-gdbserver-on-localhost, it returns the
  PID of the ssh client session instead.

Fixing the method for getting the inferior PID gives us fails, and there's no
evidence that killing the inferior ever worked.

So, fix this by reverting the commit and just killing gdbserver, using the
original method of getting the gdbserver PID which does work for target board
remote-gdbserver-on-localhost.

Tested on x86_64-linux.

[gdb/testsuite] Fix gdb.server/connect-with-no-symbol-file.exp for remote target

Test-case gdb.server/connect-with-no-symbol-file.exp fails with target board
remote-gdbserver-on-localhost.

The problem is here:
...
       set target_exec [gdb_remote_download target $binfile.bak $binfile]
...
A "gdb_remote_download target" copies from build to target.  So $binfile is
assumed to be a target path, but it's actually a build path.

Fix this by:
- fist copying $binfile.bak to $binfile, and
- simply doing [gdb_remote_download target $binfile].

Then, $binfile.bak is created here:
...
 # Make sure we have the original symbol file in a safe place to copy from.
 gdb_remote_download host $binfile $binfile.bak
...
and since "gdb_remote_download host" copies from build to host, $binfile.bak
is assumed to be a host path, but it's actually a build path.  This happens to
cause no problems in this configuration (because build == host), but it would
for a remote host configuration.

So let's fix this by making build rather than host the "safe place to copy
from".

Tested on x86_64-linux.

lddigest 32-bit support and gcc-4 compile errors

* ld.texi: Revert 2023-03-08 commit 9a534b9f8e3d.
* testsuite/ld-scripts/crc64-poly.d: Likewise.
* testsuite/ld-scripts/crc64-poly.t: Likewise.
* lddigest.c: Formatting.
(get_uint64_t): New function.
(lang_add_digest): Take etree_type* args.  Replace "illegal" with
"invalid" in error message.
* lddigest.h (lang_add_digest): Update prototype.
* lddigest_tab.c (algorithms): Work around gcc-4 errors.
* ldgram.y (polynome): Adjust lang_add_digest call.
* testsuite/ld-scripts/crc64-poly-size.d: Update expected error.

Automatic date update in version.in

Remove OBJF_REORDERED

OBJF_REORDERED is set for nearly every object format.  And, despite
the ominous warnings here and there, it does not seem very expensive.
This patch removes the flag entirely.

Reviewed-By: Andrew Burgess <aburgess@redhat.com>

PowerPC, fix test gdb.arch/altivec-regs.exp

The test fails on Power 10 with the RHEL9 distro.  It also fails on
Power 9.

The test set a the breakpoint in main that stops at line:
a = 9; /* start here */.  The test then sets a break point at the same
line where it wants to start the test and does a continue.  GDB does not
stop again on the same line where it is stopped, but rather continues to
the end of the program.

Initialize variable A to zero so the break on main will stop before setting
a break point on line a = 9; /* start here */.

Make the match on the breakpoint number generic.

Patch has been tested on Power 10 with RHEL 9, Power 10 with Ubuntu 22.04,
and Power 9 with Fedora 36 with no regression failures.

ld: Use correct types for crc64 calculations

Tidy pe_ILF_build_a_bfd a little

* peicode.h (ILF section, pe_ILF_object_p): Correct comments
and update the reference to Microsoft's docs.
(pe_ILF_build_a_bfd): Move all symbol creation before flipping
the bfd over to in-memory.

Re: DIGEST: testsuite

Correct test target/skip lines to fix fails on alpha-dec-vms,
alpha-linux-gnuecoff, i386-bsd, i386-msdos, ns32k-openbsd,
ns32k-pc532-mach, pdp11-dec-aout, rs6000-aix*, tic4x-coff, and
tic54x-coff.

Regen potfiles

Re: Move nm.c cached line number info to bfd usrdata

Commit e3f450f3933d resulted in a nm -l segfault on object files
without undefined symbols.  Fix that, and be paranoid about bfd
section count changing.

* nm.c (struct lineno_cache): Add seccount.
(free_lineno_cache): Don't segfault on NULL lc->relocs.
(print_symbol): Stash section count when creating arrays.

z8 and z80 coff_reloc16_extra_cases sanity checks

* reloc16.c (bfd_coff_reloc16_get_relocated_section_contents):
Use size_t variables.  Sanity check reloc address.  Handle
errors from bfd_coff_reloc16_extra_cases.
* coffcode.h (_bfd_coff_reloc16_extra_cases): Return bool, take
size_t* args.
(dummy_reloc16_extra_cases): Adjust to suit.  Don't abort.
* coff-z80.c (extra_case): Sanity check reloc address.  Return
errors.  Tidy formatting.  Use bfd_signed_vma temp var to
check for reloc overflow.  Don't abort on unexpected reloc type,
instead print an error and return false.
* coff-z8k.c (extra_case): Likewise.
* libcoff.h: Regenerate.

Automatic date update in version.in

gdb/amdgpu: provide dummy implementation of gdbarch_return_value_as_value

The AMD GPU support has been merged shortly after commit 4e1d2f5814b2
("Add new overload of gdbarch_return_value"), which made it mandatory
for architectures to provide either a return_value or
return_value_as_value implementation.  Because of my failure to test
properly after rebasing and before pushing, we get this with the current
master:

    $ gdb ./gdb -nx --data-directory=data-directory -q -ex "set arch amdgcn:gfx1010" -batch
    /home/simark/src/binutils-gdb/gdb/gdbarch.c:517: internal-error: verify_gdbarch: the following are invalid ...
            return_value_as_value

I started trying to change GDB to not force architectures to provide a
return_value or return_value_as_value implementation, but Andrew pointed
out that any serious port will have an implementation one day or
another, and it's easy to add a dummy implementation in the mean time.
So it's better to not complicate the core of GDB to know how to deal
with this.

There is an implementation of return_value in the downstream ROCgdb port
(which we'll need to convert to the new return_value_as_value), which
we'll contribute soon-ish.  In the mean time, add a dummy implementation
of return_value_as_value to avoid the failed assertion.

Change-Id: I26edf441b511170aa64068fd248ab6201158bb63
Reviewed-By: Lancelot SIX <lancelot.six@amd.com>

Merge forget_cached_source_info_for_objfile into objfile method

forget_cached_source_info_for_objfile does some objfile-specific work
and then calls objfile::forget_cached_source_info.  It seems better to
me to just have the method do all the work.

Clean up attribute reprocessing

I ran across the attribute reprocessing code recently and noticed that
it unconditionally sets members of the CU when reading a DIE.  Also,
each spot reading attributes needs to be careful to "reprocess" them
as a separate step.

This seemed excessive to me, because while reprocessing applies to any
DIE, setting the CU members is only necessary for the toplevel DIE in
any given CU.

This patch introduces a new read_toplevel_die function and changes a
few spots to call it.  This is easily done because reading the
toplevel DIE is already special.

I left the reprocessing flag and associated checks in attribute.  It
could be stripped out, but I am not sure it would provide much value
(maybe some iota of performance).

Regression tested on x86-64 Fedora 36.

gdb: initialize interp::next

This field is never initialized, it seems to me like it would be a good
idea to initialize it to nullptr to avoid bad surprises.

Change-Id: I8c04319d564f5d385d8bf0acee758f6ce28b4447
Reviewed-By: Tom Tromey <tom@tromey.com>

gdb: make interp::m_name an `const char *`

I realized that the memory for interp names does not need to be
allocated.  The name used to register interp factory functions is always
a literal string, so has static storage duration.  If we change
interp_lookup to pass that name instead of the string that it receives
as a parameter (which does not always have static storage duration),
then interps can simply store pointers to the name.

So, change interp_lookup to pass `factory.name` rather than `name`.
Change interp::m_name to be a `const char *` rather than an std::string.

Change-Id: I0474d1f7b3512e7d172ccd73018aea927def3188
Reviewed-By: Tom Tromey <tom@tromey.com>

gdb: make get_interp_info return a reference

get_interp_info and get_current_interp_info always return non-nullptr,
so they can return a reference instead of a pointer.

Since we don't need to copy it, make ui_interp_info non-copyiable, to
avoid a copying it in a local variable, instead of getting a reference.

Change-Id: I6d8dea92dc26a58ea340d04862db6b8d9cf906a0
Reviewed-By: Tom Tromey <tom@tromey.com>

Fix selfcheck regression due to new maint command

Simon points out that the new maint command, intended to fix a
regression, also introduces a new regression in "maint selftest".

This patch fixes the error.  I did a full regression test on x86-64
Fedora 36.

gprofng: read Dwarf 5

gprofng reads Dwarf to find function names, sources, and line numbers.
gprofng skips other debug information.
I fixed three places in gprofng Dwarf reader:
 - parsing the compilation unit header.
 - parsing the line number table header.
 - parsing new DW_FORMs.

Tested on aarch64-linux/x86_64-linux.

gprofng/ChangeLog
2023-03-05  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

PR gprofng/30195
gprofng/src/Dwarf.cc: Support Dwarf-5.
gprofng/src/DwarfLib.cc: Likewise.
gprofng/src/Dwarf.h: Likewise.
gprofng/src/DwarfLib.h: Likewise.
gprofng/src/collctrl.cc: Don't read freed memory.

gdb: Fix GDB_AC_CHECK_BFD macro regression

Commit 5218fa9e8937b007d554f1e01c2e4ecdb9b7e271, "gdb: use libtool in
GDB_AC_CHECK_BFD" dropped passing in existing LDFLAGS. In our environment,
this caused the configure check "checking for ELF support in BFD" to stop
working causing build failures as we need our LDFLAGS to be used for
correct linking.

That change also meant the code failed to match the comments. Add back the
missing LDFLAGS preservation, fix our builds and match the comment.

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Change-Id: Ie91509116fab29f95b9db1ff0b6ddc280d460112
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Reviewed-By: Jose E. Marchesi <jose.marchesi@oracle.com>

Enable vector instruction debugging for AIX

AIX now supports vector register contents debugging for both VMX
VSX registers.

[gdb/testsuite] Fix gdb.threads/execl.exp for remote target

Fix test-case gdb.threads/execl.exp on target board
remote-gdbserver-on-localhost using gdb_remote_download.

Tested on x86_64-linux.

Ensure index cache entry written in test

Now that index cache files are written in the background, one test in
index-cache.exp is racy -- it assumes that the cache file will have
been written during startup.

This patch fixes the problem by introducing a new maintenance command
to wait for all pending writes to the index cache.

Approved-By: Simon Marchi <simon.marchi@efficios.com>
Reviewed-By: Eli Zaretskii <eliz@gnu.org>

[gdb/testsuite] Fix gdb.base/skip-solib.exp for remote target

Fix test-case gdb.base/skip-solib.exp for target board
remote-gdbserver-on-localhost using gdb_load_shlib.

Tested on x86_64-linux.

[gdb/testsuite] Use shlib gdb_compile option in gdb.base/skip-solib.exp

In test-case gdb.base/skip-solib.exp the linking against a shared library is
done manually:
...
if {[gdb_compile "${binfile_main}.o" "${binfile_main}" executable \
        [list debug "additional_flags=-L$testobjdir" \
             "additional_flags=-l${test}" \
             "ldflags=-Wl,-rpath=$testobjdir"]] != ""} {
...

Instead, use the shlib gdb_compile option such that we simply have:
...
        [list debug shlib=$binfile_lib]] != ""} {
...

Tested on x86_64-linux.

[gdb/testsuite] Fix gdb.base/fork-no-detach-follow-child-dlopen.exp for remote target

Fix test-case gdb.base/fork-no-detach-follow-child-dlopen.exp for target board
remote-gdbserver-on-localhost.exp by using gdb_download_shlib and gdb_locate_shlib.

Tested on x86_64-linux.

[gdb/testsuite] Fix gdb.base/break-probes.exp for remote target

With test-case gdb.base/break-probes.exp and target board
remote-gdbserver-on-localhost (using REMOTE_TARGET_USERNAME) we run into some
failures.

Fix these by adding the missing gdb_download_shlib and gdb_locate_shlib.

Tested on x86_64-linux.

[gdb/testsuite] Fix gdb.dwarf2/dw2-zero-range.exp for remote-gdbserver-on-localhost

Fix test-case gdb.dwarf2/dw2-zero-range.exp for target board
remote-gdbserver-on-localhost using gdb_load_shlib.

Tested on x86_64-linux.

Build ldint

Signed-off-by: Ulf Samuelsson <ulf@emagii.com>

DIGEST: Makefile.*

The Makefile.in was generated using automake
after adding a few files.

When adding the ldreflect.* files, the autotools
versions were wrong.
After upgrading the host OS, autotools were upgraded to 2.71
reinstalling the desired 2.69 still generates a lot of changes.

Makefile.ini has therefore been manually edited.

Signed-off-by: Ulf Samuelsson <ulf@emagii.com>

DIGEST: calculation

Signed-off-by: Ulf Samuelsson <ulf@emagii.com>