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

gprofng: include a new function in the right place

Static function name is not available in stripped libraries.
In this case, gprofng maps PC to a fake function like <static>@0xPC (<libname>).
Sometimes gprofng creates two functions instead of one.
Also FUNC_FLAG_SIMULATED is needed for these fake functions.

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

* src/LoadObject.cc (LoadObject::find_function): Set FUNC_FLAG_SIMULATED.
Include a new function in the right place.

[gdb/tui] Don't show line number for lines not in source file

Currently, for a source file containing only 5 lines, we also show line
numbers 6 and 7 if they're in scope of the source window:
...
    0 +-compact-source.c----------------+
    1 |___3_{                           |
    2 |___4_  return 0;                 |
    3 |___5_}                           |
    4 |___6_                            |
    5 |___7_                            |
    6 +---------------------------------+
...

Fix this by not showing line numbers not in a source file, such that we have instead:
...
    0 +-compact-source.c----------------+
    1 |___3_{                           |
    2 |___4_  return 0;                 |
    3 |___5_}                           |
    4 |                                 |
    5 |                                 |
    6 +---------------------------------+
...

Tested on x86_64-linux.

Suggested-By: Simon Marchi <simon.marchi@efficios.com>
Approved-By: Tom Tromey <tom@tromey.com>

Document how to use the linker to create a resource only DLL.

  PR 30359
  * ld.texi (WIN32): Document how to create a resource only DLL.

Add section caches to coff_data_type

  * libcoff-in.h (struct coff_tdata): Add section_by_index and section_by_target_index hash tables.
  * libcoff.h: Regenerate.
  * coffcode.h (htab_hash_section_index): New function. (htab_eq_section_index): New function. (htab_hash_section_target_index): New function. (htab_eq_section_target_index): New function. (coff_mkobject_hool): Create the hash tables.
  * peicode.h: Add the same new functions. (pe_mkobject_hook): Create the hash tables.
  * coff-x86_64.c (coff_amd64_rtype_to_howto): Use the new tables to speed up lookups.
  * coffgen.c (coff_section_from_bfd_index): Likewise. (_bfd_coff_close_and_cleanup): Delete the hash tables.

Update comments for the gdb/24331 fix.

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

gdb/testsuite: fix formatting of gdb.python/py-disasm.py

Run black on gdb.python/py-disasm.py file and commit the changes.

gdb/testsuite: make gdb_supported_languages a caching proc

Rewrite gdb_supported_languages as a caching proc that actually
queries GDB for the list of supported languages, rather than just
containing a hard-coded list of languages.

There's only one test that uses this proc right now,
gdb.python/py-function.exp, and that still passes after this change,
with no changes in the test names.

-Ur option documentation

  * ld.texi (-Ur): Clarify the actions of this option.

gdb/testsuite: fix regressions in break-main-file-remove-fail.exp

After this commit:

  commit a68f7e9844208ad8cd498f89b5100084ece7d0f6
  Date:   Tue May 9 10:28:42 2023 +0100

      gdb/testsuite: extend special '^' handling to gdb_test_multiple

buildbot notified me of a regression on s390 in the test:

  gdb.base/break-main-file-remove-fail.exp

the failure looks like this:

  print /d ((int (*) (void *, size_t)) munmap) (16781312, 4096)
  warning: Error removing breakpoint 0
  $2 = 0
  (gdb) FAIL: gdb.base/break-main-file-remove-fail.exp: cmdline: get integer valueof "((int (*) (void *, size_t)) munmap) (16781312, 4096)"

On the mailing list it has been reported that this failure also
impacts arm, aarch64, and possibly ppc/ppc64 too.

The above commit changed get_integer_valueof so that no output is
expected between the command and the '$2 = 0' line.  In this case the
'warning: Error removing breakpoint 0' output is causing the
get_integer_valueof call to fail.

The reason for this warning is that this test deliberately calls
munmap on a page of the inferior's code.  The test is checking that
GDB can handle the situation where a s/w breakpoint can't be
removed (due to the page no longer being readable/writable).

The test that is supposed to trigger the warning is later in the test
script when we delete a breakpoint.

So why do some targets trigger the warning earlier during the inferior
call?

The impacted targets use AT_ENTRY_POINT as their strategy for handling
inferior calls, that is, the trampoline that calls the inferior
function is placed at the program's entry point, e.g. often the _start
label.

If this location happens to be on the same page as the page that the
test script unmaps then, when the inferior function call returns, GDB
will not be able to remove the temporary breakpoint that is inserted
to catch the inferior function call returning!  As a result we end up
seeing the warning earlier than expected.

I did wonder if this means I should relax the pattern in
get_integer_valueof - just accept that there might be additional
output from GDB which we should ignore.

However, I don't think this the right way to go.  With the change in
a68f7e984420 we are now stricter for GDB emitting additional,
unexpected, output, and I think that is a good thing.

So, I think, in this case, in order to handle the possible extra
output, we should implement something like get_integer_valueof
directly in the gdb.base/break-main-file-remove-fail.exp test script.
This local version will handle the possible warning output.

After this the test should pass again on the impacted targets.

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

This commit extends the Python Disassembler API to allow for styling
of the instructions.

Before this commit the Python Disassembler API allowed the user to do
two things:

  - They could intercept instruction disassembly requests and return a
    string of their choosing, this string then became the disassembled
    instruction, or

  - They could call builtin_disassemble, which would call back into
    libopcode to perform the disassembly.  As libopcode printed the
    instruction GDB would collect these print requests and build a
    string.  This string was then returned from the builtin_disassemble
    call, and the user could modify or extend this string as needed.

Neither of these approaches allowed for, or preserved, disassembler
styling, which is now available within libopcodes for many of the more
popular architectures GDB supports.

This commit aims to fill this gap.  After this commit a user will be
able to do the following things:

  - Implement a custom instruction disassembler entirely in Python
    without calling back into libopcodes, the custom disassembler will
    be able to return styling information such that GDB will display
    the instruction fully styled.  All of GDB's existing style
    settings will affect how instructions coming from the Python
    disassembler are displayed in the expected manner.

  - Call builtin_disassemble and receive a result that represents how
    libopcode would like the instruction styled.  The user can then
    adjust or extend the disassembled instruction before returning the
    result to GDB.  Again, the instruction will be styled as expected.

To achieve this I will add two new classes to GDB,
DisassemblerTextPart and DisassemblerAddressPart.

Within builtin_disassemble, instead of capturing the print calls from
libopcodes and building a single string, we will now create either a
text part or address part and store these parts in a vector.

The DisassemblerTextPart will capture a small piece of text along with
the associated style that should be used to display the text.  This
corresponds to the disassembler calling
disassemble_info::fprintf_styled_func, or for disassemblers that don't
support styling disassemble_info::fprintf_func.

The DisassemblerAddressPart is used when libopcodes requests that an
address be printed, and takes care of printing the address and
associated symbol, this corresponds to the disassembler calling
disassemble_info::print_address_func.

These parts are then placed within the DisassemblerResult when
builtin_disassemble returns.

Alternatively, the user can directly create parts by calling two new
methods on the DisassembleInfo class: DisassembleInfo.text_part and
DisassembleInfo.address_part.

Having created these parts the user can then pass these parts when
initializing a new DisassemblerResult object.

Finally, when we return from Python to gdbpy_print_insn, one way or
another, the result being returned will have a list of parts.  Back in
GDB's C++ code we walk the list of parts and call back into GDB's core
to display the disassembled instruction with the correct styling.

The new API lives in parallel with the old API.  Any existing code
that creates a DisassemblerResult using a single string immediately
creates a single DisassemblerTextPart containing the entire
instruction and gives this part the default text style.  This is also
what happens if the user calls builtin_disassemble for an architecture
that doesn't (yet) support libopcode styling.

This matches up with what happens when the Python API is not involved,
an architecture without disassembler styling support uses the old
libopcodes printing API (the API that doesn't pass style info), and
GDB just prints everything using the default text style.

The reason that parts are created by calling methods on
DisassembleInfo, rather than calling the class constructor directly,
is DisassemblerAddressPart.  Ideally this part would only hold the
address which the part represents, but in order to support backwards
compatibility we need to be able to convert the
DisassemblerAddressPart into a string.  To do that we need to call
GDB's internal print_address function, and to do that we need an
gdbarch.

What this means is that the DisassemblerAddressPart needs to take a
gdb.Architecture object at creation time.  The only valid place a user
can pull this from is from the DisassembleInfo object, so having the
DisassembleInfo act as a factory ensures that the correct gdbarch is
passed over each time.  I implemented both solutions (the one
presented here, and an alternative where parts could be constructed
directly), and this felt like the cleanest solution.

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

gdb/python: rework how the disassembler API reads the result object

This commit is a refactor ahead of the next change which will make
disassembler styling available through the Python API.

Unfortunately, in order to make the styling support available, I think
the easiest solution is to make a very small change to the existing
API.

The current API relies on returning a DisassemblerResult object to
represent each disassembled instruction.  Currently GDB allows the
DisassemblerResult class to be sub-classed, which could mean that a
user tries to override the various attributes that exist on the
DisassemblerResult object.

This commit removes this ability, effectively making the
DisassemblerResult class final.

Though this is a change to the existing API, I'm hoping this isn't
going to cause too many issues:

  - The Python disassembler API was only added in the previous release
    of GDB, so I don't expect it to be widely used yet, and

  - It's not clear to me why a user would need to sub-class the
    DisassemblerResult type, I allowed it in the original patch
    because at the time I couldn't see any reason to NOT allow it.

Having prevented sub-classing I can now rework the tail end of the
gdbpy_print_insn function; instead of pulling the results out of the
DisassemblerResult object by calling back into Python, I now cast the
Python object back to its C++ type (disasm_result_object), and access
the fields directly from there.  In later commits I will be reworking
the disasm_result_object type in order to hold information about the
styled disassembler output.

The tests that dealt with sub-classing DisassemblerResult have been
removed, and a new test that confirms that DisassemblerResult can't be
sub-classed has been added.

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

Automatic date update in version.in

Correctly handle forward DIE references in scanner

The cooked index scanner has special code to handle forward DIE
references.  However, a bug report lead to the discovery that this
code does not work -- the "deferred_entry::spec_offset" field is
written to but never used, i.e., the lookup is done using the wrong
key.

This patch fixes the bug and adds a regression test.

The test in the bug itself used a thread_local variable, which
provoked a failure at runtime.  This test instead uses "maint print
objfiles" and then inspects to ensure that the entry in question has a
parent.  This lets us avoid a clang dependency in the test.

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

LoongArch: Fix PLT entry generate bug

If a function symbol only get its address by la.global, without
directly called by bl instruction, the PLT entry is not required.

bfd/ChangeLog:

* elfnn-loongarch.c (loongarch_elf_adjust_dynamic_symbol): Fix PLT
entry generate bug.

ld/ChangeLog:

* testsuite/ld-elf/shared.exp: Clear xfail for LoongArch.

Automatic date update in version.in

Automatic date update in version.in

Fix bad interaction between element limit and repeated values (BZ#24331).

Currently

  print -elements=3 -- "AAAAAA"

prints complete string, which is not what the user asked for.

Fix two buggy tests exposed by the fix, and add a new test.

Reviewed-by: Keith Seitz <keiths@redhat.com>

PR28955 mips gas segfault

Testing for NULL in pic_need_relax fixes the other call to this
function in md_estimate_size_before_relax.

PR 28955
* config/tc-mips.c (mips_frob_file): Move NULL sym test to..
(pic_need_relax): ..here.

PR28902, -T script with INSERT ordering

The answer to PR28902 may be deduced from the existing INSERT
documentation that says the default script is parsed after the -T
INSERT script, if you assume (correctly) that nothing special is done
when inserting into -T scripts overriding the default script.  In both
cases INSERT handling looks for the specified output section later on
the internal list of parsed script commands.  This isn't obvious
though, so make the ordering explicit, and mention that section
assignments are the same too.

PR 28902
* ld.texi (INSERT): Specify ordering when -T is used both to
override the default script and to augment.

Automatic date update in version.in

Fix regression due to Pragma Import series

A co-worker here at AdaCore discovered that the Pragma Import series
caused a rgression.  When debugging gnat1, gdb started asking for
overload resolution like:

(gdb) call pp(n)
Multiple matches for pp
[0] cancel
[1] pp (types.union_id) at ../../gcc/gcc/ada/treepr.adb:511
[2] treepr.pp (types.union_id) at ../../gcc/gcc/ada/treepr.adb:511

This worked before the series, and is strange anyway, because the
matches refer to the same function.

This patch adds a test case for this situation and fixes the bug by
pruning identical functions in remove_extra_symbols.

Use bool and early loop exit in remove_extra_symbols

This changes remove_extra_symbols to use bool rather than int, and
changes the nested loops to exit early when "remove_p" is set.

Use reference parameter in remove_extra_symbols

Changing ada-lang.c:remove_extra_symbols to take a reference parameter
makes the code a bit easier to read, by replacing "(*syms)" with plain
"syms".

Handle Ada Pragma Import and Pragma Export

Ada can import C APIs and also export Ada constructs to C via Pragma
Import and Pragma Export.  This patch adds support for these to gdb,
by arranging to either defer some aspects of a symbol to the
underlying C symbol (for Import) or by introducing a second symbol
(for Export).  A somewhat tricky approach is needed, both because gdb
doesn't generally handle symbol aliasing, and because Ada treats
symbol names in an unusual way (as compared to the rest of gdb).

Introduce symbol_block_ops::get_block_value

This adds a new callback to symbol_block_ops.  This callback lets a
LOC_BLOCK symbol implement its own function to find the underlying
block.

Define symbol::value_block separately

This moves the definition of symbol::value_block outside of the class.
A subsequent patch will change this method to use SYMBOL_BLOCK_OPS,
and it seemed simplest to move this method out-of-line, and cleaner to
do this as a separate change.

Bump MAX_SYMBOL_IMPLS

A subsequent patch will introduce more aclass registrations, causing
the number to go over the current maximum.  This bumps the number.
Note that there's a separate static assert that ensures that this
number doesn't get too large for the field size in the symbol.

Introduce lookup_minimal_symbol_linkage

This introduces a new function, lookup_minimal_symbol_linkage, and
refactors a couple other existing functions to call it.  This function
will be used in a subsequent patch.

gdb: remove unnecessary call to std::string constructor

I spotted this explicit call to std::string, which creates an
unnecessary temporary extra std::string, while calling emplace_back.
I'm not sure if it has any impact in an optimized build, maybe the
compiler elides it.  But still, it's unnecessary.

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

Add dynamic_prop::is_constant

I noticed many spots checking whether a dynamic property's kind is
PROP_CONST.  Some spots, I think, are doing a slightly incorrect check
-- checking for != PROP_UNDEFINED where == PROP_CONST is actually
required, the key thing being that const_val may only be called for
PROP_CONST properties.

This patch adds dynamic::is_constant and then updates these checks to
use it.

Regression tested on x86-64 Fedora 36.

Implement DAP register scope

I noticed that gdb's DAP code did not provide a way to see register
values.  DAP defines a "register" scope, which this patch implements.
This patch also adds the missing (and optional) "presentationHint" to
scopes.

Fix calling debuginfo-less functions in Ada

A co-worker at AdaCore noticed that calling a function without
debuginfo yields:

(gdb) print plus_one(23)
'pck.plus_one' has unknown return type; cast the call to its declared return type

However, this also happens if you follow the directions and add the
cast.

This patch fixes the problem and adds a regression test.

gdb/python: implement DisassemblerResult.__str__ method

Add the DisassemblerResult.__str__ method.  This gives the same result
as the DisassemblerResult.string attribute, but can be useful
sometimes depending on how the user is trying to print the object.

There's a test for the new functionality.

gdb/python: implement __repr__ methods for py-disasm.c types

Add a __repr__ method for the DisassembleInfo and DisassemblerResult
types, and add some tests for these new methods.

gdb/doc: improve Python Disassembler API documentation

Some small improvements to the Python Disassembler API documentation:

  * Be consistent about using the package scope in the @deftp lines,

  * Rework the description of the DisassemblerResult class to include
    mention of builtin_disassemble.

gdb/testsuite: extend special '^' handling to gdb_test_multiple

The commit:

  commit 08ec06d6440745ef9204d39197aa1e732df41056
  Date:   Wed Mar 29 10:41:07 2023 +0100

      gdb/testsuite: special case '^' in gdb_test pattern

Added some special handling of '^' to gdb_test -- a leading '^' will
cause the command regexp to automatically be included in the expected
output pattern.

It was pointed out that the '-wrap' flag of gdb_test_multiple is
supposed to work in the same way as gdb_test, and that the recent
changes for '^' had not been replicated for gdb_test_multiple.  This
patch addresses this issue.

So, after this commit, the following two constructs should have the
same meaning:

  gdb_test "command" "^output" "test name"

  gdb_test_multiple "command" "test name" {
    -re -wrap "^output" {
      pass $gdb_test_name
    }
  }

In both cases the '^' will case gdb.exp to inject a regexp that
matches 'command' after the '^' and before the 'output', this is in
addition to adding the $gdb_prompt pattern after 'output' in the
normal way.

The special '^' handling is only applied when '-wrap' is used, as this
is the only mode that aims to mimic gdb_test.

While working on this patch I realised that I could actually improve
the logic for the special '^' handling in the case where the expected
output pattern is empty.  I replicated these updates for both gdb_test
and gdb_test_multiple in order to keep these two paths in sync.

There were a small number of tests that needed adjustment after this
change, mostly just removing command regexps that are now added
automatically, but the gdb.base/settings.exp case was a little weird
as it turns out trying to match a single blank line is probably harder
now than it used to be -- still, I suspect this is a pretty rare case,
so I think the benefits (improved anchoring) outweigh this small
downside (IMHO).

gdb: fix error message for $_gdb_maint_setting

I spotted this behaviour:

  (gdb) p $_gdb_maint_setting("xxx")
  First argument of $_gdb_maint_setting must be a valid setting of the 'show' command.

Notice that GDB claims I need to use a setting from the 'show'
command, which isn't correct for $_gdb_maint_setting, in this case I
need to use a setting from 'maintenance show'.

This same issue is present for $_gdb_maint_setting_str.

This commit fixes this minor issue.

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

[gdb/testsuite] Fix gdb.dwarf2/opt-out-not-implptr.exp for -m32

When running test-case gdb.dwarf2/opt-out-not-implptr.exp with target board
unix/-m32 we have:
...
(gdb) print noptr^M
$1 = {0, <optimized out>, <optimized out>, <optimized out>}^M
(gdb) FAIL: gdb.dwarf2/opt-out-not-implptr.exp: print noptr
...

The problem happens when evaluating this dwarf expression:
...
  <45> DW_AT_location : 13 byte block: 10 86 ea d7 d0 96 8e cf 92 5c 9f 93 8 \
  (DW_OP_constu: 6639779683436459270; DW_OP_stack_value; DW_OP_piece: 8)
...

The DW_OP_constu pushes a value with "generic type" on to the DWARF stack, and
the "generic type" has the size of an address on the target machine, which for
target board unix/-m32 is 4 bytes.  Consequently, the constant is abbreviated.

Next, the DW_OP_piece declares that the resulting 4-byte value is 8 bytes
large, and we hit this clause in rw_pieced_value:
...
            /* Use zeroes if piece reaches beyond stack value.  */
            if (p->offset + p->size > stack_value_size_bits)
              break;
...
and consequently get a zero.

We could just add require is_target_64 to the test-case, but instead, add a
32-bit case and require is_target_64 just for the 64-bit case.

Tested on x86_64-linux.

[gdb/testsuite] Make is_64_target more robust

I ran test-case gdb.dwarf2/opt-out-not-implptr.exp with make-check-all.sh, and
with target board dwarf64 ran into:
...
FAIL: gdb.dwarf2/opt-out-not-implptr.exp: print noptr
...
due to is_target_64 failing because of:
...
builtin_spawn -ignore SIGHUP gcc -fno-stack-protector \
  -fdiagnostics-color=never -w -c -gdwarf64 -g -o is_64_target.o \
  is_64_target.c^M
gcc: error: '-gdwarf64' is ambiguous; use '-gdwarf-64' for DWARF version or \
  '-gdwarf -g64' for debug level^M
compiler exited with status 1
...

The FAIL is the same FAIL I run into with target board unix/-m32: is_target_64
fails for both cases.

The reason that is_target_64 is failing for target board dwarf64, is because
of using system compiler 7.5.0 which doesn't support -gdwarf64.

Fix this by making is_target_64 use nodebug instead of debug for compilation.

Tested on x86_64-linux.

[gdb/cli] Fix wrapping for TERM=ansi

I. Auto-detected width (xterm vs. ansi)

Say we have a terminal with a width of 40 chars:
...
$ echo $COLUMNS
40
...

With TERM=xterm, we report a width of 40 chars:
...
$ TERM=xterm gdb
(gdb) show width
Number of characters gdb thinks are in a line is 40.
...

And with TERM=ansi, a width of 39 chars:
...
$ TERM=ansi gdb
(gdb) show width
Number of characters gdb thinks are in a line is 39.
...

Gdb uses readline to auto-detect screen size, and readline decides in the
TERM=ansi case that the terminal does not have reliable auto-wrap, and
consequently decides to hide the last terminal column from the readline user
(in other words GDB), hence we get 39 instead of 40.

II. Types of wrapping

Looking a bit more in detail inside gdb, it seems there are two types of
wrapping:
- readline wrapping (in other words, prompt edit wrapping), and
- gdb output wrapping (can be observed by issuing "info sources").
  This type of wrapping attempts to wrap some of the gdb output earlier
  than the indicated width, to not break lines in inconvenient places.

III. Readline wrapping, auto-detected screen size

Let's investigate readline wrapping with the auto-detected screen widths.

First, let's try with xterm:
...
$ TERM=xterm gdb
(gdb) 7890123456789012345678901234567890
123
...
That looks as expected, wrapping occurs after 40 chars.

Now, let's try with ansi:
...
$ TERM=ansi gdb
(gdb) 78901234567890123456789012345678
90123
...
It looks like wrapping occurred after 38, while readline should be capable of
wrapping after 39 chars.

This is caused by readline hiding the last column, twice.

In more detail:
- readline detects the screen width: 40,
- readline hides the last column, setting the readline screen width to 39,
- readline reports 39 to gdb as screen width,
- gdb sets its width setting to 39,
- gdb sets readline screen width to 39,
- readline hides the last column, again, setting the readline screen width to
  38.

This is reported as PR cli/30346.

IV. gdb output wrapping, auto-detected screen size

Say we set the terminal width to 56. With TERM=xterm, we have:
...
/home/abuild/rpmbuild/BUILD/glibc-2.31/csu/elf-init.c,
/data/vries/hello.c,
...
but with TERM=ansi:
...
/home/abuild/rpmbuild/BUILD/glibc-2.31/csu/elf-init.c, /
data/vries/hello.c,
...

So what happened here?  With TERM=ansi, the width setting is auto-detected to
55, and gdb assumes the terminal inserts a line break there, which it doesn't
because the terminal width is 56.

This is reported as PR cli/30411.

V. Fix PRs

Fix both mentioned PRs by taking into account the hidden column when readline
reports the screen width in init_page_info, and updating chars_per_line
accordingly.

Note that now we report the same width for both TERM=xterm and TERM=ansi,
which is much clearer.

The point where readline respectively expects or ensures wrapping is still
indicated by "maint info screen", for xterm:
...
Number of characters readline reports are in a line is 40.
...
and ansi:
...
Number of characters readline reports are in a line is 39.
...

VI. Testing

PR cli/30346 is covered by existing regression tests gdb.base/wrap-line.exp
and gdb.tui/wrap-line.exp, so remove the KFAILs there.

I didn't manage to come up with a regression test for PR cli/30411.  Perhaps
that would be easier if we had a maintenance command that echoes its arguments
while applying gdb output wrapping.

Tested on x86_64-linux.

PR cli/30346
PR cli/30411
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30346
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30411

x86: move a few more disassembler helper functions

... such that they wouldn't need forward declarations anymore. Note that
append_seg() already was suitably placed.

x86: move get<N>() disassembler helper functions

... such that none of them would need forward declarations anymore.

x86: slightly simplify i386_parse_name()

With the switch to parse_real_register() (commit 4faaa10f3fab) "bad_reg"
cannot come back anymore. Drop the respective check.

gas: equates of registers

There are two problems: symbol_equated_p() doesn't recognize equates of
registers, and S_CAN_BE_REDEFINED() goes by section rather than by
expression type. Both together undermine .eqv and .equiv clearly meaning
to guard the involved symbols against re-definition (both ways).

To compensate pseudo_set() now using O_symbol and S_CAN_BE_REDEFINED()
now checking for O_register,
- for targets creating register symbols through symbol_{new,create}() ->
  symbol_init() -> S_SET_VALUE() (alpha, arc, dlx, ia64, m68k, mips,
  mmix, tic4x, tic54x, plus anything using cgen or itbl-ops), have
  symbol_init() set their expressions to O_register,
- x86'es parse_register() also can't go by section anymore when
  trying to "look through" equates; probably symbol_equated_p() should
  have been used there from the beginning, if only that had worked for
  equates of registers,
- various targets need to "look through" equates when parsing insn
  operands (which also helps transitive forward equates); perhaps even
  more ought to, but many don't look to consider the possibility of
  register equates in the first place.

This was uncovered by code reported in PR gas/30274 (duplicating
PR gas/30272), except that there .eqv was used when really .equ was
meant. Therefore that bug report is addressed here only in so far as
gas wouldn't crash anymore; the code there still won't assemble
successfully, just that now the issues there are properly diagnosed.

Automatic date update in version.in

Do not print <synthetic pointer> when piece is optimized out

A user reported a bug where printing a certain array of integer types
would result in the nonsensical:

(gdb) p l_126
$1 = {6639779683436459270, <synthetic pointer>, <synthetic pointer>, <synthetic pointer>}

I tracked this down to some issues in the DWARF expression code.
First, check_pieced_synthetic_pointer did not account for the
situation where a location expression does not describe all the bits
of a value -- in this case it returned true, meaning there is a
synthetic pointer, but in fact these bits are optimized out.  (It
turns out this incorrect output had already been erroneously tested
for as well.)

Next, rw_pieced_value did not mark these bits as optimized-out,
either.

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

gdb/testsuite: Match file size in gdb.debuginfod/crc_mismatch.exp

gdb's debuginfod progress messages include the size of the file being
downloaded if the size information is available at the time the message
is printed.  For example:

    Downloading 10 MB separate debug info for /lib64/libxyz.so

This size information is omitted if it's not available at the time of
printing:

    Downloading separate debug info for /lib64/libxyz.so

A pattern in crc_mismatch.exp fails to be matched if a progress message
includes a file size.  Add a wildcard to the pattern so that it matches
the progress message whether or not it includes the file size.

Disable out-of-scope watchpoints

Currently, when a local software watchpoint goes out of scope, GDB sets
the watchpoint's disposition to `delete at next stop' and then normal
stops (i.e., stop and wait for the next GDB command). When GDB normal
stops, it automatically deletes the breakpoints with their disposition
set to `delete at next stop'.

Suppose a Python script decides not to normal stop when a local
software watchpoint goes out of scope, the watchpoint will not be
automatically deleted even when its disposition is set to
`delete at next stop'.

Since GDB single-steps the program and tests the watched expression
after each instruction, not deleting the watchpoint causes the
watchpoint to be hit many more times than it should, as reported in
PR python/29603.

This was happening because the watchpoint is not deleted or disabled
when going out of scope.

This commit fixes this issue by disabling the watchpoint when going out
of scope. It also adds a test to ensure this feature isn't regressed in
the future.

Calling `breakpoint_auto_delete' on all kinds of stops (in
`fetch_inferior_event') seem to solve this issue, but is in fact
inappropriate, since `breakpoint_auto_delete' goes over all breakpoints
instead of just going through the bpstat chain (which only contains the
breakpoints that were hit right now).

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

Add "scheduler-locking" to documentation index

I noticed that "scheduler-locking" does not appear in the index of the
gdb manual.  This patch corrects this oversight.

Add LDPT_REGISTER_CLAIM_FILE_HOOK_V2 linker plugin hook [GCC PR109128]

This is one part of the fix for GCC PR109128, along with a
corresponding GCC change.  Without this patch, what happens in the
linker, when an unused object in a .a file has offload data, is that
elf_link_is_defined_archive_symbol calls bfd_link_plugin_object_p,
which ends up calling the plugin's claim_file_handler, which then
records the object as one with offload data. That is, the linker never
decides to use the object in the first place, but use of this _p
interface (called as part of trying to decide whether to use the
object) results in the plugin deciding to use its offload data (and a
consequent mismatch in the offload data present at runtime).

The new hook allows the linker plugin to distinguish calls to
claim_file_handler that know the object is being used by the linker
(from ldmain.c:add_archive_element), from calls that don't know it's
being used by the linker (from elf_link_is_defined_archive_symbol); in
the latter case, the plugin should avoid recording the object as one
with offload data.

bfd/
* plugin.c (struct plugin_list_entry): Add claim_file_v2.
(register_claim_file_v2): New.
(try_load_plugin): Use LDPT_REGISTER_CLAIM_FILE_HOOK_V2.
(ld_plugin_object_p): Take second argument.
(bfd_link_plugin_object_p): Update call to ld_plugin_object_p.
(register_ld_plugin_object_p): Update argument prototype.
(bfd_plugin_object_p): Update call to ld_plugin_object_p.
* plugin.h (register_ld_plugin_object_p): Update argument
prototype.

include/
* plugin.api.h (ld_plugin_claim_file_handler_v2)
(ld_plugin_register_claim_file_v2)
(LDPT_REGISTER_CLAIM_FILE_HOOK_V2): New.
(struct ld_plugin_tv): Add tv_register_claim_file_v2.

ld/
* plugin.c (struct plugin): Add claim_file_handler_v2.
(LDPT_REGISTER_CLAIM_FILE_HOOK_V2): New.
(plugin_object_p): Add second argument.  Update call to
plugin_call_claim_file.
(register_claim_file_v2): New.
(set_tv_header): Handle LDPT_REGISTER_CLAIM_FILE_HOOK_V2.
(plugin_call_claim_file): Add argument known_used.
(plugin_maybe_claim): Update call to plugin_object_p.
* testplug.c, testplug2.c, testplug3.c, testplug4.c: Handle
LDPT_REGISTER_CLAIM_FILE_HOOK_V2.
* testsuite/ld-plugin/plugin-1.d, testsuite/ld-plugin/plugin-10.d,
testsuite/ld-plugin/plugin-11.d, testsuite/ld-plugin/plugin-13.d,
testsuite/ld-plugin/plugin-14.d, testsuite/ld-plugin/plugin-15.d,
testsuite/ld-plugin/plugin-16.d, testsuite/ld-plugin/plugin-17.d,
testsuite/ld-plugin/plugin-18.d, testsuite/ld-plugin/plugin-19.d,
testsuite/ld-plugin/plugin-2.d, testsuite/ld-plugin/plugin-26.d,
testsuite/ld-plugin/plugin-3.d, testsuite/ld-plugin/plugin-30.d,
testsuite/ld-plugin/plugin-4.d, testsuite/ld-plugin/plugin-5.d,
testsuite/ld-plugin/plugin-6.d, testsuite/ld-plugin/plugin-7.d,
testsuite/ld-plugin/plugin-8.d, testsuite/ld-plugin/plugin-9.d:
Update test expectations.

Automatic date update in version.in

[gdb/tui] Fix tui compact-source a bit more

Andrew pointed out that the behaviour as tested in gdb.tui/compact-source.exp
is incorrect:
...
0 +-compact-source.c--------------------------------------------------------+
1 |___3_{                                                                   |
2 |___4_  return 0;                                                         |
3 |___5_}                                                                   |
4 |___6_                                                                    |
5 |___7_                                                                    |
6 |___8_                                                                    |
7 |___9_                                                                    |
8 +-------------------------------------------------------------------------+
...

The last line number in the source file is 5, and there are 7 lines to display
source lines, so if we'd scroll all the way down, the first line number in the
source window would be 5, and the last one would be 11.

To represent 11 we'd need 2 digits, so we expect to see ___04_ here instead of
___4_, even though all line numbers currently in the src window (3-9) can be
represented with only 1 digit.

Fix this in tui_source_window::set_contents, by updating the computation of
max_line_nr:
...
-      int max_line_nr = std::max (lines_in_file, last_line_nr_in_window);
+      int max_line_nr = lines_in_file + nlines - 1;
...

Tested on x86_64-linux.

Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
Approved-By: Tom Tromey <tom@tromey.com>

gdb/rust: fix crash for expression debug with strings

While working on another patch I did this:

  (gdb) set debug expression 1
  (gdb) set language rust
  (gdb) p "foo"
  Operation: OP_AGGREGATE
   Type: &str

  Fatal signal: Segmentation fault
  ... etc ...

The problem is that the second field of the rust_aggregate_operation
is created as a nullptr, this can be seen in rust-parse.c. in the
function rust_parser::parse_string().

However, in expop.h, in the function dump_for_expression, we make the
assumption that the expressions will never be nullptr.

I did consider moving the nullptr handling into a new function
rust_aggregate_operation::dump, however, as the expression debug
dumping code is not exercised as much as it might be, I would rather
that this code be hardened and able to handle a nullptr without
crashing, so I propose that we add nullptr handling into the general
dump_for_expression function.  The behaviour is now:

  (gdb) set debug expression 1
  (gdb) set language rust
  (gdb) p "foo"
  Operation: OP_AGGREGATE
   Type: &str
   nullptr
   Vector:
    String: data_ptr
    Operation: UNOP_ADDR
     Operation: OP_STRING
      String: foo
    String: length
    Operation: OP_LONG
     Type: usize
     Constant: 3
  evaluation of this expression requires the target program to be active
  (gdb)

There's a new test to check for this case.

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

Re: stack overflow in debug_write_type

Apparently u.kindirect->slot can point at a NULL.

* debug.c (debug_write_type): Don't segfault on NULL indirect.

or1k relocation truncated to fit: R_OR1K_GOT16 even when using -mcmodel=large

  PR 30422
  * elf32-or1k.c (or1k_elf_relocate_section): Prescan for R_OR1K_GOT_AHI16 relocs as they may occur after R_OR1K_GOT16 relocs.

Add linker option to include local symbols in  the linker map.

  PR 16566
  * ldlang.c (ld_is_local_symbol): New function. (print_input_section): Add code to display local symbols in the section.
  * ldlex.h (enum option_values): Add OPTION_PRINT_MAP_LOCALS and OPTION_PRINT_MAP_LOCALS.
  * lexsup.c (ld_options[]): Add entries for --print-map-locals and --no-print-map-locals.
  * NEWS: Mention the new feature.
  * ld.h (struct ld_config_type): Add print_map_locals field.
  * ld.texi: Document the new command line option.
  * testsuite/ld-scripts/sizeof.s: Add a local symbol.
  * testsuite/ld-scripts/map-locals.d: New test control file.
  * testsuite/ld-scripts/map-address.exp: Run the new test.

[gdb/tui] Fix tui compact-source

Consider a hello.c, with less than 10 lines:
...
$ wc -l hello.c
8 hello.c
...
and compiled with -g into an a.out.

With compact-source off:
...
$ gdb -q a.out \
    -ex "set tui border-kind ascii" \
    -ex "maint set tui-left-margin-verbose on" \
    -ex "set tui compact-source off" \
    -ex "tui enable"
...
we get:
...
+-./data/hello.c-----------------------+
|___000005_{                           |
|___000006_  printf ("hello\n");       |
|___000007_  return 0;                 |
|___000008_}                           |
|___000009_                            |
|___000010_                            |
|___000011_                            |
...
but with compact-source on:
...
+-./data/hello.c-----------------------+
|___5{                                 |
|___6  printf ("hello\n");             |
|___7  return 0;                       |
|___8}                                 |
|___9                                  |
|___1                                  |
|___1                                  |
...

There are a couple of problems with compact-source.

First of all the documentation mentions:
...
The default display uses more space for line numbers and starts the
source text at the next tab stop; the compact display uses only as
much space as is needed for the line numbers in the current file, and
only a single space to separate the line numbers from the source.
...

The bit about the default display and the next tab stop looks incorrect.  The
source doesn't start at a tab stop, instead it uses a single space to separate
the line numbers from the source.

Then the documentation mentions that there's single space in the compact
display, but evidently that's missing.

Then there's the fact that the line numbers "10" and "11" are both abbreviated
to "1" in the compact case.

The abbreviation is due to allocating space for <lines in source>, which is
8 for this example, and takes a single digit.  The line numbers though
continue past the end of the file, so fix this by allocating space for
max (<lines in source>, <last line in window>), which in this example takes 2
digits.

The missing space is due to some confusion about what the "1" here in
tui_source_window::set_contents represent:
...
      double l = log10 ((double) offsets->size ());
      m_digits = 1 + (int) l;
...

It could be the trailing space that's mentioned in tui-source.h:
...
  /* How many digits to use when formatting the line number.  This
     includes the trailing space.  */
  int m_digits;
...

Then again, it could be part of the calculation for the number of digits
needed for printing.  With this minimal example:
...
int main () {
  for (int i = 8; i <= 11; ++i) {
    double l = log10 ((double) i);
    printf ("%d %d\n", i, (int)l);
  }
  return 0;
}
...
we get:
...
$ ./a.out
8 0
9 0
10 1
11 1
...
which shows that the number of digits needed for printing i is
"1 + (int)log10 ((double) i)".

Fix this by introducing named variables needed_digits and trailing_space, each
adding 1.

With the fixes, we get for compact-source on:
...
+-./data/hello.c-----------------------+
|___05_{                               |
|___06_  printf ("hello\n");           |
|___07_  return 0;                     |
|___08_}                               |
|___09_                                |
|___10_                                |
|___11_                                |
|...

Also fix the documentation and help text to actually match effect of
compact-source.

Tested on x86_64-linux.

Automatic date update in version.in

Support higher baud rates when they are defined

On Linux at least, baud rate codes are defined up to B4000000. Allow the
user to select them if they are present in the system headers.

Change-Id: I393ff32e4a4b6127bdf97e3306ad5b6ebf7c934e

gdb: fix use-after-free in check_longjmp_breakpoint_for_call_dummy

Commit 7a8de0c33019 ("Remove ALL_BREAKPOINTS_SAFE") introduced a
use-after-free in the breakpoints iterations (see below for full ASan
report).  This makes gdb.base/stale-infcall.exp fail when GDB is build
with ASan.

check_longjmp_breakpoint_for_call_dummy iterates on all breakpoints,
possibly deleting the current breakpoint as well as related breakpoints.
The problem arises when a breakpoint in the B->related_breakpoint chain
is also B->next.  In that case, deleting that related breakpoint frees
the breakpoint that all_breakpoints_safe has saved.

The old code worked around that by manually changing B_TMP, which was
the next breakpoint saved by the "safe iterator":

while (b->related_breakpoint != b)
  {
    if (b_tmp == b->related_breakpoint)
      b_tmp = b->related_breakpoint->next;
    delete_breakpoint (b->related_breakpoint);
  }

(Note that this seemed to assume that b->related_breakpoint->next was
the same as b->next->next, not sure this is guaranteed.)

The new code kept the B_TMP variable, but it's not useful in that
context.  We can't go change the next breakpoint as saved by the safe
iterator, like we did before.  I suggest fixing that by saving the
breakpoints to delete in a map and deleting them all at the end.

Here's the full ASan report:

    (gdb) PASS: gdb.base/stale-infcall.exp: continue to breakpoint: break-run1
    print infcall ()
    =================================================================
    ==47472==ERROR: AddressSanitizer: heap-use-after-free on address 0x611000034980 at pc 0x563f7012c7bc bp 0x7ffdf3804d70 sp 0x7ffdf3804d60
    READ of size 8 at 0x611000034980 thread T0
        #0 0x563f7012c7bb in next_iterator<breakpoint>::operator++() /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/next-iterator.h:66
        #1 0x563f702ce8c0 in basic_safe_iterator<next_iterator<breakpoint> >::operator++() /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/safe-iterator.h:84
        #2 0x563f7021522a in check_longjmp_breakpoint_for_call_dummy(thread_info*) /home/smarchi/src/binutils-gdb/gdb/breakpoint.c:7611
        #3 0x563f714567b1 in process_event_stop_test /home/smarchi/src/binutils-gdb/gdb/infrun.c:6881
        #4 0x563f71454e07 in handle_signal_stop /home/smarchi/src/binutils-gdb/gdb/infrun.c:6769
        #5 0x563f7144b680 in handle_inferior_event /home/smarchi/src/binutils-gdb/gdb/infrun.c:6023
        #6 0x563f71436165 in fetch_inferior_event() /home/smarchi/src/binutils-gdb/gdb/infrun.c:4387
        #7 0x563f7136ff51 in inferior_event_handler(inferior_event_type) /home/smarchi/src/binutils-gdb/gdb/inf-loop.c:42
        #8 0x563f7168038d in handle_target_event /home/smarchi/src/binutils-gdb/gdb/linux-nat.c:4219
        #9 0x563f72fccb6d in handle_file_event /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:573
        #10 0x563f72fcd503 in gdb_wait_for_event /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:694
        #11 0x563f72fcaf2b in gdb_do_one_event(int) /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:217
        #12 0x563f7262b9bb in wait_sync_command_done() /home/smarchi/src/binutils-gdb/gdb/top.c:426
        #13 0x563f7137a7c3 in run_inferior_call /home/smarchi/src/binutils-gdb/gdb/infcall.c:650
        #14 0x563f71381295 in call_function_by_hand_dummy(value*, type*, gdb::array_view<value*>, void (*)(void*, int), void*) /home/smarchi/src/binutils-gdb/gdb/infcall.c:1332
        #15 0x563f7137c0e2 in call_function_by_hand(value*, type*, gdb::array_view<value*>) /home/smarchi/src/binutils-gdb/gdb/infcall.c:780
        #16 0x563f70fe5960 in evaluate_subexp_do_call(expression*, noside, value*, gdb::array_view<value*>, char const*, type*) /home/smarchi/src/binutils-gdb/gdb/eval.c:649
        #17 0x563f70fe6617 in expr::operation::evaluate_funcall(type*, expression*, noside, char const*, std::__debug::vector<std::unique_ptr<expr::operation, std::default_delete<expr::operation> >, std::allocator<std::unique_ptr<expr::operation, std::default_delete<expr::operation> > > > const&) /home/smarchi/src/binutils-gdb/gdb/eval.c:677
        #18 0x563f6fd19668 in expr::operation::evaluate_funcall(type*, expression*, noside, std::__debug::vector<std::unique_ptr<expr::operation, std::default_delete<expr::operation> >, std::allocator<std::unique_ptr<expr::operation, std::default_delete<expr::operation> > > > const&) /home/smarchi/src/binutils-gdb/gdb/expression.h:136
        #19 0x563f70fe6bba in expr::var_value_operation::evaluate_funcall(type*, expression*, noside, std::__debug::vector<std::unique_ptr<expr::operation, std::default_delete<expr::operation> >, std::allocator<std::unique_ptr<expr::operation, std::default_delete<expr::operation> > > > const&) /home/smarchi/src/binutils-gdb/gdb/eval.c:689
        #20 0x563f704b71dc in expr::funcall_operation::evaluate(type*, expression*, noside) /home/smarchi/src/binutils-gdb/gdb/expop.h:2219
        #21 0x563f70fe0f02 in expression::evaluate(type*, noside) /home/smarchi/src/binutils-gdb/gdb/eval.c:110
        #22 0x563f71b1373e in process_print_command_args /home/smarchi/src/binutils-gdb/gdb/printcmd.c:1319
        #23 0x563f71b1391b in print_command_1 /home/smarchi/src/binutils-gdb/gdb/printcmd.c:1332
        #24 0x563f71b147ec in print_command /home/smarchi/src/binutils-gdb/gdb/printcmd.c:1465
        #25 0x563f706029b8 in do_simple_func /home/smarchi/src/binutils-gdb/gdb/cli/cli-decode.c:95
        #26 0x563f7061972a in cmd_func(cmd_list_element*, char const*, int) /home/smarchi/src/binutils-gdb/gdb/cli/cli-decode.c:2735
        #27 0x563f7262d0ef in execute_command(char const*, int) /home/smarchi/src/binutils-gdb/gdb/top.c:572
        #28 0x563f7100ed9c in command_handler(char const*) /home/smarchi/src/binutils-gdb/gdb/event-top.c:543
        #29 0x563f7101014b in command_line_handler(std::unique_ptr<char, gdb::xfree_deleter<char> >&&) /home/smarchi/src/binutils-gdb/gdb/event-top.c:779
        #30 0x563f72777942 in tui_command_line_handler /home/smarchi/src/binutils-gdb/gdb/tui/tui-interp.c:104
        #31 0x563f7100d059 in gdb_rl_callback_handler /home/smarchi/src/binutils-gdb/gdb/event-top.c:250
        #32 0x7f5a80418246 in rl_callback_read_char (/usr/lib/libreadline.so.8+0x3b246) (BuildId: 092e91fc4361b0ef94561e3ae03a75f69398acbb)
        #33 0x563f7100ca06 in gdb_rl_callback_read_char_wrapper_noexcept /home/smarchi/src/binutils-gdb/gdb/event-top.c:192
        #34 0x563f7100cc5e in gdb_rl_callback_read_char_wrapper /home/smarchi/src/binutils-gdb/gdb/event-top.c:225
        #35 0x563f728c70db in stdin_event_handler /home/smarchi/src/binutils-gdb/gdb/ui.c:155
        #36 0x563f72fccb6d in handle_file_event /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:573
        #37 0x563f72fcd503 in gdb_wait_for_event /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:694
        #38 0x563f72fcb15c in gdb_do_one_event(int) /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:264
        #39 0x563f7177ec1c in start_event_loop /home/smarchi/src/binutils-gdb/gdb/main.c:412
        #40 0x563f7177f12e in captured_command_loop /home/smarchi/src/binutils-gdb/gdb/main.c:476
        #41 0x563f717846e4 in captured_main /home/smarchi/src/binutils-gdb/gdb/main.c:1320
        #42 0x563f71784821 in gdb_main(captured_main_args*) /home/smarchi/src/binutils-gdb/gdb/main.c:1339
        #43 0x563f6fcedfbd in main /home/smarchi/src/binutils-gdb/gdb/gdb.c:32
        #44 0x7f5a7e43984f  (/usr/lib/libc.so.6+0x2384f) (BuildId: 2f005a79cd1a8e385972f5a102f16adba414d75e)
        #45 0x7f5a7e439909 in __libc_start_main (/usr/lib/libc.so.6+0x23909) (BuildId: 2f005a79cd1a8e385972f5a102f16adba414d75e)
        #46 0x563f6fcedd84 in _start (/home/smarchi/build/binutils-gdb/gdb/gdb+0xafb0d84) (BuildId: 50bd32e6e9d5e84543e9897b8faca34858ca3995)

    0x611000034980 is located 0 bytes inside of 208-byte region [0x611000034980,0x611000034a50)
    freed by thread T0 here:
        #0 0x7f5a7fce312a in operator delete(void*, unsigned long) /usr/src/debug/gcc/gcc/libsanitizer/asan/asan_new_delete.cpp:164
        #1 0x563f702bd1fa in momentary_breakpoint::~momentary_breakpoint() /home/smarchi/src/binutils-gdb/gdb/breakpoint.c:304
        #2 0x563f702771c5 in delete_breakpoint(breakpoint*) /home/smarchi/src/binutils-gdb/gdb/breakpoint.c:12404
        #3 0x563f702150a7 in check_longjmp_breakpoint_for_call_dummy(thread_info*) /home/smarchi/src/binutils-gdb/gdb/breakpoint.c:7673
        #4 0x563f714567b1 in process_event_stop_test /home/smarchi/src/binutils-gdb/gdb/infrun.c:6881
        #5 0x563f71454e07 in handle_signal_stop /home/smarchi/src/binutils-gdb/gdb/infrun.c:6769
        #6 0x563f7144b680 in handle_inferior_event /home/smarchi/src/binutils-gdb/gdb/infrun.c:6023
        #7 0x563f71436165 in fetch_inferior_event() /home/smarchi/src/binutils-gdb/gdb/infrun.c:4387
        #8 0x563f7136ff51 in inferior_event_handler(inferior_event_type) /home/smarchi/src/binutils-gdb/gdb/inf-loop.c:42
        #9 0x563f7168038d in handle_target_event /home/smarchi/src/binutils-gdb/gdb/linux-nat.c:4219
        #10 0x563f72fccb6d in handle_file_event /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:573
        #11 0x563f72fcd503 in gdb_wait_for_event /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:694
        #12 0x563f72fcaf2b in gdb_do_one_event(int) /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:217
        #13 0x563f7262b9bb in wait_sync_command_done() /home/smarchi/src/binutils-gdb/gdb/top.c:426
        #14 0x563f7137a7c3 in run_inferior_call /home/smarchi/src/binutils-gdb/gdb/infcall.c:650
        #15 0x563f71381295 in call_function_by_hand_dummy(value*, type*, gdb::array_view<value*>, void (*)(void*, int), void*) /home/smarchi/src/binutils-gdb/gdb/infcall.c:1332
        #16 0x563f7137c0e2 in call_function_by_hand(value*, type*, gdb::array_view<value*>) /home/smarchi/src/binutils-gdb/gdb/infcall.c:780
        #17 0x563f70fe5960 in evaluate_subexp_do_call(expression*, noside, value*, gdb::array_view<value*>, char const*, type*) /home/smarchi/src/binutils-gdb/gdb/eval.c:649
        #18 0x563f70fe6617 in expr::operation::evaluate_funcall(type*, expression*, noside, char const*, std::__debug::vector<std::unique_ptr<expr::operation, std::default_delete<expr::operation> >, std::allocator<std::unique_ptr<expr::operation, std::default_delete<expr::operation> > > > const&) /home/smarchi/src/binutils-gdb/gdb/eval.c:677
        #19 0x563f6fd19668 in expr::operation::evaluate_funcall(type*, expression*, noside, std::__debug::vector<std::unique_ptr<expr::operation, std::default_delete<expr::operation> >, std::allocator<std::unique_ptr<expr::operation, std::default_delete<expr::operation> > > > const&) /home/smarchi/src/binutils-gdb/gdb/expression.h:136
        #20 0x563f70fe6bba in expr::var_value_operation::evaluate_funcall(type*, expression*, noside, std::__debug::vector<std::unique_ptr<expr::operation, std::default_delete<expr::operation> >, std::allocator<std::unique_ptr<expr::operation, std::default_delete<expr::operation> > > > const&) /home/smarchi/src/binutils-gdb/gdb/eval.c:689
        #21 0x563f704b71dc in expr::funcall_operation::evaluate(type*, expression*, noside) /home/smarchi/src/binutils-gdb/gdb/expop.h:2219
        #22 0x563f70fe0f02 in expression::evaluate(type*, noside) /home/smarchi/src/binutils-gdb/gdb/eval.c:110
        #23 0x563f71b1373e in process_print_command_args /home/smarchi/src/binutils-gdb/gdb/printcmd.c:1319
        #24 0x563f71b1391b in print_command_1 /home/smarchi/src/binutils-gdb/gdb/printcmd.c:1332
        #25 0x563f71b147ec in print_command /home/smarchi/src/binutils-gdb/gdb/printcmd.c:1465
        #26 0x563f706029b8 in do_simple_func /home/smarchi/src/binutils-gdb/gdb/cli/cli-decode.c:95
        #27 0x563f7061972a in cmd_func(cmd_list_element*, char const*, int) /home/smarchi/src/binutils-gdb/gdb/cli/cli-decode.c:2735
        #28 0x563f7262d0ef in execute_command(char const*, int) /home/smarchi/src/binutils-gdb/gdb/top.c:572
        #29 0x563f7100ed9c in command_handler(char const*) /home/smarchi/src/binutils-gdb/gdb/event-top.c:543

    previously allocated by thread T0 here:
        #0 0x7f5a7fce2012 in operator new(unsigned long) /usr/src/debug/gcc/gcc/libsanitizer/asan/asan_new_delete.cpp:95
        #1 0x563f7029a9a3 in new_momentary_breakpoint<program_space*&, frame_id&, int&> /home/smarchi/src/binutils-gdb/gdb/breakpoint.c:8129
        #2 0x563f702212f6 in momentary_breakpoint_from_master /home/smarchi/src/binutils-gdb/gdb/breakpoint.c:8169
        #3 0x563f70212db1 in set_longjmp_breakpoint_for_call_dummy() /home/smarchi/src/binutils-gdb/gdb/breakpoint.c:7582
        #4 0x563f713804db in call_function_by_hand_dummy(value*, type*, gdb::array_view<value*>, void (*)(void*, int), void*) /home/smarchi/src/binutils-gdb/gdb/infcall.c:1260
        #5 0x563f7137c0e2 in call_function_by_hand(value*, type*, gdb::array_view<value*>) /home/smarchi/src/binutils-gdb/gdb/infcall.c:780
        #6 0x563f70fe5960 in evaluate_subexp_do_call(expression*, noside, value*, gdb::array_view<value*>, char const*, type*) /home/smarchi/src/binutils-gdb/gdb/eval.c:649
        #7 0x563f70fe6617 in expr::operation::evaluate_funcall(type*, expression*, noside, char const*, std::__debug::vector<std::unique_ptr<expr::operation, std::default_delete<expr::operation> >, std::allocator<std::unique_ptr<expr::operation, std::default_delete<expr::operation> > > > const&) /home/smarchi/src/binutils-gdb/gdb/eval.c:677
        #8 0x563f6fd19668 in expr::operation::evaluate_funcall(type*, expression*, noside, std::__debug::vector<std::unique_ptr<expr::operation, std::default_delete<expr::operation> >, std::allocator<std::unique_ptr<expr::operation, std::default_delete<expr::operation> > > > const&) /home/smarchi/src/binutils-gdb/gdb/expression.h:136
        #9 0x563f70fe6bba in expr::var_value_operation::evaluate_funcall(type*, expression*, noside, std::__debug::vector<std::unique_ptr<expr::operation, std::default_delete<expr::operation> >, std::allocator<std::unique_ptr<expr::operation, std::default_delete<expr::operation> > > > const&) /home/smarchi/src/binutils-gdb/gdb/eval.c:689
        #10 0x563f704b71dc in expr::funcall_operation::evaluate(type*, expression*, noside) /home/smarchi/src/binutils-gdb/gdb/expop.h:2219
        #11 0x563f70fe0f02 in expression::evaluate(type*, noside) /home/smarchi/src/binutils-gdb/gdb/eval.c:110
        #12 0x563f71b1373e in process_print_command_args /home/smarchi/src/binutils-gdb/gdb/printcmd.c:1319
        #13 0x563f71b1391b in print_command_1 /home/smarchi/src/binutils-gdb/gdb/printcmd.c:1332
        #14 0x563f71b147ec in print_command /home/smarchi/src/binutils-gdb/gdb/printcmd.c:1465
        #15 0x563f706029b8 in do_simple_func /home/smarchi/src/binutils-gdb/gdb/cli/cli-decode.c:95
        #16 0x563f7061972a in cmd_func(cmd_list_element*, char const*, int) /home/smarchi/src/binutils-gdb/gdb/cli/cli-decode.c:2735
        #17 0x563f7262d0ef in execute_command(char const*, int) /home/smarchi/src/binutils-gdb/gdb/top.c:572
        #18 0x563f7100ed9c in command_handler(char const*) /home/smarchi/src/binutils-gdb/gdb/event-top.c:543
        #19 0x563f7101014b in command_line_handler(std::unique_ptr<char, gdb::xfree_deleter<char> >&&) /home/smarchi/src/binutils-gdb/gdb/event-top.c:779
        #20 0x563f72777942 in tui_command_line_handler /home/smarchi/src/binutils-gdb/gdb/tui/tui-interp.c:104
        #21 0x563f7100d059 in gdb_rl_callback_handler /home/smarchi/src/binutils-gdb/gdb/event-top.c:250
        #22 0x7f5a80418246 in rl_callback_read_char (/usr/lib/libreadline.so.8+0x3b246) (BuildId: 092e91fc4361b0ef94561e3ae03a75f69398acbb)

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

Correct a spelling mistake in the binutils README file.