PR22263 ld test

A number of targets that I test regularly fail the "Build pr22263-1"
test for various reasons.

arm-linux-gnueabi: "undefined reference to `__aeabi_read_tp'"
ia64-linux-gnu: "Explicit stops are ignored in auto mode"
m68k-linux-gnu: "undefined reference to `__m68k_read_tp'"
microblaze-linux-gnu: "undefined reference to `__tls_get_addr'"
nios2-linux-gnu, s390-linux-gnu and sh4-linux-gnu have a tprel reloc in .got
riscv64-linux-gnu has a dynamic relocation in text

So only riscv really fails the pr.  The rest fail due to test issues
or lack of a linker optimisation.  Lack of an optimisation isn't
really a fail, but it's worth keeping the test to ensure those
optimisations don't regress.  The xfail targets may not be an
exhaustive list.  This just tidies test results for those for which I
have cross compilers installed.

PR 22263
* testsuite/ld-elf/tls.exp: Split pr22263 test into two parts,
one to check for -z text errors, the other to check tprel
linker optimisation.  Supply needed symbols and assembler flags.
xfail the linker optimisation on targets known to fail.

Make MI commands const-correct

I've had this patch for a while now and figured I'd update it and send
it.  It changes MI commands to use a "const char * const" for their
argv parameter.

Regression tested on x86-64 Fedora 36.

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

Automatic date update in version.in

Fix scoped_value_mark not working with empty value chain

The scoped_value_mark helper class was setting its internal
mark value to NULL to indicate that the value chain had already
been freed to mark.

However, value_mark() also returns NULL if the value chain is
empty at the time of call.

This lead to the situation that if the value chain was empty
at the time the scoped_value_mark was created, the class
would not correctly clean up the state when it was destroyed,
because it believed it had already been freed.

I noticed this because I was setting a watchpoint very early
in my debug session, and it was becoming a software watchpoint
rather than hardware. Running any command that called evaluate()
beforehand (such as 'x 0') would mean that a hardware watchpoint
was correctly used. After some careful examination of the
differences in execution, I noticed that values were being freed
later in the 'bad case', which lead me to notice the issue with
scoped_value_mark.

gdb: remove breakpoint_pointer_iterator

Remove the breakpoint_pointer_iterator layer.  Adjust all users of
all_breakpoints and all_tracepoints to use references instead of
pointers.

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

gdbsupport: make filtered_iterator::operator* return the same thing as underlying iterator

This is the same idea as the previous patch, but for filtered_iterator.
Without this patch, I would see this when applying the patch that
removes reference_to_pointer_iterator from breakpoint_range:

      CXX    breakpoint.o
    /home/smarchi/src/binutils-gdb/gdb/breakpoint.c: In function ‘void download_tracepoint_locations()’:
    /home/smarchi/src/binutils-gdb/gdb/breakpoint.c:11007:41: error: cannot allocate an object of abstract type ‘breakpoint’
    11007 |   for (breakpoint &b : all_tracepoints ())
          |                                         ^
    In file included from /home/smarchi/src/binutils-gdb/gdb/gdbthread.h:26,
                     from /home/smarchi/src/binutils-gdb/gdb/infrun.h:21,
                     from /home/smarchi/src/binutils-gdb/gdb/gdbarch.h:28,
                     from /home/smarchi/src/binutils-gdb/gdb/arch-utils.h:23,
                     from /home/smarchi/src/binutils-gdb/gdb/breakpoint.c:21:
    /home/smarchi/src/binutils-gdb/gdb/breakpoint.h:619:8: note:   because the following virtual functions are pure within ‘breakpoint’:
      619 | struct breakpoint : public intrusive_list_node<breakpoint>
          |        ^~~~~~~~~~
    /home/smarchi/src/binutils-gdb/gdb/breakpoint.c:250:1: note:     ‘virtual breakpoint::~breakpoint()’
      250 | breakpoint::~breakpoint ()
          | ^~~~~~~~~~

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

gdbsupport: make basic_safe_iterator::operator* return the same thing as underlying iterator

Using the following patch that removes the reference_to_pointer_iterator
from breakpoint_range, I would get:

      CXX    breakpoint.o
    /home/smarchi/src/binutils-gdb/gdb/breakpoint.c: In function ‘void breakpoint_program_space_exit(program_space*)’:
    /home/smarchi/src/binutils-gdb/gdb/breakpoint.c:3030:46: error: cannot allocate an object of abstract type ‘breakpoint’
     3030 |   for (breakpoint &b : all_breakpoints_safe ())
          |                                              ^
    In file included from /home/smarchi/src/binutils-gdb/gdb/gdbthread.h:26,
                     from /home/smarchi/src/binutils-gdb/gdb/infrun.h:21,
                     from /home/smarchi/src/binutils-gdb/gdb/gdbarch.h:28,
                     from /home/smarchi/src/binutils-gdb/gdb/arch-utils.h:23,
                     from /home/smarchi/src/binutils-gdb/gdb/breakpoint.c:21:
    /home/smarchi/src/binutils-gdb/gdb/breakpoint.h:619:8: note:   because the following virtual functions are pure within ‘breakpoint’:
      619 | struct breakpoint : public intrusive_list_node<breakpoint>
          |        ^~~~~~~~~~
    /home/smarchi/src/binutils-gdb/gdb/breakpoint.c:250:1: note:     ‘virtual breakpoint::~breakpoint()’
      250 | breakpoint::~breakpoint ()
          | ^~~~~~~~~~

This is because the operator* method of the basic_safe_iterator iterator
wrapper returns a value_type.  So, even if the method of the underlying
iterator (breakpoint_iterator, an intrusive_list iterator) returns a
`breakpoint &`, the method of the wrapper returns a `breakpoint`.

I think it would make sense for iterator wrappers such as
basic_safe_iterator to return the exact same thing as the iterator they
wrap.  At least, it fixes my problem.

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

gdb: link breakpoints with intrusive_list

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

gdb: remove bp_location_pointer_iterator

Remove the bp_location_pointer_iterator layer.  Adjust all users of
breakpoint::locations to use references instead of pointers.

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

gdb: use intrusive_list for breakpoint locations

Replace the hand-maintained linked lists of breakpoint locations with
and intrusive list.

 - Remove breakpoint::loc, add breakpoint::m_locations.

 - Add methods for the various manipulations that need to be done on the
   location list, while maintaining reasonably good encapsulation.

 - bp_location currently has a default constructor because of one use
   in hoist_existing_locations.  hoist_existing_locations now returns a
   bp_location_list, and doesn't need the default-constructor
   bp_location anymore, so remove the bp_location default constructor.

 - I needed to add a call to clear_locations in delete_breakpoint to
   avoid a use-after-free.

 - Add a breakpoint::last_loc method, for use in
   set_breakpoint_condition.

bp_location_range uses reference_to_pointer_iterator, so that all
existing callers of breakpoint::locations don't need to change right
now.  It will be removed in the next patch.

The rest of the changes are to adapt the call sites to use the new
methods, of breakpoint::locations, rather than breakpoint::loc directly.

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

gdbsupport: add missing increment/decrement operators to reference_to_pointer_iterator

Using the following patch, I would get this build failure:

      CXX    breakpoint.o
    In file included from /usr/include/c++/13.1.1/bits/stl_algobase.h:66,
                     from /usr/include/c++/13.1.1/bits/hashtable_policy.h:36,
                     from /usr/include/c++/13.1.1/bits/hashtable.h:35,
                     from /usr/include/c++/13.1.1/bits/unordered_map.h:33,
                     from /usr/include/c++/13.1.1/unordered_map:41,
                     from /usr/include/c++/13.1.1/functional:63,
                     from /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/ptid.h:35,
                     from /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/common-defs.h:206,
                     from /home/smarchi/src/binutils-gdb/gdb/defs.h:26,
                     from /home/smarchi/src/binutils-gdb/gdb/breakpoint.c:20:
    /usr/include/c++/13.1.1/bits/stl_iterator_base_funcs.h: In instantiation of ‘constexpr void std::__advance(_BidirectionalIterator&, _Distance, bidirectional_iterator_tag) [with _BidirectionalIterator = reference_to_pointer_iterator<intrusive_list_iterator<bp_location, intrusive_base_node<bp_location> > >; _Distance = long int]’:
    /usr/include/c++/13.1.1/bits/stl_iterator_base_funcs.h:224:21:   required from ‘constexpr void std::advance(_InputIterator&, _Distance) [with _InputIterator = reference_to_pointer_iterator<intrusive_list_iterator<bp_location, intrusive_base_node<bp_location> > >; _Distance = long int]’
    /usr/include/c++/13.1.1/bits/stl_iterator_base_funcs.h:237:19:   required from ‘constexpr _InputIterator std::next(_InputIterator, typename iterator_traits<_Iter>::difference_type) [with _InputIterator = reference_to_pointer_iterator<intrusive_list_iterator<bp_location, intrusive_base_node<bp_location> > >; typename iterator_traits<_Iter>::difference_type = long int]’
    /home/smarchi/src/binutils-gdb/gdb/breakpoint.c:1073:19:   required from here
    /usr/include/c++/13.1.1/bits/stl_iterator_base_funcs.h:179:11: error: no match for ‘operator--’ (operand type is ‘reference_to_pointer_iterator<intrusive_list_iterator<bp_location, intrusive_base_node<bp_location> > >’)
      179 |           --__i;
          |           ^~~~~

This points out that while intrusive_list_iterator has an operator--,
the reference_to_pointer_iterator wrapper does not.  I'm not to sure why
the compiler chooses the overload of __advance that accepts a
_BidirectionalIterator, given that reference_to_pointer_iterator can't
be decremented, but adding those operators seems like the right thing to
do in any case, for completeness.

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

gdb: add breakpoint::first_loc methods

Add convenience first_loc methods to struct breakpoint (const and
non-const overloads).  A subsequent patch changes the list of locations
to be an intrusive_list and makes the actual list private, so these
spots would need to change from:

    b->loc

to something ugly like:

    *b->locations ().begin ()

That would make the code much heavier and not readable.  There is a
surprisingly big number of places that access the first location of
breakpoints.  Whether this is correct, or these spots fail to consider
the possibility of multi-location breakpoints, I don't know.  But
anyhow, I think that using this instead:

 b->first_loc ()

conveys the intention better than the other two forms.

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

gdb: add breakpoint "has locations" methods

Add three convenience methods to struct breakpoint:

 - has_locations: returns true if the breakpoint has at least one
   location
 - has_single_location: returns true if the breakpoint has exactly one
   location
 - has_multiple_locations: returns true if the breakpoint has more than
   one location

A subsequent patch changes the list of breakpoints to be an
intrusive_list, so all these spots would need to change.  But in any
case, I think that this:

  if (b->has_multiple_locations ())

conveys the intention better than:

  if (b->loc != nullptr && b->loc->next != nullptr)

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

gdb: constify breakpoint::print_it parameter

The print_it method itself is const.  In a subsequent patch, the
locations that come out of a const breakpoint will be const as well.  It
will therefore be needed to make the last_loc output parameter const as
well.  Make that change now to reduce the size of the following patches.

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

gdb: make some breakpoint methods use `this`

Some implementations of breakpoint::check_status and
breakpoint::print_it do this:

    struct breakpoint *b = bs->breakpoint_at;

bs->breakpoint_at is always the same as `this` (we can get convinced by
looking at the call sites of check_status and print_it), so it would
just be clearer to access fields through `this` instead.

Change-Id: Ic542a64fcd88e31ae2aad6feff1da278c7086891
Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
Reviewed-By: Andrew Burgess <aburgess@redhat.com>

gdb: get gdbarch from syscall_catchpoint instead of location

I noticed some methods of syscall_catchpoint doing this:

  struct gdbarch *gdbarch = loc->owner->gdbarch;

`loc` is the list of locations of this catchpoint.  Logically, the owner
the locations are this catchpoint.  So this just ends up getting
this->gdbarch.  Remove the unnecessary indirection through the loc.

syscall_catchpoint::print_recreate does something slightly different,
getting its arch from the loc:

  struct gdbarch *gdbarch = loc->gdbarch;

I suppose it's always going to be the same arch, so get it from the
catchpoint there too.

Change-Id: I6f6a6f8e0cd7cfb754cecfb6249e71ec12ba4855
Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
Reviewed-By: Andrew Burgess <aburgess@redhat.com>

PR29189, dlltool delaylibs corrupt float/double arguments

PR 29189
* dlltool.c (i386_x64_trampoline): Save and restore xmm0-5.  Make
use of parameter save area for integer arg regs.  Comment.

Automatic date update in version.in

gdbsupport: add support for references to checked_static_cast

Add a checked_static_cast overload that works with references.  A bad
dynamic cast with references throws std::bad_cast, it would be possible
to implement the new overload based on that, but it seemed simpler to
just piggy back off the existing function.

I found some potential uses of this new overload in amd-dbgapi-target.c,
update them to illustrate the use of the new overload.  To build
amd-dbgapi-target.c, on needs the amd-dbgapi library, which I don't
expect many people to have.  But I have it, and it builds fine here.  I
did test the new overload by making a purposely bad cast and it did
catch it.

Change-Id: Id6b6a7db09fe3b4aa43cddb60575ff5f46761e96
Reviewed-By: Lancelot SIX <lsix@lancelotsix.com>
Reviewed-By: Andrew Burgess <aburgess@redhat.com>

gdb/testsuite: fix race in gdb.server/multi-ui-errors.exp

After this commit:

  commit ed32754a8c7919feffc6ddb66ff1c532e4a4d1cd
  Date:   Thu Mar 9 10:45:03 2023 +0100

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

I noticed the occasional failure in gdb.server/multi-ui-errors.exp,
which looked like this:

  (gdb) PASS: gdb.server/multi-ui-errors.exp: interact with GDB's main UI
  interrupt
  (gdb)
  Program received signal SIGINT, Interrupt.
  0x00007ffff7d501e7 in nanosleep () from /lib64/libc.so.6
  FAIL: gdb.server/multi-ui-errors.exp: interrupt (timeout)
  PASS: gdb.server/multi-ui-errors.exp: interrupt arrived
  p server_pid
  $1 = 718174
  (gdb) PASS: gdb.server/multi-ui-errors.exp: p server_pid

This is triggered by this code in gdb.server/multi-ui-errors.exp:

    gdb_test "interrupt"

    gdb_test_multiple "" "interrupt arrived" {
-re "Program received signal SIGINT, Interrupt\\.\r\n" {
    pass $gdb_test_name
}
    }

The problem here is that the first interrupt will trigger the prompt
to be printed, and then, after some time the inferior will be
interrupted.

However the default pattern for gdb_test includes a '$' end anchor.
If expect sees the prompt with nothing following it then everything is
fine, and the test passes.

However, if the interrupt is quick and so what expect sees is this:

  (gdb)
  Program received signal SIGINT, Interrupt.
  0x00007ffff7d501e7 in nanosleep () from /lib64/libc.so.6

In this case the end anchor means that the gdb_test fails to match,
and eventually times out.

Fix this by passing -no-prompt-anchor to gdb_test.

Reviewed-By: Tom de Vries <tdevries@suse.de>

gdb, infcmd: Support jump command with same line in multiple symtabs

If a header file defining a static function is included in multiple source
files, each calling the function, and GDB is asked to jump to a line inside
that function, there would be multiple locations matching the target.  The
solution in this commit is to select the location in the current symtab.

Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Andrew Burgess <aburgess@redhat.com>

Add "args" and "env" parameters to DAP launch request

This patch augments the DAP launch request with some optional new
parameters that let the client control the command-line arguments and
the environment of the inferior.

Reviewed-By: Andrew Burgess <aburgess@redhat.com>
Reviewed-By: Eli Zaretskii <eliz@gnu.org>

Add attributes and methods to gdb.Inferior

This adds two new attributes and three new methods to gdb.Inferior.

The attributes let Python code see the command-line arguments and the
name of "main".  Argument setting is also supported.

The methods let Python code manipulate the inferior's environment
variables.

Reviewed-By: Eli Zaretskii <eliz@gnu.org>

Remove accidentally added file

Don't optimise bfd_seek to same position

It's not worth avoiding an fseek to the same position, and can cause
problems if the linker's output file (which is opened "w+") is read,
because that can result in writing, reading, then writing again.

POSIX.1-2017 (IEEE Std 1003.1) says of fopen:
"When a file is opened with update mode ('+' as the second or third
character in the mode argument), both input and output may be
performed on the associated stream. However, the application shall
ensure that output is not directly followed by input without an
intervening call to fflush() or to a file positioning function
(fseek(), fsetpos(), or rewind()), and input is not directly followed
by output without an intervening call to a file positioning function,
unless the input operation encounters end-of-file."

* bfdio.c (bfd_seek): Always call iovec->bseek.

Automatic date update in version.in

Handle DAP evaluate request without a frame ID

DAP specifies that if an evaluate request does not have a frameID
parameter, then the expression is evaluated in the global scope.

Add global_context parameter to gdb.parse_and_eval

This adds a 'global_context' parse_and_eval to gdb.parse_and_eval.
This lets users request a parse that is done at "global scope".

I considered letting callers pass in a block instead, with None
meaning "global" -- but then there didn't seem to be a clean way to
express the default for this parameter.

Reviewed-By: Eli Zaretskii <eliz@gnu.org>

Add flags to parse_and_eval

This adds a flags parameter to parse_and_eval.

Add PARSER_LEAVE_BLOCK_ALONE flag

This adds a PARSER_LEAVE_BLOCK_ALONE flag, and changes the parse API
to respect it.  This flag lets callers avoid any change to the
passed-in block and expression PC, letting them specify the context
exactly.  In particular, now nullptr can be used to indicate that the
parse should not examine any local variables.

Add PARSER_DEBUG flag

This adds a new PARSER_DEBUG constant and changes the parser code to
use it.  This lets us make the 'parser_debug' global 'static'.

Rearrange parser_state

This patch mildly rearranges parser_state, moving all the bool fields
together.

Boolify parser_state::comma_terminates

parser_state::comma_terminates ought to be boolean, and changing it
does not require any other changes.

Simplify parser_state constructor

This simplifies the parser_state constructor by having it accept a
parser_flags parameter.

Introduce and use parser flags

This patch adds a new parser_flags type and changes the parser APIs to
use it rather than a collection of 'int' and 'bool'.  More flags will
be added in subsquent patches.

Move innermost_block_tracker to expression.h

I think parser-defs.h should hold declarations that can be used by
parser implementations, whereas expression.h should hold declarations
that are used by code that wants to call a parser.  Following this
logic, this patch moves innermost_block_tracker to expression.h.

Avoid forward declaration in parse.c

This minorly rearranges parse.c to avoid the need for a forward
declaration.

Implement DAP loadedSources request

This implements the DAP loadedSources request, using gdb.execute_mi to
avoid having to write another custom Python API.

Implement gdb.execute_mi

This adds a new Python function, gdb.execute_mi, that can be used to
invoke an MI command but get the output as a Python object, rather
than a string.  This is done by implementing a new ui_out subclass
that builds a Python object.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=11688
Reviewed-By: Eli Zaretskii <eliz@gnu.org>

Add second mi_parse constructor

This adds a second mi_parse constructor.  This constructor takes a
command name and vector of arguments, and does not do any escape
processing.  This also changes mi_parse::args to handle parse objects
created this new way.

Introduce mi_parse helper methods

This introduces some helper methods for mi_parse that handle some of
the details of parsing.  This approach lets us reuse them later.

Introduce "static constructor" for mi_parse

Change the mi_parse function to be a static method of mi_parse.  This
lets us remove the 'set_args' setter function.

Change mi_parse_argv to a method

This changes mi_parse_argv to be a method of mi_parse.  This is just a
minor cleanup.

Use accessor for mi_parse::args

This changes mi_parse::args to be a private member, retrieved via
accessor.  It also changes this member to be a std::string.  This
makes it simpler for a subsequent patch to implement different
behavior for argument parsing.

Use member initializers in mi_parse

This changes mi_parse to use member initializers rather than a
constructor.  This is easier to follow.

Use field_signed from Python MI commands

If an MI command written in Python includes a number in its output,
currently that is simply emitted as a string.  However, it's
convenient for a later patch if these are emitted using field_signed.
This does not make a difference to ordinary MI clients.

gdb/cli-out.c: clear_current_line shouldn't trigger pagination prompt

clear_current_line overwrites the current line with chars_per_line
blank spaces.  Printing the final space triggers a condition in
pager_file::puts that causes lines_printed to be incremented.  If
lines_printed becomes greater than or equal to lines_allowed, the
pagination prompt will appear if enabled.

In this case the prompt is unnecessary since after printing the final
space clear_current_line immediately moves the cursor to the beginning
of the line with '\r'.  A new line isn't actually started, so the prompt
ends up being spurious.

Additionally it's possible for gdb to crash during this pagination prompt.
Answering the prompt with 'q' throws an exception intended to bring gdb
back to the main event loop.  But since commit 0fea10f32746,
clear_current_line may be called under the progress_update destructor.
The exception will try to propagate through the destructor, causing an abort.

To fix this, pagination is disabled for the duration for clear_current_line.
clear_current_line is also renamed to clear_progress_notify to help
indicate that it is a special purpose function intended for use with
do_progress_notify.

Acked-by: Eli Zaretskii <eliz@gnu.org>

PR30437 aarch64: make RELA relocs idempotent

normally RELA relocs in BFD should not consider the contents of the
relocated place.  The aarch64 psABI is even stricter, it specifies
(section 5.7.16) that all RELA relocs _must_ be idempotent.

Since the inception of the aarch64 BFD backend all the relocs have a
non-zero src_mask, and hence break this invariant.  It's normally not
a very visible problem as one can see it only when the relocated place
already contains a non-zero value, which usually only happens sometimes
when using 'ld -r' (or as in the testcase when jumping through hoops to
generate the relocations).  Or with alternative toolchains that do encode
stuff in the relocated places with the assumption that a relocation
to that place ignores whatever is there (as they can according to
the psABI).

Golang is such a toolchain and https://github.com/golang/go/issues/39927
is ultimately caused by this problem: the testcase testGCData failing
is caused by the garbage collection data-structure to describe a type
containing pointers to be wrong.  It's wrong because a field that's
supposed to contain a file-relative offset (to some gcbits) has a
relocation applied and that relocation has an addend which also is
already part of the go-produced object file (so the addend is
implicitely applied twice).

bfd/
PR ld/30437
* elfnn-aarch64.c (elfNN_aarch64_howto_table): Clear src_mask
if all relocation descriptors.

ld/
* testsuite/ld-aarch64/rela-idempotent.s: New testcase.
* testsuite/ld-aarch64/rela-idempotent.d: New.
* testsuite/ld-aarch64/aarch64-elf.exp: Run it.

Updated Swedish translation for the opcodes directory

gdb/testsuite: change hardcoded assembly in gdb.arch/disp-step-insn-reloc.exp

When testing gdb.arch/disp-step-insn-reloc.exp with clang in an x86_64
machine, the compiled test case would segfault when returning from
the function can_relocate_call, with a suggestion of a broken stack.
The example assembly in the commment was the following:

   f:
     MOV $1, %[ok]
     JMP end
   set_point0:
     CALL f ; tracepoint here.
   end:

And the segmentation fault happening at the final "ret" instruction of
can_relocate_call.  Looking at the disassembled version of the later
half of the important function, we see:

Clang version (f starting at 11a4):
  00000000000011ae <set_point0>:
      11ae:       e8 f1 ff ff ff          callq  11a4 <can_relocate_call+0x14>
      11b3:       89 45 fc                mov    %eax,-0x4(%rbp)
      11b6:       83 7d fc 01             cmpl   $0x1,-0x4(%rbp)
      11ba:       0f 85 0a 00 00 00       jne    11ca <set_point0+0x1c>
      11c0:       e8 5b 00 00 00          callq  1220 <pass>
      11c5:       e9 05 00 00 00          jmpq   11cf <set_point0+0x21>
      11ca:       e8 61 00 00 00          callq  1230 <fail>
      11cf:       48 83 c4 10             add    $0x10,%rsp
      11d3:       5d                      pop    %rbp
      11d4:       c3                      retq
      11d5:       66 66 2e 0f 1f 84 00    data16 nopw %cs:0x0(%rax,%rax,1)
      11dc:       00 00 00 00

gcc version (f starting at 401125):
  000000000040112c <set_point0>:
    40112c:       e8 f4 ff ff ff          callq  401125 <can_relocate_call+0x11>
    401131:       89 45 fc                mov    %eax,-0x4(%rbp)
    401134:       83 7d fc 01             cmpl   $0x1,-0x4(%rbp)
    401138:       75 07                   jne    401141 <set_point0+0x15>
    40113a:       e8 c7 ff ff ff          callq  401106 <pass>
    40113f:       eb 05                   jmp    401146 <set_point0+0x1a>
    401141:       e8 c7 ff ff ff          callq  40110d <fail>
    401146:       90                      nop
    401147:       c9                      leaveq
    401148:       c3                      retq

The epilogue of set_point0 (11cf for clang, 401146 for gcc) is the main
difference: GCC's version uses the leaveq instruction, which resets rsp
based on rbp, while clang adds the same constant to rsp that it
subtracted in the prologue.  Clang fails because the return address that
is added by the "call f" instruction isn't accounted for.

This commit fixes that by adding a return instruction to f, which leaves
the rsp as the compilers would expect.

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

x86/Intel: address quoted-symbol related FIXMEs

If in a "word ptr <address>" or alike construct the "ptr" part is
double-quoted, it shouldn't be recognized as the specific keyword we're
looking for (just like we don't recognize double-quoted operator or
register names anymore). Be careful though to tell closing from opening
double-quotes, as a quoted symbol may follow right afterwards.

x86: don't recognize quoted symbol names as registers or operators

The concept of quoted symbols names was introduced pretty late. Utilize
it to allow access to symbols with names matching that of a register (or,
in Intel syntax, also an identifier-like operator).

This is primarily to aid gcc when generating Intel syntax output; see
their bug target/53929.

Support Intel FRED LKGS

gas/ChangeLog:

* NEWS: Support Intel FRED LKGS.
* config/tc-i386.c: Add fred lkgs
* doc/c-i386.texi: Document .fred, .lkgs.
* testsuite/gas/i386/i386.exp: Add FRED LKGS tests
* testsuite/gas/i386/x86-64-fred-intel.d: Ditto.
* testsuite/gas/i386/x86-64-fred.d: Ditto.
* testsuite/gas/i386/x86-64-fred.s: Ditto.
* testsuite/gas/i386/x86-64-lkgs-intel.d: Ditto.
* testsuite/gas/i386/x86-64-lkgs-inval.l: Ditto.
* testsuite/gas/i386/x86-64-lkgs-inval.s: Ditto.
* testsuite/gas/i386/x86-64-lkgs.d: Ditto.
* testsuite/gas/i386/x86-64-lkgs.s: Ditto.

opcodes/ChangeLog:

* i386-dis.c: New entry for fred, lkgs.
* i386-gen.c: Add CPU_FRED CPU_LKGS.
* i386-init.h : Regenerated.
* i386-mnem.h : Regenerated.
* i386-opc.h: Add fred, lkgs.
* i386-opc.tbl: Add FRED, LKGS instructions.
* i386-tbl.h: Regenerated.

Revert "Support Intel FRED LKGS"

This reverts commit e5a497fe38e0ab19e16bdd9e4b4ed5e4d0056478.

Support Intel FRED LKGS

gas/ChangeLog:

        * NEWS: Support Intel FRED LKGS.
        * config/tc-i386.c: Add fred lkgs
        * doc/c-i386.texi: Document .fred, .lkgs.
        * testsuite/gas/i386/i386.exp: Add FRED LKGS tests
        * testsuite/gas/i386/x86-64-fred-intel.d: Ditto.
        * testsuite/gas/i386/x86-64-fred.d: Ditto.
        * testsuite/gas/i386/x86-64-fred.s: Ditto.
        * testsuite/gas/i386/x86-64-lkgs-intel.d: Ditto.
        * testsuite/gas/i386/x86-64-lkgs-inval.l: Ditto.
        * testsuite/gas/i386/x86-64-lkgs-inval.s: Ditto.
        * testsuite/gas/i386/x86-64-lkgs.d: Ditto.
        * testsuite/gas/i386/x86-64-lkgs.s: Ditto.

opcodes/ChangeLog:

        * i386-dis.c: New entry for fred, lkgs.
        * i386-gen.c: Add CPU_FRED CPU_LKGS.
        * i386-init.h : Regenerated.
        * i386-mnem.h : Regenerated.
        * i386-opc.h: Add fred, lkgs.
        * i386-opc.tbl: Add FRED, LKGS instructions.
        * i386-tbl.h: Regenerated.

Automatic date update in version.in

[gdb/tui] Fix buglet in tui_update_variables

I noticed a buglet in tui_update_variables:
...
   entry = translate (tui_border_kind, tui_border_kind_translate_lrcorner);
   if (tui_border_lrcorner != (chtype) entry->value)
    {
      tui_border_lrcorner = (entry->value < 0) ? ACS_LRCORNER : entry->value;
...

When assigning the new value to tui_border_lrcorner, an entry->value of -1 is
taken into account, but not when comparing to the current value of
tui_border_lrcorner.

Fix this by introducing:
...
  int val = (entry->value < 0) ? ACS_LRCORNER : entry->value;
...
and using this in both comparison and assignment.

Tested on x86_64-linux.

Remove some FIXME comments from DAP

I recently added a 'dap' component to bugzilla, and I filed a few bugs
there.  This patch removes the corresponding FIXME comments.

A few such comments still exist.  In at least one case, I have a fix
I'll be submitting eventually; in others I think I need to do a bit of
investigation to properly file a bug report.

gdb: add Richard Bunt to gdb/MAINTAINERS

[gdb/testsuite] Add Term::get_line_with_attrs

Add a new proc Term::get_line_with_attrs, similar to Term::get_line, that
annotates a tuiterm line with the active attributes.

For instance, the line representing the TUI status window with attribute mode
standout looks like this with Term::get_line:
...
exec No process In: ... L??   PC: ??
...
but like this with Term::get_line_with_attrs:
...
<reverse:1>exec No process In: ... L??   PC: ?? <reverse:0>
...

Also add Term::dump_screen_with_attrs, a Term::dump_screen variant that uses
Term::get_line_with_attrs instead of Term::get_line.

Tested by re-running the TUI test-cases (gdb.tui/*.exp and gdb.python/tui*.exp)
on x86_64-linux.

[gdb/testsuite] Factor out Term::_reset_attrs

Factor out new proc Term::_reset_attrs.

Tested by re-running the TUI test-cases (gdb.tui/*.exp and gdb.python/tui*.exp)
on x86_64-linux.

Re: readelf: Support SHT_RELR/DT_RELR for -r

Revert value of DT_ENCODING to as it was before commit a7fd118627, and
adjust readelf.

include/
* elf/common.h (DT_ENCODING): Set back to 32.
binutils/
* readelf.c (struct filedata): Don't size dynamic_info array
using DT_ENCODING.

PowerPC64 report number of stub iterations

As a developer it is sometimes useful to know how many times stubs
have been resized.  Report the count for users too, in ld --stats.

Automatic date update in version.in

Automatic date update in version.in

Re: Bug 23686, two segment faults in nm

The fix for pr23686 had a hole in the reloc address sanity check,
the calculation could overflow.  Note that stabsize is known to be a
non-zero multiple of 12 so stabsize - 4 can't underflow.

PR 23686
* syms.c (_bfd_stab_section_find_nearest_line): Correct
r->address sanity check.

coffcode.h handle_COMDAT tidy

I started down the path of attempting to fix
https://sourceware.org/pipermail/binutils/2023-April/127263.html but
decided after a while that I didn't want to mess with this code..

This patch is a just a few things that I thought worth doing, the main
one being reporting of errors up the call chain.  The while loop to
for loop change is shamelessly stolen from Oleg.

* coffcode.h (handle_COMDAT): Return bool.  Make sec_flags a
flagword*, and adjust to suit.  Replace while loop with for
loop.  Check isym.n_numaux before reading aux entries.  Alloc
coff_comdat_info and name in one call to bfd_alloc.  Remove
goto breakloop.
(styp_to_sec_flags): Adjust handle_COMDAT call.

tic54x set_arch_mach

The tic54x backend provides its own coff_set_arch_mach, but wants to
use the standard coff_set_section_contents.  BFD_JUMP_TABLE_WRITE
defines both of these functions, so the code also provides a wrapper
for coff_set_section_contents.  This is all quite OK, but I was on a
mission to remove unnecessary declarations in coffcode.h, and on
deleting the one for coff_set_arch_mach ran into a warning about the
function being unused.  I could have kept that declaration with its
ATTRIBUTE_UNUSED or written "static bool ATTRIBUTE_UNUSED" on the
definition but the latter is not usual and looks odd to me.  So I
had a closer look at tic54x_set_arch_mach and decided the function is
very likely wrong to allow bfd_arch_unknown.  Thus the backend should
be using the standard coff_set_arch_mach.

* coff-tic54x.c: Use BFD_JUMP_TABLE_WRITE (coff) in target vecs.
(tic54x_coff_set_arch_mach): Delete.
(tic54x_set_section_contents): Delete.
* coffcode.h: Delete unnecessary forward declarations.

Automatic date update in version.in

Update documentation for Python Frame.older and Frame.newer

I noticed that Frame.older and Frame.newer don't document that they
return None at the ends of the stack.  This patch updates the
documentation, and also fixes a somewhat related typo in a comment
that I noticed while digging into this.

Approved-By: Eli Zaretskii <eliz@gnu.org>

ld: drop stray blank from ld.texi

At least older makeinfo complains about it. Also fix an apparent typo
while touching that line.

gdb: fix post-hook execution for remote targets

Commit b5661ff2 ("gdb: fix possible use-after-free when
executing commands") attempted to fix possible use-after-free
in case command redefines itself.

Commit 37e5833d ("gdb: fix command lookup in execute_command ()")
updated the previous fix to handle subcommands as well by using the
original command string to lookup the command again after its execution.

This fixed the test in gdb.base/define.exp but it turned out that it
does not work (at least) for "target remote" and "target extended-remote".

The problem is that the command buffer P passed to execute_command ()
gets overwritten in dont_repeat () while executing "target remote"
command itself:

#0  dont_repeat () at top.c:822
#1  0x000055555730982a in target_preopen (from_tty=1) at target.c:2483
#2  0x000055555711e911 in remote_target::open_1 (name=0x55555881c7fe ":1234", from_tty=1, extended_p=0)
    at remote.c:5946
#3  0x000055555711d577 in remote_target::open (name=0x55555881c7fe ":1234", from_tty=1) at remote.c:5272
#4  0x00005555573062f2 in open_target (args=0x55555881c7fe ":1234", from_tty=1, command=0x5555589d0490)
    at target.c:853
#5  0x0000555556ad22fa in cmd_func (cmd=0x5555589d0490, args=0x55555881c7fe ":1234", from_tty=1)
    at cli/cli-decode.c:2737
#6  0x00005555573487fd in execute_command (p=0x55555881c802 "4", from_tty=1) at top.c:688

Therefore the second call to lookup_cmd () at line 697 fails to find
command because the original command string is gone.

This commit addresses this particular problem by creating a *copy* of
original command string for the sole purpose of using it after command
execution to lookup the command again. It may not be the most efficient
way but it's safer given that command buffer is shared and overwritten
in hard-to-foresee situations.

Tested on x86_64-linux.

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

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

gdb: Remove redundant frame switching

547ce8f00b fixed an issue where dynamic types were not being resolved
correctly prior to printing a value. The same issue was discovered when
printing the value using mi-mode, which was not covered by the fix.
Porting the fix to the mi-mode code path resolved the issue.

However, it was discovered that a later patch series, ending
2fc3b8a4cb8, independently fixed the issue in both the cli- and mi-mode
code paths, making the original fix unneeded.

This commit removes this extra frame switch and adds test coverage for
the mi-mode scenario to protect against any future divergence in this
area.

GDB built with GCC 11.

No test suite regressions detected. Compilers: GCC 12.1.0, ACfL 22.1,
Intel 22.1; Platforms: x86_64, aarch64.

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

gdb: safety checks in skip_prologue_using_sal

While working on the previous patch I reverted this commit:

  commit e86e87f77fd5d8afb3e714f1d9e09e0ff5b4e6ff
  Date:   Tue Nov 28 16:23:32 2006 +0000

          * symtab.c (find_pc_sect_line): Do not return a line before
            the start of a symtab.

When I re-ran the testsuite I saw some GDB crashes in the tests:

  gdb.dwarf2/dw2-line-number-zero.exp
  gdb.dwarf2/dw2-lines.exp
  gdb.dwarf2/dw2-vendor-extended-opcode.exp

GDB was reading beyond the end of an array in the function
skip_prologue_using_sal.

Now, without the above commit reverted I don't believe that this
should ever happen.  Reverting the above commit effectively breaks
GDB's symtab_and_line lookup, we try to find a result for an address,
and return the wrong symtab and line-table.  In
skip_prologue_using_sal we then walk the line table looking for an
appropriate entry, except we never find one, and GDB just keeps going,
wandering off the end of the array.

However, I think adding extra protection to prevent walking off the
end of the array is pretty cheap, and if something does go wrong in
the future then this should prevent a random crash.

Obviously, I have no reproducer for this, as I said, I don't think
this should impact GDB at all, this is just adding a little extra
caution.

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

gdb/testsuite: test for a function with no line table

This commit adds a test for the following commit:

  commit e86e87f77fd5d8afb3e714f1d9e09e0ff5b4e6ff
  Date:   Tue Nov 28 16:23:32 2006 +0000

              * symtab.c (find_pc_sect_line): Do not return a line before
              the start of a symtab.

We have been carrying a test for that commit in the Fedora GDB tree
since that commit was added to GDB.  I don't know why the test wasn't
added along with the original commit, but as was written, the test is
pretty gross, it uses objcopy to pull the .text section from an object
file, which was then injected into another source file within a .asm
statement...

... these days we can just make use of the DWARF assembler to achieve
the same results, so I've rewritten the test and think it is worth
adding this to upstream GDB.

The original patch was about about how we find the best symtab and
line table entry, and what to do when GDB can't find a good match.

The new test creates a CU with two functions, only one of which is
covered by the line table.  With the above patch reverted GDB returns
an invalid address.

With the above patch reverted I did run the testsuite to see what
other tests might already be exercising this functionality, and I
found two tests:

  gdb.dwarf2/dw2-step-out-of-function-no-stmt.exp
  gdb.dwarf2/dw2-vendor-extended-opcode.exp

These are pretty similar, they either create minimal, or no line table
for one of the functions in the source file, and as a consequence GDB
returns an unexpected address at some point during the test.

However, both of those tests are really focused on other issues, so I
think this new test does add some value.  Plus the new test is not
large, so it's not a huge cost to also run this new test.

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

gdb/breakpoint: use warning function instead of gdb_printf

Noticed that in breakpoint.c, in one place, we do this:

  gdb_printf (_("warning: Error removing "
                "breakpoint %d\n"),
                old_loc->owner->number);

Instead of using the `warning` function.  There are a number of
differences between using gdb_printf like this and calling `warning`,
the main one is probably that real warnings are sent to gdb_stderr,
while the above gdb_printf call will go to gdb_stdout.

In this commit I:

  1. Change to call `warning`, we can drop the "warning: " prefix from
  the string in breakpoint.c,

  2. Update the warning text, I now start with a lower case 'e', which
  I believe is the GDB style for warnings,

  3. And I have included the address of the bp_location in the warning
  messsage,

  4. Finally, I update all the tests (2) that include this error
  message.

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

gdb/testsuite: handle older Python versions in gdb.python/py-disasm.exp

It was pointed out on the mailing list that the new tests added in
this commit:

  commit 4de4e48514fc47aeb4ca95cd4091e2a333fbe9e1
  Date:   Tue Jan 24 15:35:45 2023 +0000

      gdb/python: extend the Python Disassembler API to allow for styling

will fail when GDB is built with Python 3.6 or earlier.  This is
because the error that is emitted when a function argument is missing
changed in Python 3.7, instead of an error like this:

  Python Exception <class 'TypeError'>: function missing required argument 'style' (pos 1)

earlier versions of Python emit:

  Python Exception <class 'TypeError'>: Required argument 'style' (pos 1) not found

and the new tests didn't allow for this.

This commit fixes this by allowing either pattern.  I've tested this
building GDB against Python 3.7.9 and 3.6.15, with this commit all
tests in gdb.python/py-disasm.exp now pass.

RISC-V: Support subtraction of .uleb128.

https://github.com/riscv-non-isa/riscv-elf-psabi-doc/commit/96d6e190e9fc04a8517f9ff7fb9aed3e9876cbd6

There are some known limitations for now,

* Do not shrink the length of the uleb128 value, even if the value is reduced
after relaxations.  Also reports error if the length grows up.

* The R_RISCV_SET_ULEB128 needs to be paired with and be placed before the
R_RISCV_SUB_ULEB128.

bfd/
* bfd-in2.h: Regenerated.
* elfnn-riscv.c (perform_relocation): Perform R_RISCV_SUB_ULEB128 and
R_RISCV_SET_ULEB128 relocations.  Do not shrink the length of the
uleb128 value, and report error if the length grows up.  Called the
generic functions, _bfd_read_unsigned_leb128 and _bfd_write_unsigned_leb128,
to encode the uleb128 into the section contents.
(riscv_elf_relocate_section): Make sure that the R_RISCV_SET_ULEB128
must be paired with and be placed before the R_RISCV_SUB_ULEB128.
* elfxx-riscv.c (howto_table): Added R_RISCV_SUB_ULEB128 and
R_RISCV_SET_ULEB128.
(riscv_reloc_map): Likewise.
(riscv_elf_ignore_reloc): New function.
* libbfd.h: Regenerated.
* reloc.c (BFD_RELOC_RISCV_SET_ULEB128, BFD_RELOC_RISCV_SUB_ULEB128):
New relocations to support .uleb128 subtraction.
gas/
* config/tc-riscv.c (md_apply_fix): Added BFD_RELOC_RISCV_SET_ULEB128
and BFD_RELOC_RISCV_SUB_ULEB128.
(s_riscv_leb128): Updated to allow uleb128 subtraction.
(riscv_insert_uleb128_fixes): New function, scan uleb128 subtraction
expressions and insert fixups for them.
(riscv_md_finish): Called riscv_insert_uleb128_fixes for all sections.
include/
* elf/riscv.h ((R_RISCV_SET_ULEB128, (R_RISCV_SUB_ULEB128): Defined.
ld/
* testsuite/ld-riscv-elf/ld-riscv-elf.exp: Updated.
* testsuite/ld-riscv-elf/uleb128*: New testcase for uleb128 subtraction.
binutils/
* testsuite/binutils-all/nm.exp: Updated since RISCV supports .uleb128.

RISC-V: Minor improvements for dis-assembler.

* Extract all private_data initializations into riscv_init_disasm_info, which
called from print_insn_riscv rather than riscv_disassemble_insn.

* The disassemble_free_target seems like the right place to release all target
private_data, also including the internal data structures, like riscv_subsets.
Therefore, add a new function, disassemble_free_riscv, to release them for safe.

opcodes/
* disassemble.c (disassemble_free_target): Called disassemble_free_riscv
for riscv to release private_data and internal data structures.
* disassemble.h: Added extern disassemble_free_riscv.
* riscv-dis.c (riscv_init_disasm_info): New function, used to init
riscv_private_data.
(riscv_disassemble_insn): Moved riscv_private_data initializations
into riscv_init_disasm_info.
(print_insn_riscv): Called riscv_init_disasm_info to init
riscv_private_data once time.
(disassemble_free_riscv): New function, used to free the internal data
structures, like riscv_subsets.

x86: permit all relational operators in insn operands

Oddly enough == and != were not permitted, because of '=' not having
been listed in operand_special_chars[].

x86: further adjust extend-to-32bit-address conditions

While a442cac5084e ("ix86: wrap constants") helped address a number of
inconsistencies between BFD64 and !BFD64 builds, it has also resulted in
certain bogus uses of constants to no longer be warned about. Leverage
the md_optimize_expr() hook to adjust when to actually truncate
expressions to 32 bits - any involvement of binary expressions (which
would be evaluated in 32 bits only when !BFD64) signals the need for
doing so. Plain constants (or ones merely subject to unary operators)
should remain un-truncated - they would be handled as bignums when
!BFD64, and hence are okay to permit.

To compensate
- slightly extend optimize_imm() (to be honest I never understood why
  the code being added - or something similar - wasn't there in the
  first place),
- adjust expectations of the disp-imm-32 testcase (there are now
  warnings, as there should be for any code which won't build [warning-
  free] when !BFD64, and Disp8/Imm8 are no longer used in the warned
  about cases).

gas: invoke md_optimize_expr() also for unary expressions

Give backends a chance to see these, just as they can see binary ones.
Most of those which use this hook already cope with NULL being passed
for the left operand (typically because of checking the operator first).
Adjust the two which don't.

Take the opportunity and also document the hook.

gas: maintain O_constant signedness in more cases

Unary '~' doesn't really produce an unsigned result. Neither does
subtraction (unless taking operand values into consideration). And an
abstract operator applied to two operands which aren't both unsigned
can't be assumed to yield an unsigned result; exceptions are
- shifts, where only signedness of the left hand operand matters,
- comparisons, which - unlike unary '!' - produce signed results (they
  deliver 0 or ~0, as opposed to '!', which yields 0 or 1),
- logical operators (yielding 0 or 1 and hence treated like unary '!').

While doing this (specifically while extending the all/quad testcase),
update .quad and .8byte documentation: With 64-bit architectures now
being common, it is highly inappropriate to state that these directives
unconditionally require bignums.

x86: tighten extend-to-32bit-address conditions

In a442cac5084e ("ix86: wrap constants") I made the truncation condition
too relaxed: Any indication of a mode that's possible with BFD64 only
should avoid the truncation. Therefore, like in the other two cases of
calls to extend_to_32bit_address(), also check whether we're generating
a 64-bit object.

Automatic date update in version.in

Use lower-case in @sc in the documentation

Eli pointed out that @sc only produces small caps for lower case
letters in its argument, so it's weird to write it using upper-case
letters.  This patch fixes the instances I found.

Approved-By: Eli Zaretskii <eliz@gnu.org>

gdb.fortran/lbound-ubound.exp: read expected lbound and ubound from function parameters (PR 30414)

gdb.fortran/lbound-ubound.exp reads the expected lbound and ubound
values by reading some output from the inferior.  This is racy when
running on boards where the inferior I/O is on a separate TTY than
GDB's, such as native-gdbserver.

I sometimes see this behavior:

    (gdb) continue
    Continuing.

    Breakpoint 2, do_test (lb=..., ub=...) at /home/jenkins/workspace/binutils-gdb_master_linuxbuild/platform/jammy-amd64/target_board/nati
    ve-gdbserver/src/binutils-gdb/gdb/testsuite/gdb.fortran/lbound-ubound.F90:45
    45        print *, ""   ! Test Breakpoint
    (gdb) Remote debugging from host ::1, port 37496

     Expected GDB Output:

    LBOUND = (-8, -10)
    UBOUND = (-1, -2)
    APB: Run a test here
    APB: Expected lbound '(-8, -10)'
    APB: Expected ubound ''

What happened is that expect read the output from GDB before the output
from the inferior, triggering this gdb_test_multiple clause:

    -re "$gdb_prompt $" {
        set found_prompt true

        if {$found_dealloc_breakpoint
            || ($expected_lbound != "" && $expected_ubound != "")} {
            # We're done.
        } else {
            exp_continue
        }
    }

So it set found_prompt, but the gdb_test_multiple kept going because
found_dealloc_breakpoint is false (this is the flag indicating that the
test is finished) and we still don't have expected_lbound and
expected_ubound.  Then, expect reads in the inferior I/O, triggering
this clause:

    -re ".*LBOUND = (\[^\r\n\]+)\r\n" {
        set expected_lbound $expect_out(1,string)
        if {!$found_prompt} {
            exp_continue
        }
    }

This sets expected_lbound, but since found_prompt is true, we don't do
exp_continue, and exit the gdb_test_multiple, without having an
expected_ubound.

Change the test to read the values from the lb and ub function
parameters instead.  As far as I understand, this still exercises what
we want to test.  These variables contain the return values of the
lbound and ubound functions as computed by the program.  We'll use them
to check the return values of the lbound and ubound functions as
computed by GDB.

Change-Id: I3c4d3d17d9291870a758a42301d15a007821ebb5
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30414

gdb/elfread.c: Add plt symbol check for _PROCEDURE_LINKAGE_TABLE_

In the current code, when execute the following test on LoongArch:

$ make check-gdb TESTS="gdb.base/gnu-ifunc.exp"
 === gdb Summary ===

 # of expected passes           111
 # of unexpected failures       62

According to IFUNC's working process [1]. first time the IFUNC function
is called, the dynamic linker will not simply fill the .got.plt entry
with the actual address of IFUNC symbol, it will call the IFUNC resolver
function and take the return address, uses it as the sym-bound address
and puts it in the .got.plt entry. Initial address in .got.plt entry is
not a real function addresss. Depending on the compiler implementation,
some different addresses will be filled in. Most architectures will use
a .plt entry address to fill in the corresponding .got.plt entry.

In gdb, elf_gnu_ifunc_resolve_addr() will be called to return a real
IFUNC function addresss. First check to see if the real address for
the IFUNC symbol has been resolved by the following function:

elf_gnu_ifunc_resolve_name (const char *name, CORE_ADDR *addr_p)
{
  if (elf_gnu_ifunc_resolve_by_cache (name, addr_p))
    return true;

  if (elf_gnu_ifunc_resolve_by_got (name, addr_p))
    return true;

  return false;
}

in elf_gnu_ifunc_resolve_by_got(), it gets the contents of the
.got.plt entry and determines if the contents is the correct address
by calling elf_gnu_ifunc_record_cache(). Based on the IFUNC working
principle analysis above, the address filled in the .got.plt entry is
not the actual target function address initially, it would be a .plt
entry address corresponding symbol like *@plt. In this case, gdb just
go back to execute the resolver function and puts the return address
in the .got.plt entry. After that, gdb can get a real ifun address via
.got.plt entry.

On LoongArch, initially, each address filled in the .got.plt entries
is the first .plt entry address. Some architectures such as LoongArch
define the symbol _PROCEDURE_LINKAGE_TABLE_ at the start of the .plt
section. This symbol is the first plt entry, so gdb needs to check
this symbol in elf_gnu_ifunc_record_cache().

On LoongArch .got.plt and .plt section as follow:

$objdump -D gdb/testsuite/outputs/gdb.base/gnu-ifunc/gnu-ifunc-0-0-0
...
0000000120010008 <.got.plt>:
   120010008:   ffffffff        0xffffffff
   12001000c:   ffffffff        0xffffffff
        ...
   120010018:   20004000        ll.w            $zero, $zero, 64(0x40)
   12001001c:   00000001        0x00000001
   120010020:   20004000        ll.w            $zero, $zero, 64(0x40)
   120010024:   00000001        0x00000001
   120010028:   20004000        ll.w            $zero, $zero, 64(0x40)
   12001002c:   00000001        0x00000001
   120010030:   20004000        ll.w            $zero, $zero, 64(0x40)
   120010034:   00000001        0x00000001

...
Disassembly of section .plt:

0000000120004000 <_PROCEDURE_LINKAGE_TABLE_>:
   120004000:   1c00018e        pcaddu12i       $t2, 12(0xc)
   120004004:   0011bdad        sub.d           $t1, $t1, $t3
   120004008:   28c021cf        ld.d            $t3, $t2, 8(0x8)
   12000400c:   02ff51ad        addi.d          $t1, $t1, -44(0xfd4)
   120004010:   02c021cc        addi.d          $t0, $t2, 8(0x8)
   120004014:   004505ad        srli.d          $t1, $t1, 0x1
   120004018:   28c0218c        ld.d            $t0, $t0, 8(0x8)
   12000401c:   4c0001e0        jirl            $zero, $t3, 0

0000000120004020 <__libc_start_main@plt>:
   120004020:   1c00018f        pcaddu12i       $t3, 12(0xc)
   120004024:   28ffe1ef        ld.d            $t3, $t3, -8(0xff8)
   120004028:   4c0001ed        jirl            $t1, $t3, 0
   12000402c:   03400000        andi            $zero, $zero, 0x0

0000000120004030 <abort@plt>:
   120004030:   1c00018f        pcaddu12i       $t3, 12(0xc)
   120004034:   28ffc1ef        ld.d            $t3, $t3, -16(0xff0)
   120004038:   4c0001ed        jirl            $t1, $t3, 0
   12000403c:   03400000        andi            $zero, $zero, 0x0

0000000120004040 <gnu_ifunc@plt>:
   120004040:   1c00018f        pcaddu12i       $t3, 12(0xc)
   120004044:   28ffa1ef        ld.d            $t3, $t3, -24(0xfe8)
   120004048:   4c0001ed        jirl            $t1, $t3, 0
   12000404c:   03400000        andi            $zero, $zero, 0x0
...

With this patch:

$make check-gdb TESTS="gdb.base/gnu-ifunc.exp"
=== gdb Summary ===

 #of expected passes            173

[1] https://sourceware.org/glibc/wiki/GNU_IFUNC

Signed-off-by: Hui Li <lihui@loongson.cn>

Re: Add section caches to coff_data_type

Another thing, section target_index is renumbered in
coff_compute_section_file_positions and _bfd_xcoff_bfd_final_link.  I
don't know that there is currently any way that the output bfd
section_by_target_index could be populated before this point but
clear them out so no one need worry about it.

* coffcode.h (coff_compute_section_file_positions): Clear
section_by_target_index hash table when changing target_index.
(_bfd_xcoff_bfd_final_link): Likewise.

[gdb/testsuite] Fix whitespace and indentation in lib/tuiterm.exp

I noticed a trailing whitespace and some indentation errors in lib/tuiterm.exp.

Fix these.

Tested by re-running the TUI test-cases (gdb.tui/*.exp and gdb.python/tui*.exp)
on x86_64-linux.

libsframe: testsuite: add tests for sframe_get_funcdesc_with_addr API

sframe_get_funcdesc_with_addr API is currently used internally by the
sframe_find_fre ().

In this test, we create three dummy SFrame FDEs with 4 FREs each.  Then,
we use few negative tests to lookup FREs with PCs not in the range of
PCs covered by the FDEs, ensuring graceful return from
sframe_get_funcdesc_with_addr in all cases.  Some positive tests are
also added that exercise further scenarios as well.

libsframe/
* Makefile.in: Regenerated.
* testsuite/libsframe.find/find.exp: Include new test.
* testsuite/libsframe.find/findfunc-1.c: New Test.
* testsuite/libsframe.find/local.mk: Include new test.

libsframe: testsuite: add new tests for sframe_find_fre API

libsframe provides an API to find the FRE associated with a given PC in
the program.  This patch adds a direct test of this API.

In this test, we create two dummy SFrame FDEs with 4 FREs each.  Then we
test that sframe_find_fre () works for the first, second, third and the
last FRE from one of the FDEs.  Such a test ensures better regression
testing for the sframe_find_fre () function which is going to be the
bread and butter of an SFrame based stack tracer.

libsframe/
* Makefile.in: Regenerated.
* testsuite/libsframe.find/find.exp: New test.
* testsuite/libsframe.find/findfre-1.c: New test.
* testsuite/libsframe.find/local.mk: Build new test.
* testsuite/local.mk: Include libsframe.find.

Re: Add section caches to coff_data_type

Commit 0e759f232b6d regressed these tests:
rs6000-aix7.2  +FAIL: Garbage collection test 1 (32-bit)
rs6000-aix7.2  +FAIL: Garbage collection test 1 (64-bit)
rs6000-aix7.2  +FAIL: Glink test 1 (32-bit)
rs6000-aix7.2  +FAIL: Glink test 1 (64-bit)

Investigation showed segfaults in coff_section_from_bfd_index called
by xcoff_write_global_symbol due to the hash table pointer being
NULL.  Well, yes, the hash table isn't initialised for the output bfd.
mkobject_hook is the wrong place to do that.

* coffcode.h: Revert 0e759f232b6d changes.
* peicode.h: Likewise.
* coff-x86_64.c (htab_hash_section_index, htab_eq_section_index):
Moved here from coffcode.h.
(coff_amd64_rtype_to_howto): Create section_by_index htab.
* coffgen.c (htab_hash_section_target_index),
(htab_eq_section_target_index): Moved here from coffcode.h.
(coff_section_from_bfd_index): Create section_by_target_index
htab.  Stash newly created sections in htab.

PR11601, Solaris assembler compatibility doesn't work

Well, it doesn't work on x86 or ppc, which both have # starting
comments anywhere on a line.  I think it is therefore only useful on
sparc.

PR 11601
* config/obj-elf.c (obj_elf_section_word): Only compile for sparc.
(obj_elf_section): Only support solaris .section directive on
sparc.
* doc/as.texi (Section): Mention that solaris .section
directive is only supported for sparc.

Automatic date update in version.in

Special case "&str" in Rust parser

"&str" is an important type in Rust -- it's the type of string
literals.  However, the compiler puts it in the DWARF in a funny way.
The slice itself is present and named "&str".  However, the Rust
parser doesn't look for types with names like this, but instead tries
to construct them from components.  In this case it tries to make a
pointer-to-"str" -- but "str" isn't always available, and in any case
that wouldn't yield the best result.

This patch adds a special case for &str.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22251
Reviewed-By: Andrew Burgess <aburgess@redhat.com>

Decorated symbols in import libs (BUG 30421)

  PR 30421
  * cofflink.c (_decoration_hash_newfunc): New function. (_bfd_coff_link_hash_table_init): Call it.
  * libcoff-in.h (struct coff_link_hash_table): Add decoration_hash field. (struct decoration_hash_entry): Declare. (_decoration_hash_newfunc): Prototype.
  * libcoff.h: Regenerate.

  * emultempl/pe.em (set_decoration): New function. (pe_fixup_stdcalls): Call the new function.
  * emultempl/pep.em (set_decoration): New function. (pep_fixup_stdcalls): Call the new function.
  * pe-dll.c (make_one): Check for decoated symbols.

PR29961, plugin-api.h: "Could not detect architecture endianess"

Found when attempting to build binutils on sparc sunos-5.8 where
sys/byteorder.h defines _BIG_ENDIAN but not any of the BYTE_ORDER
variants.  This patch adds the extra tests to cope with the old
machine, and tidies the header a little.

PR 29961
plugin-api.h: When handling non-gcc or gcc < 4.6.0 include
necessary header files before testing macros.  Make more use
of #elif.  Test _LITTLE_ENDIAN and _BIG_ENDIAN in final tests.

gcc-4.5 build fixes

Trying to build binutils with an older gcc currently fails.  Working
around these gcc bugs is not onerous so let's fix them.

bfd/
* elf32-csky.c (csky_elf_size_dynamic_sections): Don't type-pun
pointer.
* elf32-rl78.c (rl78_compute_complex_reloc): Rename "stat"
variable to "status".
gas/
* compress-debug.c (compress_finish): Supply all fields in
ZSTD_inBuffer initialisation.
include/
* xtensa-dynconfig.h (xtensa_isa_internal): Delete unnecessary
forward declaration.
opcodes/
* loongarch-opc.c: Supply all fields of zero struct initialisation
in various opcode tables.

Automatic date update in version.in