aarch64: Fix SVE2 register/immediate distinction

GAS refuses to interpret register names like x0 as unadorned
immediates, due to the obvious potential for confusion with
register operands.  (An explicit #x0 is OK.)

For compatibility reasons, we can't extend the set of registers
that GAS rejects for existing instructions.  For example:

   mov x0, z0

was valid code before SVE was added, so it needs to stay valid
code even when SVE is enabled.  But we can make GAS reject newer
registers in newer instructions.  The SVE instruction:

   and z0.s, z0.s, z0.h

is therefore invalid, rather than z0.h being an immediate.

This patch extends the SVE behaviour to SVE2.  The old call
to AARCH64_CPU_HAS_FEATURE was technically the wrong way around,
although it didn't matter in practice for base SVE instructions
since their avariants only set SVE.

aarch64: Restrict range of PRFM opcodes

In the register-index forms of PRFM, the unallocated prefetch opcodes
24-31 have been reused for the encoding of the new RPRFM instruction.
The PRFM opcode space is now capped at 23 for these forms.  The other
forms of PRFM are unaffected.

aarch64: Fix PSEL opcode mask

The opcode mask for PSEL was missing some bits, which meant
that some upcoming SME2 opcodes would be misinterpreted as PSELs.

aarch64: Add sme-i16i64 and sme-f64f64 aliases

Most extension flags are named after the associated architectural
FEAT_* flags, but sme-i64 and sme-f64 were exceptions.  This patch
adds sme-i16i64 and sme-f64f64 aliases, but keeps the old names too
for compatibility.

Fix an illegal memory access triggered by parsing corrupt DWARF info.

  PR 30284
  * dwarf.c (read_and_display_attr_value): Detect and ignore negative base values.

gdb/python: Add new gdb.unwinder.FrameId class

When writing an unwinder it is necessary to create a new class to act
as a frame-id.  This new class is almost certainly just going to set a
'sp' and 'pc' attribute within the instance.

This commit adds a little helper class gdb.unwinder.FrameId that does
this job.  Users can make use of this to avoid having to write out
standard boilerplate code any time they write an unwinder.

Of course, if the user wants their FrameId class to be more
complicated in some way, then they can still write their own class,
just like they could before.

I've simplified the example code in the documentation to now use the
new helper class, and I've also made use of this helper within the
testsuite.

Any existing user code will continue to work just as it did before
after this change.

Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Reviewed-By: Tom Tromey <tom@tromey.com>

gdb/python: Allow gdb.UnwindInfo to be created with non gdb.Value args

Currently when creating a gdb.UnwindInfo object a user must call
gdb.PendingFrame.create_unwind_info and pass a frame-id object.

The frame-id object should have at least a 'sp' attribute, and
probably a 'pc' attribute too (it can also, in some cases have a
'special' attribute).

Currently all of these frame-id attributes need to be gdb.Value
objects, but the only reason for that requirement is that we have some
code in py-unwind.c that only handles gdb.Value objects.

If instead we switch to using get_addr_from_python in py-utils.c then
we will support both gdb.Value objects and also raw numbers, which
might make things simpler in some cases.

So, I started rewriting pyuw_object_attribute_to_pointer (in
py-unwind.c) to use get_addr_from_python.  However, while looking at
the code I noticed a problem.

The pyuw_object_attribute_to_pointer function returns a boolean flag,
if everything goes OK we return true, but we return false in two
cases, (1) when the attribute is not present, which might be
acceptable, or might be an error, and (2) when we get an error trying
to extract the attribute value, in which case a Python error will have
been set.

Now in pending_framepy_create_unwind_info we have this code:

  if (!pyuw_object_attribute_to_pointer (pyo_frame_id, "sp", &sp))
    {
      PyErr_SetString (PyExc_ValueError,
       _("frame_id should have 'sp' attribute."));
      return NULL;
    }

Notice how we always set an error.  This will override any error that
is already set.

So, if you create a frame-id object that has an 'sp' attribute, but
the attribute is not a gdb.Value, then currently we fail to extract
the attribute value (it's not a gdb.Value) and set this error in
pyuw_object_attribute_to_pointer:

  rc = pyuw_value_obj_to_pointer (pyo_value.get (), addr);
  if (!rc)
    PyErr_Format (
        PyExc_ValueError,
        _("The value of the '%s' attribute is not a pointer."),
        attr_name);

Then we return to pending_framepy_create_unwind_info and immediately
override this error with the error about 'sp' being missing.

This all feels very confused.

Here's my proposed solution: pyuw_object_attribute_to_pointer will now
return a tri-state enum, with states OK, MISSING, or ERROR.  The
meanings of these states are:

  OK - Attribute exists and was extracted fine,

  MISSING - Attribute doesn't exist, no Python error was set.

  ERROR - Attribute does exist, but there was an error while
     extracting it, a Python error was set.

We need to update pending_framepy_create_unwind_info, the only user of
pyuw_object_attribute_to_pointer, but now I think things are much
clearer.  Errors from lower levels are not blindly overridden with the
generic meaningless error message, but we still get the "missing 'sp'
attribute" error when appropriate.

This change also includes the switch to get_addr_from_python which was
what started this whole journey.

For well behaving user code there should be no visible changes after
this commit.

For user code that hits an error, hopefully the new errors should be
more helpful in figuring out what's gone wrong.

Additionally, users can now use integers for the 'sp' and 'pc'
attributes in their frame-id objects if that is useful.

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

gdb: have value_as_address call unpack_pointer

While refactoring some other code in gdb/python/* I wanted to merge
two code paths.  One path calls value_as_address, while the other
calls unpack_pointer.

I suspect calling value_as_address is the correct choice, but, while
examining the code I noticed that value_as_address calls unpack_long
rather than unpack_pointer.

Under the hood, unpack_pointer does just call unpack_long so there's
no real difference here, but it feels like value_as_address should
call unpack_pointer.

I've updated the code to use unpack_pointer, and changed a related
comment to say that we call unpack_pointer.  I've also adjusted the
header comment on value_as_address.  The existing header refers to
some code that is now commented out.

Rather than trying to describe the whole algorithm of
value_as_address, which is already well commented within the function,
I've just trimmed the comment on value_as_address to be a brief
summary of what the function does.

There should be no user visible changes after this commit.

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

gdb/python: remove Py_TPFLAGS_BASETYPE from gdb.UnwindInfo

It is not currently possible to directly create gdb.UnwindInfo
instances, they need to be created by calling
gdb.PendingFrame.create_unwind_info so that the newly created
UnwindInfo can be linked to the pending frame.

As such there's no tp_init method defined for UnwindInfo.

A consequence of all this is that it doesn't really make sense to
allow sub-classing of gdb.UnwindInfo.  Any sub-class can't call the
parents __init__ method to correctly link up the PendingFrame
object (there is no parent __init__ method).  And any instances that
sub-classes UnwindInfo but doesn't call the parent __init__ is going
to be invalid for use in GDB.

This commit removes the Py_TPFLAGS_BASETYPE flag from the UnwindInfo
class, which prevents the class being sub-classed.  Then I've added a
test to check that this is indeed prevented.

Any functional user code will not have any issues with this change.

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

gdb/python: add __repr__ for PendingFrame and UnwindInfo

Having a useful __repr__ method can make debugging Python code that
little bit easier.  This commit adds __repr__ for gdb.PendingFrame and
gdb.UnwindInfo classes, along with some tests.

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

gdb/python: add some additional methods to gdb.PendingFrame

The gdb.Frame class has far more methods than gdb.PendingFrame.  Given
that a PendingFrame hasn't yet been claimed by an unwinder, there is a
limit to which methods we can add to it, but many of the methods that
the Frame class has, the PendingFrame class could also support.

In this commit I've added those methods to PendingFrame that I believe
are safe.

In terms of implementation: if I was starting from scratch then I
would implement many of these (or most of these) as attributes rather
than methods.  However, given both Frame and PendingFrame are just
different representation of a frame, I think there is value in keeping
the interface for the two classes the same.  For this reason
everything here is a method -- that's what the Frame class does.

The new methods I've added are:

  - gdb.PendingFrame.is_valid: Return True if the pending frame
    object is valid.

  - gdb.PendingFrame.name: Return the name for the frame's function,
    or None.

  - gdb.PendingFrame.pc: Return the $pc register value for this
    frame.

  - gdb.PendingFrame.language: Return a string containing the
    language for this frame, or None.

  - gdb.PendingFrame.find_sal: Return a gdb.Symtab_and_line object
    for the current location within the pending frame, or None.

  - gdb.PendingFrame.block: Return a gdb.Block for the current
    pending frame, or None.

  - gdb.PendingFrame.function: Return a gdb.Symbol for the current
    pending frame, or None.

In every case I've just copied the implementation over from gdb.Frame
and cleaned the code slightly e.g. NULL to nullptr.  Additionally each
function required a small update to reflect the PendingFrame type, but
that's pretty minor.

There are tests for all the new methods.

For more extensive testing, I added the following code to the file
gdb/python/lib/command/unwinders.py:

  from gdb.unwinder import Unwinder

  class TestUnwinder(Unwinder):
      def __init__(self):
          super().__init__("XXX_TestUnwinder_XXX")

      def __call__(self,pending_frame):
          lang = pending_frame.language()
          try:
              block = pending_frame.block()
              assert isinstance(block, gdb.Block)
          except RuntimeError as rte:
              assert str(rte) == "Cannot locate block for frame."
          function = pending_frame.function()
          arch = pending_frame.architecture()
          assert arch is None or isinstance(arch, gdb.Architecture)
          name = pending_frame.name()
          assert name is None or isinstance(name, str)
          valid = pending_frame.is_valid()
          pc = pending_frame.pc()
          sal = pending_frame.find_sal()
          assert sal is None or isinstance(sal, gdb.Symtab_and_line)
          return None

  gdb.unwinder.register_unwinder(None, TestUnwinder())

This registers a global unwinder that calls each of the new
PendingFrame methods and checks the result is of an acceptable type.
The unwinder never claims any frames though, so shouldn't change how
GDB actually behaves.

I then ran the testsuite.  There was only a single regression, a test
that uses 'disable unwinder' and expects a single unwinder to be
disabled -- the extra unwinder is now disabled too, which changes the
test output.  So I'm reasonably confident that the new methods are not
going to crash GDB.

Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Reviewed-By: Tom Tromey <tom@tromey.com>

gdb/python: add PENDING_FRAMEPY_REQUIRE_VALID macro in py-unwind.c

This commit copies the pattern that is present in many other py-*.c
files: having a single macro to check that the Python object is still
valid.

This cleans up the code a little throughout the py-unwind.c file.

Some of the exception messages will change slightly with this commit,
though the type of the exceptions is still ValueError in all cases.

I started writing some tests for this change and immediately ran into
a problem: GDB would crash.  It turns out that the PendingFrame
objects are not being marked as invalid!

In pyuw_sniffer where the pending frames are created, we make use of a
scoped_restore to invalidate the pending frame objects.  However, this
only restores the pending_frame_object::frame_info field to its
previous value -- and it turns out we never actually give this field
an initial value, it's left undefined.

So, when the scoped_restore (called invalidate_frame) performs its
cleanup, it actually restores the frame_info field to an undefined
value.  If this undefined value is not nullptr then any future
accesses to the PendingFrame object result in undefined behaviour and
most likely, a crash.

As part of this commit I now initialize the frame_info field, which
ensures all the new tests now pass.

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

gdb/python: remove unneeded nullptr check in frapy_block

Spotted a redundant nullptr check in python/py-frame.c in the function
frapy_block.  This was introduced in commit 57126e4a45e3000e when we
expanded an earlier check in return early if the pointer in question
is nullptr.

There should be no user visible changes after this commit.

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

gdb/python: make the gdb.unwinder.Unwinder class more robust

This commit makes a few related changes to the gdb.unwinder.Unwinder
class attributes:

  1. The 'name' attribute is now a read-only attribute.  This prevents
  user code from changing the name after registering the unwinder.  It
  seems very unlikely that any user is actually trying to do this in
  the wild, so I'm not very worried that this will upset anyone,

  2. We now validate that the name is a string in the
  Unwinder.__init__ method, and throw an error if this is not the
  case.  Hopefully nobody was doing this in the wild.  This should
  make it easier to ensure the 'info unwinder' command shows sane
  output (how to display a non-string name for an unwinder?),

  3. The 'enabled' attribute is now implemented with a getter and
  setter.  In the setter we ensure that the new value is a boolean,
  but the real important change is that we call
  'gdb.invalidate_cached_frames()'.  This means that the backtrace
  will be updated if a user manually disables an unwinder (rather than
  calling the 'disable unwinder' command).  It is not unreasonable to
  think that a user might register multiple unwinders (relating to
  some project) and have one command that disables/enables all the
  related unwinders.  This command might operate by poking the enabled
  attribute of each unwinder object directly, after this commit, this
  would now work correctly.

There's tests for all the changes, and lots of documentation updates
that both cover the new changes, but also further improve (I think)
the general documentation for GDB's Unwinder API.

Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Reviewed-By: Tom Tromey <tom@tromey.com>

Fix an illegal memory access when an accessing a zer0-lengthverdef table.

  PR 30285
  * elf.c (_bfd_elf_slurp_version_tables): Fail if no version definitions are allocated.

gprofng: Add version symbols to libgprofng.ver

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

PR gprofng/30089
* libcollector/libgprofng.ver: Add version symbols.
* libcollector/synctrace.c: Fix typo for pthread_mutex_lock.

Setting sh_link for SHT_REL/SHT_RELA

It's wrong to have an alloc reloc section trying to use a non-alloc
symbol table.

* elf.c (assign_section_numbers <SHT_REL, SHT_RELA>): Correct
comment.  Always set sh_link to .dynsym for alloc reloc
sections and to .symtab for non-alloc.

Fix memory leak in bfd_get_debug_link_info_1

* opncls.c (bfd_get_alt_debug_link_info): Don't bother freeing
after bfd_malloc_and_get_section failure.
(get_build_id): Likewise.
(bfd_get_debug_link_info_1): Likewise.  Free section contents
when crc not present.
* section.c (bfd_malloc_and_get_section): Document that the
buffer is NULL on error return.

Tidy leaked objcopy memory

* objcopy.c (delete_symbol_htabs): Also free symbols.
(write_debugging_info): Free strings and syms once written.
* wrstabs.c (write_stabs_in_sections_debugging_info): memset
entire info struct.  Free hash tables before returning.  Free
syms on error return.

Tidy memory on addr2line failures

* addr2line.c (process_file): Close bfd on error paths.

Fix typo in ld manual --enable-non-contiguous-regions example

Automatic date update in version.in

RISC-V: PR28789, Reject R_RISCV_PCREL relocations with ABS symbol in PIC/PIE.

The non-preemptible SHN_ABS symbol with a pc-relative relocation should be
disallowed when generating shared object (pic and pie).  Generally, the
following cases, which refer to pr25749, will cause a symbol be
non-preemptible,

* -pie, or -shared with -symbolic
* STV_HIDDEN, STV_INTERNAL, STV_PROTECTED
* Have dynamic symbol table, but without the symbol
* VER_NDX_LOCAL

However, PCREL_HI20/LO12 relocs are always bind locally when generating
shared object, so not only the non-preemptible absolute symbol need to
be disallowed, all absolute symbol references need but except that they
are defined in linker script.  If we also disallow the absolute symbol
in linker script, then the glibc-linux toolchain build failed, so regard
them as pc-relative symbols, just like what x86 did.

Maybe we should add this check for all pc-relative relocations, rather
than just handle in R_RISCV_PCREL relocs.  Ideally, since the value of
SHN_ABS symbol is a constant, only S - A relocations should be allowed
in the shared object, so only BFD_RELOC_8/16/32/64 are allowed, which
means R_RISCV_32/R_RISCV_64.

bfd/
    PR 28789
    * elfnn-riscv.c (riscv_elf_check_relocs): The absolute symbol cannot be
    referneced with pc-relative relocation when generating shared object.
ld/
    PR 28789
    * ld/testsuite/ld-riscv-elf/ld-riscv-elf.exp: Updated.
    * ld/testsuite/ld-riscv-elf/pcrel-reloc*: New testcases.

RISC-V: Clarify link behaviors of R_RISCV_32/64 relocations with ABS symbol.

There are two improvements, which are all referenced to aarch64,

* R_RISCV_32 with non ABS symbol cannot be used under RV64 when making
  shard objects.

* Don't need dynamic relocation for R_RISCV_32/64 under RV32/RV64 when
  making shared objects, if the referenced symbol is local ABS symbol.

However, considering this link,
https://github.com/riscv-non-isa/riscv-elf-psabi-doc/issues/341

Seems like we should makes all R_RISCV_32/64 relocs with ABS symbol
that don't need any dynamic relocations when making the shared objects.
But anyway, I just sync the current behavior as aarch64 ld, in case
there are any unexpected behaviors happen.

Passed the gcc/binutils regressions in riscv-gnu-toolchain.

bfd/
    * elfnn-riscv.c (riscv_elf_check_relocs): Only allow R_RISCV_32 with ABS
    symbol under RV64.
    (riscv_elf_relocate_section): R_RISCV_32/64 with local ABS symbol under
    RV32/RV64 doesn't need any dynamic relocation when making shared objects.
    I just make the implementations similar to other targets, so that will be
    more easy to mainatain.
ld/
    * testsuite/ld-riscv-elf/data-reloc*: New testcases.
    * testsuite/ld-riscv-elf/ld-riscv-elf.exp: Added new data-reloc* testcases,
    and need to make ifunc-seperate* testcases work for rv32.
    * testsuite/ld-riscv-elf/ifunc-seperate-caller-nonplt.s: Likewise.
    * testsuite/ld-riscv-elf/ifunc-seperate-caller-plt.s: Likewise.

RISC-V: Extract the ld code which are too complicated, and may be reused.

These types of codes are different for each target, I am not sure what are the
best for RISC-V, so extract them out may be more easy to compare what's the
difference.

bfd/
    * elfnn-riscv.c (RISCV_NEED_DYNAMIC_RELOC): New defined.  Extracted
    from riscv_elf_check_relocs, to see if dynamic reloc is needed for the
    specific relocation.
    (RISCV_GENERATE_DYNAMIC_RELOC): New defined.  Extracted from
    riscv_elf_relocate_section, to see if R_RISCV_32/64 need to generate
    dynamic relocation.
    (RISCV_COPY_INPUT_RELOC): New defined.  Extracted from
    riscv_elf_relocate_section, to see if R_RISCV_32/64 need to copy itslef
    tp output file.
    (RISCV_RESOLVED_LOCALLY): New defined.  Extracted from
    riscv_elf_relocate_section, to see if R_RISCV_GOT_HI20 can be resolved
    locally.

Use the correct frame when evaluating a dynamic property

The test case in this patch shows an unusual situation: an Ada array
has a dynamic bound, but the bound comes from a frame that's referred
to by the static link.  This frame is correctly found when evaluating
the array variable itself, but is lost when evaluating the array's
bounds.

This patch fixes the problem by passing this frame through to
value_at_lazy in the DWARF expression evaluator.

Pass a frame to value_at_lazy and value_from_contents_and_address

This patch adds a 'frame' parameter to value_at_lazy and ensures that
it is passed down to the call to resolve_dynamic_type.  This required
also adding a frame parameter to value_from_contents_and_address.

Nothing passes this parameter to value_at_lazy yet, so this patch
should have no visible effect.

Add frame parameter to resolve_dynamic_type

This adds a frame parameter to resolve_dynamic_type and arranges for
it to be passed through the call tree and, in particular, to all calls
to dwarf2_evaluate_property.

Nothing passes this parameter yet, so this patch should have no
visible effect.

A 'const frame_info_ptr *' is used here to avoid including frame.h
from gdbtypes.h.

Remove version_at_least

version_at_least is a less capable variant of version_compare, so this
patch removes it.

Rewrite version_compare and rust_at_least

This rewrites version_compare to allow the input lists to have
different lengths, then rewrites rust_at_least to use version_compare.

Introduce rust_at_least helper proc

This adds a 'rust_at_least' helper proc, for checking the version of
the Rust compiler in use.  It then changes various tests to use this
with 'require'.

[gdb/testsuite] Require gnatmake 11 for gdb.ada/verylong.exp

With test-case gdb.ada/verylong.exp and gnatmake 7.5.0 I run into:
...
compilation failed: gcc ... $src/gdb/testsuite/gdb.ada/verylong/prog.adb
prog.adb:16:11: warning: file name does not match unit name, should be "main.adb"
prog.adb:17:08: "Long_Long_Long_Integer" is undefined (more references follow)
gnatmake: "prog.adb" compilation error

FAIL: gdb.ada/verylong.exp: compilation prog.adb
...

AFAICT, support for Long_Long_Long_Integer was added in gcc 11.

Fix this by requiring gnatmake version 11 or higher in the test-case.

Tested on x86_64-linux.

doc: fix informations typo in gdb.texinfo

Co-Authored-By: Christina Schimpe <christina.schimpe@intel.com>

gdb, infcmd: remove redundant ERROR_NO_INFERIOR in continue_command

The ERROR_NO_INFERIOR macro is already called at the beginning of the
function continue_command.  Since target/inferior are not switched in-between,
the second call to it is redundant.

Co-Authored-By: Christina Schimpe <christina.schimpe@intel.com>

gdb: move displaced_step_dump_bytes into gdbsupport (and rename)

It was pointed out during review of another patch that the function
displaced_step_dump_bytes really isn't specific to displaced stepping,
and should really get a more generic name and move into gdbsupport/.

This commit does just that.  The function is renamed to
bytes_to_string and is moved into gdbsupport/common-utils.{cc,h}.  The
function implementation doesn't really change. Much...

... I have updated the function to take an array view, which makes it
slightly easier to call in a couple of places where we already have a
gdb::bytes_vector.  I've then added an inline wrapper to convert a raw
pointer and length into an array view, which is used in places where
we don't easily have a gdb::bytes_vector (or similar).

Updated all users of displaced_step_dump_bytes.

There should be no user visible changes after this commit.

Finally, I ended up having to add an include of gdb_assert.h into
array-view.h.  When I include array-view.h into common-utils.h I ran
into build problems because array-view.h calls gdb_assert.

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

gdb: more debug output for displaced stepping

While investigating a displaced stepping issue I wanted an easy way to
see what GDB thought the original instruction was, and what
instruction GDB replaced that with when performing the displaced step.

We do print out the address that is being stepped, so I can track down
the original instruction, I just need to go find the information
myself.

And we do print out the bytes of the new instruction, so I can figure
out what the replacement instruction was, but it's not really easy.

Also, the code that prints the bytes of the replacement instruction
only prints 4 bytes, which clearly isn't always going to be correct.

In this commit I remove the existing code that prints the bytes of the
replacement instruction, and add two new blocks of code to
displaced_step_prepare_throw.  This new code prints the original
instruction, and the replacement instruction.  In each case we print
both the bytes that make up the instruction and the completely
disassembled instruction.

Here's an example of what the output looks like on x86-64 (this is
with 'set debug displaced on').  The two interesting lines contain the
strings 'original insn' and 'replacement insn':

  (gdb) step
  [displaced] displaced_step_prepare_throw: displaced-stepping 2892655.2892655.0 now
  [displaced] displaced_step_prepare_throw: original insn 0x401030: ff 25 e2 2f 00 00 jmp    *0x2fe2(%rip)        # 0x404018 <puts@got.plt>
  [displaced] prepare: selected buffer at 0x401052
  [displaced] prepare: saved 0x401052: 1e fa 31 ed 49 89 d1 5e 48 89 e2 48 83 e4 f0 50
  [displaced] fixup_riprel: %rip-relative addressing used.
  [displaced] fixup_riprel: using temp reg 2, old value 0x7ffff7f8a578, new value 0x401036
  [displaced] amd64_displaced_step_copy_insn: copy 0x401030->0x401052: ff a1 e2 2f 00 00 68 00 00 00 00 e9 e0 ff ff ff
  [displaced] displaced_step_prepare_throw: prepared successfully thread=2892655.2892655.0, original_pc=0x401030, displaced_pc=0x401052
  [displaced] displaced_step_prepare_throw: replacement insn 0x401052: ff a1 e2 2f 00 00 jmp    *0x2fe2(%rcx)
  [displaced] finish: restored 2892655.2892655.0 0x401052
  [displaced] amd64_displaced_step_fixup: fixup (0x401030, 0x401052), insn = 0xff 0xa1 ...
  [displaced] amd64_displaced_step_fixup: restoring reg 2 to 0x7ffff7f8a578
  0x00007ffff7e402c0 in puts () from /lib64/libc.so.6
  (gdb)

One final note.  For many targets that support displaced stepping (in
fact all targets except ARM) the replacement instruction is always a
single instruction.  But on ARM the replacement could actually be a
series of instructions.

The debug code tries to handle this by disassembling the entire
displaced stepping buffer.  Obviously this might actually print more
than is necessary, but there's (currently) no easy way to know how
many instructions to disassemble; that knowledge is all locked in the
architecture specific code.  Still I don't think it really hurts, if
someone is looking at this debug then hopefully they known what to
expect.

Obviously we can imagine schemes where the architecture specific
displaced stepping code could communicate back how many bytes its
replacement sequence was, and then our debug print code could use this
to limit the disassembly.  But this seems like a lot of effort just to
save printing a few additional instructions in some debug output.

I'm not proposing to do anything about this issue for now.

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

[gdb/testsuite] Fix gdb.guile/scm-symbol.exp for remote host

Fix test-case gdb.guile/scm-symbol.exp for remote host by making a regexp less
strict.

Likewise in gdb.guile/scm-symtab.exp.

Tested on x86_64-linux.

[gdb/testsuite] Fix /gdb.guile/scm-parameter.exp for remote host

Fix test-case gdb.guile/scm-parameter.exp for remote host by taking into
account that gdb_reinitialize_dir has no effect for remote host.

Tested on x86_64-linux.

[gdb/testsuite] Fix gdb.guile/scm-objfile-script.exp for remote host

Fix test-case gdb.guile/scm-objfile-script.exp using gdb_remote_download.

Tested on x86_64-linux.

[gdb/testsuite] Fix gdb.guile/scm-objfile-script.exp for remote host

Fix test-case gdb.guile/scm-objfile-script.exp using host_standard_output_file.

Tested on x86_64-linux.

[gdb/testsuite] Fix gdb.guile/scm-cmd.exp without readline

Fix test-case gdb.guile/scm-cmd.exp using readline_is_used.

Tested on x86_64-linux.

[gdb/testsuite] Fix gdb.guile/guile.exp for remote host

Fix test-case gdb.guile/guile.exp for remote host using gdb_remote_download.

Tested on x86_64-linux.

Sanity check section size in bfd_init_section_compress_status

This function doesn't just initialise for compression, it actually
compresses.  This patch sanity checks section size before allocating
buffers for the uncompressed contents.

* compress.c (bfd_init_section_compress_status): Sanity check
section size.

Re: Fix an aout memory leak

We have way too much duplicated code in bfd.  Apply dd3a3d0af9f6 and
920581c57e08 to pdp11.c.

* pdp11.c (bfd_free_cached_info): Free line_buf.  Return true
if tdata.aout_data is NULL.

ld testsuite CFLAGS_FOR_TARGET

run_host_cmd adds $gcc_B_opt and $ld_L_opt to the command line if it
detects the program being run is a compiler.  Since the program being
run in lto.exp linking pr28138 is "sh", we need to add these by hand.
This isn't exactly as run_host_cmd does, as it lacks reordering of
any user -B option in $CC_FOR_TARGET, but it's better than ignoring
gcc_B_opt.  This fixes a mips64 testsuite fail.

ld_compile adds CFLAGS_FOR_TARGET and other flags as well, so there
is no need for the ld_compile command line to include
CFLAGS_FOR_TARGET.  Fixing this is just a tidy.

* testsuite/ld-plugin/lto.exp: Add gcc_B_opt, CFLAGS_FOR_TARGET
and $ld_L_opt to pr28138 link line.
* testsuite/lib/ld-lib.exp (run_ld_link_tests): Don't pass
unnecessary flags to ld_compile.
(run_ld_link_exec_tests, run_cc_link_tests): Likewise.

Automatic date update in version.in

Rename "raw" to "unrelocated"

Per an earlier discussion, this patch renames the existing "raw" APIs
to use the word "unrelocated" instead.

Use unrelocated_addr in minimal symbols

This changes minimal symbols to use unrelocated_addr.  I believe this
detected a latent bug in add_pe_forwarded_sym.

Use unrelocated_addr in psymbols

This changes psymbols themselves to use unrelocated_addr.  This
transform is largely mechanical.  I don't think it finds any bugs.

Use unrelocated_addr in partial symbol tables

This changes partial symbol tables to use unrelocated_addr for the
text_high and text_low members.  This revealed some latent bugs in
ctfread.c, which are fixed here.

Move definition of unrelocated_addr earlier

This moves the definition of unrelocated_addr a bit earlier in
symtab.h, so that it can be used elsewhere in the file.

Use function_view in gdb_bfd_lookup_symbol

This changes gdb_bfd_lookup_symbol to use a function_view.  This
simplifies the code a little bit.

[gdb/testsuite] Fix gdb.btrace/multi-inferior.exp for remote host

Fix test-case gdb.btrace/multi-inferior.exp for remote host using
gdb_remote_download.

Tested on x86_64-linux.

[gdb/testsuite] Fix gdb.btrace/gcore.exp for remote host

Fix test-case gdb.btrace/gcore.exp for remote host using
host_standard_output.

Tested on x86_64-linux.

[gdb/testsuite] Fix gdb.btrace/reconnect.exp for remote target

Fix test-case gdb.btrace/reconnect.exp for target board
remote-gdbserver-on-localhost using gdb_remote_download.

Tested on x86_64-linux.

Put pretty-printers to_string output in varobj result

PR mi/11335 points out that an MI varobj will not display the result
of a pretty-printer's "to_string" method.  Instead, it always shows
"{...}".

This does not seem very useful, and there have been multiple
complaints about it over the years.  This patch changes varobj to emit
this string when possible, and updates the test suite.

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

gdb/testsuite: allow "require" callbacks to provide a reason

When an allow_* proc returns false, it can be a bit difficult what check
failed exactly, if the procedure does multiple checks.  To make
investigation easier, I propose to allow the "require" callbacks to be
able to return a list of two elements: the zero/non-zero value, and a
reason string.

Use the new feature in allow_hipcc_tests to demonstrate it (it's also
where I hit actually hit this inconvenience).  On my computer (where GDB
is built with amd-dbgapi support but where I don't have a suitable GPU
target), I get:

    UNSUPPORTED: gdb.rocm/simple.exp: require failed: allow_hipcc_tests (no suitable amdgpu targets found)

vs before:

    UNSUPPORTED: gdb.rocm/simple.exp: require failed: allow_hipcc_tests

Change-Id: Id1966535b87acfcbe9eac99f49dc1196398c6578
Approved-By: Tom de Vries <tdevries@suse.de>

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

Fix test-case gdb.server/server-kill-python.exp for remote host using
gdb_remote_download.

Tested on x86_64-linux.

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

Fix test-case gdb.server/sysroot.exp for remote host, by:
- using gdb_remote_download, and
- disabling the "local" scenario for remote host/target, unless
  remote host == remote target.

Tested on x86_64-linux.

[gdb/testsuite] Require non-remote host for gdb.server/multi-ui-errors.exp

Require non-remote host for test-case gdb.server/multi-ui-errors.exp, because
it uses "spawn -pty", which creates a pty on build, which gdb cannot use on
remote host.

Tested on x86_64-linux.

[gdb/testsuite] Fix gdb.server/solib-list.exp for remote host

Fix test-case gdb.server/solib-list.exp for remote host using
gdb_remote_download.

Likewise in another test-case.

Tested on x86_64-linux.

[gdb/testsuite] Fix gdb.server/file-transfer.exp for remote host

Fix test-case gdb.server/file-transfer.exp for remote host using
gdb_remote_download and host_standard_output_file.

Tested on x86_64-linux.

[gdb/testsuite] Fix local-remote-host-native.exp for gdb.server tests

When running test-case gdb.server/stop-reply-no-thread-multi.exp with
host+target board local-remote-host-native, I run into a time-out:
...
(gdb) PASS: gdb.server/stop-reply-no-thread-multi.exp: target-non-stop=off: \
  to_disable=: disconnect
builtin_spawn /usr/bin/ssh -t -l vries 127.0.0.1 gdbserver --once \
  localhost:2346 stop-reply-no-thread-multi^M
Process stop-reply-no-thread-multi created; pid = 32600^M
Listening on port 2346^M
set remote threads-packet off^M
FAIL: gdb.server/stop-reply-no-thread-multi.exp: target-non-stop=off: \
  to_disable=: set remote threads-packet off (timeout)
...

This is due to this line in ${board}_spawn:
...
    set board_info($board,fileid) $spawn_id
...

We have the following series of events:
- gdb is spawned, setting fileid
- a few gdb commands (set height etc) are send using fileid, arrive at gdb and
  are successful
- gdbserver is spawned, overwriting fileid
- the next gdb command is sent using fileid, so it's send
  to gdbserver instead of gdb, and we run into the timeout.

There is some notion of current gdb, tracked in both gdb_spawn_id and fileid
of the host board (see switch_gdb_spawn_id).  And because the host and target
board are the same, spawning something on the target overwrites the fileid on
host, and consequently the current gdb.

Fix this by only setting fileid when spawning gdb.

Tested on x86_64-linux.

Now gdb.server/*.exp passes for host+target board local-remote-host-native,
except for file-transfer.exp.

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

gdb: use dynamic year in update-freebsd.sh

When running update-freebsd.sh on FreeBSD, I see the following
modification in freebsd.xml,

-<!-- Copyright (C) 2009-2023 Free Software Foundation, Inc.
+<!-- Copyright (C) 2009-2020 Free Software Foundation, Inc.

It means that each time, when we running the update-freebsd.sh on
FreeBSD, we have to correct the year of copyright manually. So fix this
issue by using dynamic year.

Tested by regenerating freebsd.xml on FreeBSD/amd64.

Reviewed-By: John Baldwin <jhb@FreeBSD.org>
Approved-By: Simon Marchi <simon.marchi@efficios.com>

[gdb/testsuite] Fix gdb.server/non-existing-program.exp with remote-gdbserver-on-localhost

With test-case gdb.server/non-existing-program.exp and native, I have reliably:
...
(gdb) builtin_spawn gdbserver stdio non-existing-program^M
stdin/stdout redirected^M
/bin/bash: line 0: exec: non-existing-program: not found^M
During startup program exited with code 127.^M
Exiting^M
PASS: gdb.server/non-existing-program.exp: gdbserver exits cleanly
...

But with target board remote-gdbserver-on-localhost I sometimes have:
...
(gdb) builtin_spawn /usr/bin/ssh -t -l remote-target localhost gdbserver \
  stdio non-existing-program^M
stdin/stdout redirected^M
/bin/bash: line 0: exec: non-existing-program: not found^M
During startup program exited with code 127.^M
Exiting^M
Connection to localhost closed.^M^M
PASS: gdb.server/non-existing-program.exp: gdbserver exits cleanly
...
and sometimes the exact same output, but a FAIL instead.

Fix this by replacing "Exiting\r\n$" with "Exiting\r\n" in the regexps.

Tested on x86_64-linux.

Avoid undefined behaviour in m68hc11 md_begin

Given p = A where p is a pointer to some type and A is an array of
that type, then the expression p - 1 + 1 evokes undefined behaviour
according to the C standard.

gcc-13 -fsanitize=address,undefined complains about this, but not
where the undefined behaviour actually occurs at tc-m68hc11.c:646.
Instead you get an error: "tc-m68hc11.c:708:20: runtime error: store
to address 0x62600000016c with insufficient space for an object of
type 'int'".  Which is a lie.  There most definitely is space there.
Oh well, diagnostics are sometimes hard to get right.  The UB is easy
to avoid.

PR 30279
* config/tc-m68hc11.c (md_begin): Avoid undefined pointer
decrement.  Remove unnecessary cast.

[gdb/testsuite] Allow gdb.rust/expr.exp without rust compiler

Proc allow_rust_tests returns 0 when there's no rust compiler, but that gives
the wrong answer for gdb.rust/expr.exp, which doesn't require it.

Fix this by using can_compile rust in the test-cases that need it, and just
returning 1 in allow_rust_tests.

Tested on x86_64-linux.

[gdb/testsuite] Add can_compile rust

If I deinstall the rust compiler, I get:
...
gdb compile failed, default_target_compile: Can't find rustc --color never.
UNTESTED: gdb.rust/watch.exp: failed to prepare
...

Fix this by adding can_compile rust, and using it in allow_rust_tests, such
that we have instead:
...
UNSUPPORTED: gdb.rust/watch.exp: require failed: allow_rust_tests
...

Since the rest of the code in allow_rust_tests is also about availability of
the rust compiler, move it to can_compile.

Tested on x86_64-linux.

[gdb/testsuite] Unsupport gdb.rust for remote host

With test-case gdb.rust/watch.exp and remote host I run into:
...
Executing on host: gcc   watch.rs  -g  -lm   -o watch    (timeout = 300)
  ...
ld:watch.rs: file format not recognized; treating as linker script
ld:watch.rs:1: syntax error
  ...
UNTESTED: gdb.rust/watch.exp: failed to prepare
...

The problem is that find_rustc returns "" for remote host, so we fall back to gcc, which fails.

Fix this by returning 0 in allow_rust_tests for remote host.

Tested on x86_64-linux.

ubsan: elfnn-aarch64.c:4595:19: runtime error: load of value 190

which is not a valid value for type '_Bool'

* elfnn-aarch64.c (stub_hash_newfunc): Clear all fields past root.

Automatic date update in version.in

[gdb/testsuite] Fix gnat_runtime_has_debug_info for remote host

Fix gnat_runtime_has_debug_info for remote host by checking for
allow_ada_tests.

This fixes an error for test-case gdb.testsuite/gdb-caching-proc.exp and
remote host.

Tested on x86_64-linux.

fbsd-nat: Use correct constant for target_waitstatus::sig.

Use GDB_SIGNAL_TRAP instead of SIGTRAP.  This is a no-op since the
value of SIGTRAP on FreeBSD matches the value of GDB_SIGNAL_TRAP, but
it is more correct.

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

fbsd-nat: Avoid a direct write to target_waitstatus::kind.

This is in #ifdef'd code for a workaround for FreeBSD versions older
than 11.1 which is why it wasn't caught earlier.

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

fbsd-nat: Add missing spaces.

No functional change, just style fixes.

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

gprofng: 30089 [display text] Invalid number of threads

The real problem is that libcollector doesn't interpose thread_create@GLIBC_2.34
We interpose a lot of libC functions (dlopen, fork, pthread_create, etc.).
Some of these functions have versions. For example, dlopen@GLIBC_2.34,
dlopen@GLIBC_2.17, dlopen@GLIBC_2.2.5, etc.
We have to interpose each of the functions because we don't know
which version of libC will be used during profiling.
Historically, we have used three versions of scripts (mapfile.aarch64-Linux,
mapfile.amd64-Linux, mapfile.intel-Linux).
Three are not needed. One is enough

The fixes below include:
 - merged all version symbols into one version script.
 - added new version symbols which are defined in latest versions of libC.
 - removed unused defines and duplicated code.
 - added the DCL_FUNC_VER macro to define the version symbols.

Tested on x86_64 and aarch64 (OL8/OL9). No regression.

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

PR gprofng/30089
* libcollector/Makefile.am: Use libgprofng.ver instead of mapfile.*
* libcollector/configure.ac: Delete GPROFNG_VARIANT.
* src/collector_module.h: Move the SYMVER_ATTRIBUTE macro to collector.h
* libcollector/collector.h: Add macros (SYMVER_ATTRIBUTE, DCL_FUNC_VER).
Remove unused defines.
* libcollector/dispatcher.c: Interpose functions from libC.
Clean up the old code.
* libcollector/iotrace.c: Likewise.
* libcollector/libcol_util.c: Likewise.
* libcollector/linetrace.c: Likewise.
* libcollector/mmaptrace.c: Likewise.
* libcollector/synctrace.c: Likewise.
* libcollector/libgprofng.ver: New file.
* libcollector/Makefile.in: Rebuild.
* libcollector/configure: Rebuild.
* libcollector/mapfile.aarch64-Linux: Removed.
* libcollector/mapfile.amd64-Linux: Removed.
* libcollector/mapfile.intel-Linux: Removed.
* libcollector/mapfile.sparc-Linux: Removed.
* libcollector/mapfile.sparcv9-Linux: Removed.

linux-nat: introduce pending_status_str

I noticed that some debug log output printing an lwp's pending status
wasn't considering lp->waitstatus.  This fixes it, by introducing a
new pending_status_str function.

Also fix the comment in gdb/linux-nat.h describing
lwp_info::waitstatus and details the description of lwp_info::status
while at it.

Change-Id: I66e5c7a363d30a925b093b195d72925ce5b6b980
Approved-By: Andrew Burgess <aburgess@redhat.com>

displaced step: pass down target_waitstatus instead of gdb_signal

This commit tweaks displaced_step_finish & friends to pass down a
target_waitstatus instead of a gdb_signal.  This is needed because a
patch later in the step-over-{thread-exit,clone] series will want to
make displaced_step_buffers::finish handle
TARGET_WAITKIND_THREAD_EXITED.  It also helps with the
TARGET_WAITKIND_THREAD_CLONED patch later in that same series.

It's also a bit more logical this way, as we don't have to pass down
signals when the thread didn't actually stop for a signal.  So we can
also think of it as a clean up.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27338
Change-Id: I4c5d338647b028071bc498c4e47063795a2db4c0
Approved-By: Andrew Burgess <aburgess@redhat.com>

[gdb/testsuite] Fix gdb.stabs/exclfwd.exp for remote host

Fix test-case gdb.stabs/exclfwd.exp for remote host using include_file.

Tested on x86_64-linux.

[gdb/testsuite] Fix gdb.stabs/weird.exp for remote host

Fix test-case gdb.stabs/weird.exp for remote host by not using an absolute
destfile argument to gdb_remote_download, which doesn't work well with remotedir.

[gdb/testsuite] Fix gdb.gdb/unittest.exp for remote host

Fix test-case gdb.gdb/unittest.exp for remote host, by:
- disabling the completion tests if readline is not used, and
- not using with_gdb_cwd $dir for remote host (because it does
  not support changing to ".").

Tested on x86_64-linux.

[gdb/testsuite] Skip do_self_tests on remote host

In do_self_tests we try to find out the location of the gdb to debug, which
will then be copied and renamed to xgdb.

In principle, the host board specifies the location of GDB, on host.

With remote host, we could upload that gdb from host to build/target, but we
would miss the data directory (which is listed as the reason to skip
do_self_tests for remote target).

We could fix that by instead taking the gdb from build instead, but that
wouldn't work with installed testing.

It seems easier to just skip this on remote host.

It could be made to work for the "[is_remote host] && [is_remote target]
&& host == target" scenario (see board local-remote-host-native.exp), but
that doesn't seem worth the effort.

Tested on x86_64-linux.

Change symbol::line to unsigned int

A user here at AdaCore noticed that, when debugging a certain program,
a stack frame reported line 34358, where it should have been line
99894.

After debugging a bit, I discovered:

(top) p (99894 & ~65536)
$60 = 34358

That line, symbol::line is too narrow.

This patch widens the member and changes all the uses that currently
use the narrower type.

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

Fix 128-bit integer bug in Ada

While working on 128-bit integer support, I found one spot in Ada that
needed a fix as well.

Use gdb_gmp for scalar arithmetic

This changes gdb to use scalar arithmetic for expression evaluation.

I suspect this patch is not truly complete, as there may be code paths
that still don't correctly handle 128-bit integers.  However, many
things do work now.

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

Use value_true in value_equal and value_less

Both value_equal and value_less use value_as_long to check a
presumably boolean result of calling value_binop.  However,
value_binop in this case actually returns an int as wide as its
arguments, and this approach can then fail for integers wider than
LONGEST.  Instead, rewrite this in a form that works for any size
integer.

Simplify binop_promote

binop_promote currently only handles integer sizes up to
builtin_long_long.  However, this may not handle 128-bit types.
Simplify this code, unify the C and non-C (but not OpenCL, as I don't
know how to test this) cases, and handle 128-bit integers as well.

This still doesn't exactly follow C or C++ rules.  This could be
implemented, but if so, I think it makes more sense as a C-specific
expression node.

Add value_as_mpz and value_from_mpz

This adds the two new functions, value_as_mpz and value_from_mpz,
useful for manipulation values via gdb_mpz.

Add truncation mode to gdb_mpz

This renames gdb_mpz::safe_export to export_bits, and adds a new flag
to export a truncated value.  This is needed by value arithmetic.

Avoid a copy in gdb_mpz::safe_export

Currently, gdb_mpz::safe_export will always make a copy of *this.
However, this copy isn't always needed.  This patch makes this code
slightly more efficient, by avoiding the copy when possible.

Add many operators to gdb_mpz

This adds many operator overloads and other useful methods to gdb_mpz.
This is preparation for using this class for scalar arithmetic in gdb
expression evaluation.

Populate seen_names hash in cooked_index_shard::do_finalize

Hannes pointed out that cooked_index_shard::do_finalize never
populates the seen_names hash table.  This patch adds the necessary
store.  This reduces memory use a little for "gdb gdb":

(before) Space used: 28909568 (+0 for this command)
(after)  Space used: 28884992 (+0 for this command)

What this means, btw, is that in gdb there are not many symbols that
are both mentioned in many CUs and that also require name
canonicalization.  It's possible this would differ in other programs.

[gdb/testsuite] Fix gdb.asm/asm-source.exp for remote host

Fix test-case gdb.asm/asm-source.exp for remote host using
host_standard_output_file and gdb_remote_download.

Tested on x86_64-linux.

[gdb/testsuite] Fix gdb.dwarf2/imported-unit-bp-c.exp for remote host

Fix test-case gdb.dwarf2/imported-unit-bp-c.exp on remote by removing a
downloaded source file.

Tested on x86_64-linux.

[gdb/testsuite] Unsupport gdb.dwarf2/gdb-add-index-symlink.exp for remote host

Declare test-case gdb.dwarf2/gdb-add-index-symlink.exp unsupported for remote
host, because the current implementation of gdb_ensure_index doesn't support it.

Tested on x86_64-linux.

[gdb/testsuite] Fix gdb.dwarf2/gdb-index-cxx.exp for remote host

Fix test-case gdb.dwarf2/gdb-index-cxx.exp for remote host using
host_standard_output_file.

Tested on x86_64-linux.

[gdb/testsuite] Fix gdb.dwarf2/enqueued-cu-base-addr.exp for remote host

Fix test-case gdb.dwarf2/enqueued-cu-base-addr.exp for remote host by using
$testfile instead $binfile.

Tested on x86_64-linux.

[gdb/testsuite] Fix gdb.dwarf2/gdb-index.exp on remote host

Fix test-case gdb.dwarf2/gdb-index.exp on remote host using
gdb_remote_download and host_standard_output_file.

Also declare the test-case unsupported with readnow.

Tested on x86_64-linux.

[gdb/testsuite] Fix gdb.dwarf2/per-bfd-sharing.exp for remote host

Fix test-case gdb.dwarf2/per-bfd-sharing.exp for remote host using
gdb_remote_download.

Likewise in a few other test-cases.

Tested on x86_64-linux.

[gdb/testsuite] Fix quoting issue in gdb.base/index-cache.exp

For test-case gdb.base/index-cache.exp and remote host, this:
...
lassign [remote_exec host sh "-c \"rm $cache_dir/*.gdb-index\""] ret
...
gives us:
...
Executing on host: sh -c rm /tmp/tmp.m3L7m2AVkL/*.gdb-index    (timeout = 300)
builtin_spawn -ignore SIGHUP sh -c rm /tmp/tmp.m3L7m2AVkL/*.gdb-index^M
rm: missing operand^M
Try 'rm --help' for more information.^M
FAIL: gdb.dwarf2/per-bfd-sharing.exp: couldn't remove files in temporary cache dir
...

Fix this using quote_for_host.  Likewise in gdb.dwarf2/per-bfd-sharing.exp.

Tested on x86_64-linux.