Automatic date update in version.in

Stop the BFD library complaining about compressed dwarf debug string sections being too big.

PR 28834
* dwarf2.c (read_section): Change the heuristic that checks for
overlarge dwarf debug info sections.

gdb: fix formatting for help set/show extended-prompt

The formatting of the help text for 'help set extended-prompt' and
'help show extended-prompt' is a little off.

Here's the offending snippet:

    Substitutions are applied to VALUE to compute the real prompt.

    The currently defined substitutions are:
      \[ Begins a sequence of non-printing characters.
  \\ A backslash.
  \] Ends a sequence of non-printing characters.
  \e The ESC character.

Notice that the line for '\[' is indented more that the others.

Turns out this is due to how we build this help text, something which
is done in Python.  We extended a classes __doc__ string with some
dynamically generated text.

The classes doc string looks like this:

    """Set the extended prompt.

    Usage: set extended-prompt VALUE

    Substitutions are applied to VALUE to compute the real prompt.

    The currently defined substitutions are:
    """

Notice the closing """ are in a line of their own, and include some
white space just before.  It's this extra white space that's causing
the problem.

Fix the formatting issue by moving the """ to the end of the previous
line.  I then add the extra newline in at the point where the doc
string is merged with the dynamically generated text.

Now everything lines up correctly.

gdb: test to check one aspect of the linespec parsing code

While working on the fix for PR cli/28665 (see previous couple of
commits), I was playing with making a change in the linespec parsing
code.  Specifically, I was thinking about whether the spec_string for
LINESPEC_LOCATION locations should ever be nullptr.

I made a change to prevent the spec_string from ever being nullptr,
tested gdb, and saw no regressions.

However, as part of this work I was reviewing how the breakpoint code
handles this case (spec_string being nullptr), and spotted that in
parse_breakpoint_sals the nullptr case is specifically handled, so
changing this should have caused a regression.  But I didn't see one.

So, this commit adds a comment in location.c mentioning that the
nullptr case is (a) not an oversight, and (b) is required.  Then I add
a new test to gdb.base/break.exp that ensures a change in this area
will cause a regression.

This test passes on current gdb, but with my modified (and broken)
gdb, the test would fail.

gdb: handle calls to edit command passing only a linespec condition

While working on the previous commit to fix PR cli/28665, I noticed
that the 'edit' command would suffer from the same problem.  That is,
something like:

  (gdb) edit task 123

would cause GDB to break.  For a full explanation of what's going on
here, see the commit message for the previous commit.

As with the previous commit, this issue can be prevented by detecting,
and throwing, a junk at the end of the line error earlier, before
calling decode_line_1.

So, that's what this commit does.  I've also added some tests for this
issue.

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

gdb: handle calls to list command passing only a linespec condition

In PR cli/28665, it was reported that GDB would crash when given a
command like:

  (gdb) list task 123

The problem here is that in cli/cli-cmd.c:list_command, the string
'task 123' is passed to string_to_event_location in find a location
specification.  However, this location parsing understands about
breakpoint conditions, and so, will stop parsing when it sees
something that looks like a condition, in this case, the 'task 123'
looks like a breakpoint condition.

As a result, the location we get back from string_to_event_location
has no actual location specification attached to it.  The actual call
path is:

  list_command
    string_to_event_location
      string_to_event_location_basic
        new_linespec_location

In new_linespec_location we call linespec_lex_to_end, which looks at
'task 123' and decides that there's nothing there that describes a
location.  As such, in new_linespec_location, the spec_string field of
the location is left as nullptr.

Back in list_command we then call decode_line_1, which calls
event_location_to_sals, which calls parse_linespec, which takes the
spec_string we found earlier, and tries to converts this into a list
of sals.

However, parse_linespec is not intended to be passed a nullptr, for
example, calling is_ada_operator will try to access through the
nullptr, causing undefined behaviour.  But there are other cases
within parse_linespec which don't expect to see a nullptr.

When looking at how to fix this issue, I first considered having
linespec_lex_to_end detect the problem.  That function understands
when the first thing in the linespec is a condition keyword, and so,
could throw an error saying something like: "no linespec before
condition keyword", however, this is not going to work, at least, not
without additional changes to GDB, it is valid to place a breakpoint
like:

  (gdb) break task 123

This will place a breakpoint at the current location with the
condition 'task 123', and changing linespec_lex_to_end breaks this
behaviour.

So, next, I considered what would happen if I added a condition to an
otherwise valid list command, this is what I see:

  (gdb) list file.c:1 task 123
  Junk at end of line specification.
  (gdb)

So, then I wondered, could we just pull the "Junk" detection forward,
so that we throw the error earlier, before we call decode_line_1?

It turns out that yes we can.  Well, sort of.

It is simpler, I think, to add a separate check into the list_command
function, after calling string_to_event_location, but before calling
decode_line_1.  We know when we call string_to_event_location that the
string in question is not empty, so, after calling
string_to_event_location, if non of the string has been consumed, then
the content of the string must be junk - it clearly doesn't look like
a location specification.

I've reused the same "Junk at end of line specification." error for
consistency, and added a few tests to cover this issue.

While the first version of this patch was on the mailing list, a
second bug PR gdb/28797 was raised.  This was for a very similar
issue, but this time the problem command was:

  (gdb) list ,,

Here the list command understands about the first comma, list can have
two arguments separated by a comma, and the first argument can be
missing.  So we end up trying to parse the second command "," as a
linespec.

However, in linespec_lex_to_end, we will stop parsing a linespec at a
comma, so, in the above case we end up with an empty linespec (between
the two commas), and, like above, this results in the spec_string
being nullptr.

As with the previous case, I've resolved this issue by adding an extra
check for junk at the end of the line - after parsing (or failing to
parse) the nothing between the two commas, we still have the "," left
at the end of the list command line - when we see this we can throw
the same "junk at the end of the line" error, and all is good.

I've added tests for this case too.

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

gdb/testsuite: move linespec test into gdb.linespec/ directory

The gdb.base/linespecs.exp test should really live in the gdb.linespec
directory, so lets move it there.

As we already have gdb.linespec/linespec.exp, I've renamed the test to
gdb.linespec/errors.exp, as this better reflects what the test is
actually checking.

Finally, the test script doesn't have its own source file, it was
reusing a random other source file, gdb.base/memattr.c.  Now the tests
script is in gdb.linespec/, I've updated the test to use a different
source file from that directory.

gdb: add empty string check in parse_linespec

If parse_linespec (linespec.c) is passed ARG as an empty string then
we end up calling `strchr (linespec_quote_characters, '\0')`, which
will return a pointer to the '\0' at the end of
linespec_quote_characters.  This then results in GDB calling
skip_quote_char with `ARG + 1`, which is undefined behaviour (as ARG
only contained a single character, the '\0').

Fix this by checking for the first character of ARG being '\0' before
the call to strchr.

I have additionally added an assertion that ARG can't itself be
nullptr, as calling is_ada_operator with nullptr can end up calling
'startswith' on the nullptr, which is undefined behaviour.

Finally, I moved the declaration of TOKEN into the body of
parse_linespec, to where TOKEN is defined.

This patch came about while I was working on fixes for PR cli/28665
and PR gdb/28797.  The actual fixes for these two issues will be in a
later commit in this series, but, with this patch in place, both of
the above bugs would hit the new assertion rather than accessing
invalid memory and crashing.  The '\0' check is not currently ever
hit, but just makes the code a little safer.

Because this patch only changes the nature of the failure for the
above two bugs, there's no tests here.  A later commit will fix the
above two issues, at which point I'll add some tests.

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

gdb: update the comment on string_to_event_location

The comment on string_to_event_location is (I believe) out of date.
This commit fixes the two issues I see:

  1. This function can't return NULL any more.  The implementation
  calls string_to_explicit_location which can return NULL, but if this
  is the case we then call string_to_event_location_basic, which I
  don't believe can ever return NULL.

  2. I've removed the mention that the returned string is malloc'd,
  though this is true, now that we return a managed pointer, I believe
  the source of the memory allocation is irrelevant, and so, shouldn't
  be discussed in the header comment.

There should be no user visible changes after this commit.

Updated French translation for the ld/ and gold/ sub-directories

or1k: Avoid R_OR1K_GOT16 signed overflow by using special howto

Previously when fixing PR 21464 we masked out upper bits of the
relocation value in order to avoid overflow complaints when acceptable.
It turns out this does not work when the relocation value ends up being
signed.

To fix this this patch introduces a special howto with
complain_on_overflow set to complain_overflow_dont.  This is used in
place of the normal R_OR1K_GOT16 howto when we detect R_OR1K_GOT_AHI16
relocations.

bfd/ChangeLog:

PR 28735
* elf32-or1k.c (or1k_elf_got16_no_overflow_howto): Define.
(or1k_elf_relocate_section): Use new howto instead of trying to
mask out relocation bits.

Automatic date update in version.in

Fix flex rule in gdb

Currently, if flex fails, it will leave the resulting .c file in the
tree.  This will cause a cascade of errors, and requires the manual
deletion of the .c file in order to recreate the problem.

It's better for the rule to fail such that the .c file is not updated.
This way, 'make' will fail the same way every time -- which is much
handier for debugging syntax errors.

This fix just updates the Makefile rule to follow the way that the
"yacc" rule already works.

gdb, btrace: improve error messages

When trying to use 'record btrace' on a system that does not support it,
the error message isn't as clear as it could be.  See
https://sourceware.org/pipermail/gdb/2022-January/049870.html.

Improve the error message in a few cases.

Reported-by: Simon Sobisch <simonsobisch@gnu.org>

gdb/python: fix gdb.Objfile.__repr__ () for dynamically compiled code

While experimenting with JIT reader API I realized that calling repr ()
on objfile created by JIT reader crashes GDB.

The problem was that objfpy_repr () called objfile_filename () which
returned NULL, causing PyString_FromFormat () to crash.

This commit fixes this problem by using objfile_name () instead of
objfile_filename (). This also makes consistent with the value of gdb.Objfile.filename variable.

hurd: Fix RPC prototypes

The last updates of MIG introduced qualifying strings and arrays with
const as appropriate.  We thus have to update the protypes in gdb too.

Change-Id: I3f72aac1dfa6e58d1394d5776b822d7c8f2409df

hurd: Fix RPC link names

The RPC stub code expects to be calling a C function, not a C++
function.

Change-Id: Idd7549fc118f2addc7fb4975667a011cacacc03f

Automatic date update in version.in

elf: Check symbol version without any symbols

VER_FLG_WEAK doesn't indicate that all symbol references of the symbol
version have STB_WEAK.  VER_FLG_WEAK indicates a weak symbol version
definition with no symbols associated with it.  It is used to verify
the existence of a particular implementation without any symbol references
to the weak symbol version.

PR ld/24718
* testsuite/ld-elf/pr24718-1.d: New file.
* testsuite/ld-elf/pr24718-1.s: Likewise.
* testsuite/ld-elf/pr24718-1.t: Likewise.

Load debug section only when dumping debug sections

Don't load debug sections if we aren't dumping any debug sections.

PR binutils/28843
* objdump.c (dump_any_debugging): New.
(load_debug_section): Return false if dump_any_debugging isn't
set.
(main): Set dump_any_debugging when dumping any debug sections.
* readelf (dump_any_debugging): New.
(parse_args): Set dump_any_debugging when dumping any debug
sections.
(load_debug_section): Return false if dump_any_debugging isn't
set.

gdb: fix some clang-tidy readability-misleading-indentation warnings

I have warnings like these showing in my editor all the time, so I
thought I'd run clang-tidy with this diagnostic on all the files (that I
can compile) and fix them.

There is still one warning, in utils.c, but that's because some code
is mixed up with preprocessor macros (#ifdef TUI), so I think there no
good solution there.

Change-Id: I345175fc7dd865318f0fbe61ac026c88c3b6a96b

gdb, testsuite, fortran: adapt info symbol expected output for intel compilers

Info symbol is expected to print the symbol table name of a symbol, since
symbol lookup happens via the minimal symbol table.  This name
corresponds to the linkage name in the full symbol table.

For gfortran (and maybe others) these names currently have the form
XXXX.NUMBER where XXXX is the symbol name and NUMBER a compiler
generated appendix for mangling.
An example taken from the modified nested-funcs-2.exp would be

~~~~
$ objdump -t ./outputs/gdb.fortran/nested-funcs-2/nested-funcs-2 | grep \
increment
00000000000014ab l  F .text  0000000000000095  increment.3883
000000000000141c l  F .text  000000000000008f  increment_program_global.3881
~~~~

This mangled name gets recognized by the Ada demangler/decoder and decoded as
Ada to XXXX (setting the symbol language to Ada).  This leads to output
of XXXX over XXXX.NUMBER for info symbol on gfortran symbols.

For ifort and ifx the generated linkage names have the form
SCOPEA_SCOPEB_XXXX_ which are not recognized by the Ada decoder (or any
other demangler for that matter) and thus printed as is.
The respective objdump in the above case looks like

~~~~
$ objdump -t ./outputs/gdb.fortran/nested-funcs-2/nested-funcs-2 | grep \
increment
0000000000403a44 l  F .text  0000000000000074  contains_keyword_IP_increment_
0000000000403ab8 l  F .text  0000000000000070
contains_keyword_IP_increment_program_global_
~~~~

In the unmodified testcase this results in 'fails' when ran with the intel
compilers:

~~~~
>> make check RUNTESTFLAGS="gdb.fortran/nested-funcs-2.exp \
GDBFLAGS='$GDBFLAGS' CC_FOR_TARGET='icpc' F90_FOR_TARGET='ifort'"

...

                === gdb Summary ===

\# of expected passes            80
\# of unexpected failures        14
~~~~

Note that there is no Fortran mangling standard.  We keep the gfortran
behavior as is and modify the test to reflect ifx and ifort mangled
names which fixes above fails.

Signed-off-by: Nils-Christian Kempke <nils-christian.kempke@intel.com>

Import patch from mainline GCC to fix an infinite recusion in the Rust demangler.

PR 98886
PR 99935
* rust-demangle.c (struct rust_demangler): Add a recursion
counter.
(demangle_path): Increment/decrement the recursion counter upon
entry and exit.  Fail if the counter exceeds a fixed limit.
(demangle_type): Likewise.
(rust_demangle_callback): Initialise the recursion counter,
disabling if requested by the option flags.

Re: PR28827, assertion building LLVM 9 on powerpc64le-linux-gnu

In trying to find a testcase for PR28827, I managed to hit a linker
error in bfd_set_section_contents with a .branch_lt input section
being too large for the output .branch_lt.

bfd/
PR 28827
* elf64-ppc.c (ppc64_elf_size_stubs): Set section size to
maxsize past STUB_SHRINK_ITER before laying out.  Remove now
unnecessary conditional setting of maxsize at start of loop.
ld/
* testsuite/ld-powerpc/pr28827-2.d,
* testsuite/ld-powerpc/pr28827-2.lnk,
* testsuite/ld-powerpc/pr28827-2.s: New test.
* testsuite/ld-powerpc/powerpc.exp: Run it.

Remove unused variables in fbsd-tdep.c files

i386-fbsd-tdep.c and amd64-fbsd-tdep.c failed to build on my x86-64
Fedora 34 machine, using the system gcc, after a recent patch.  These
two files now have unused variables, which provokes a warning in this
configuration.

I'm checking in this patch to remove the unused variables.

Automatic date update in version.in

Automatic date update in version.in

Re: PR28827, assertion building LLVM 9 on powerpc64le-linux-gnu

The previous patch wasn't quite correct.  The size and padding depends
on offset used in the current iteration, and if we're fudging the
offset past STUB_SHRINK_ITER then we'd better use that offset.  We
can't have plt_stub_pad using stub_sec->size as the offset.

PR 28827
* elf64-ppc.c (plt_stub_pad): Add stub_off param.
(ppc_size_one_stub): Set up stub_offset to value used in this
iteration before sizing the stub.  Adjust plt_stub_pad calls.

objcopy --only-keep-debug

From: Peilin Ye <peilin.ye@bytedance.com>
objcopy's --only-keep-debug option has been broken for ELF files since
commit 8c803a2dd7d3.

  1. binutils/objcopy.c:setup_section() marks non-debug sections as
     SHT_NOBITS, then calls bfd_copy_private_section_data();
  2. If ISEC and OSEC share the same section flags,
     bfd/elf.c:_bfd_elf_init_private_section_data() restores OSEC's
     section type back to ISEC's section type, effectively undoing
     "make_nobits".

* objcopy.c (setup_section): Act on make_nobits after calling
bfd_copy_private_section_data.

Automatic date update in version.in

gdb: fix ppc-sysv-tdep.c build on 32-bit platforms

The previous code triggered the following error on an i386 host:

/git/gdb/gdb/ppc-sysv-tdep.c:1764:34: error: non-constant-expression cannot be narrowed from type 'ULONGEST' (aka 'unsigned long long') to 'size_t' (aka 'unsigned int') in initializer list [-Wc++11-narrowing]
              unscaled.read ({writebuf, TYPE_LENGTH (valtype)},
                                        ^~~~~~~~~~~~~~~~~~~~~
/git/gdb/gdb/gdbtypes.h:2043:31: note: expanded from macro 'TYPE_LENGTH'
                              ^~~~~~~~~~~~~~~~~~
/git/gdb/gdb/ppc-sysv-tdep.c:1764:34: note: insert an explicit cast to silence this issue
              unscaled.read ({writebuf, TYPE_LENGTH (valtype)},
                                        ^~~~~~~~~~~~~~~~~~~~~
                                        static_cast<size_t>( )
/git/gdb/gdb/gdbtypes.h:2043:31: note: expanded from macro 'TYPE_LENGTH'
                              ^~~~~~~~~~~~~~~~~~
1 error generated.

Fix this by using gdb::make_array_view.

FreeBSD x86 nat: Use register maps for GP register sets.

Rather than using the x86-specific register offset tables, use
register maps to describe the layout of the general purpose registers
fetched via PT_GETREGS.  The sole user-visible difference is that
FreeBSD/amd64 will now report additional segment registers ($ds, $es,
$fs, and $gs) for both 32-bit and 64-bit processes.

As part of these changes, the FreeBSD x86 native targets no longer use
amd64-bsd-nat.c or i386-bsd-nat.c.  Remove FreeBSD-specific register
handling (for $fs_base, $gs_base, and XSAVE state) from these files.
Similarly, remove the global x86bsd_xsave_len from x86-bsd-nat.c.  The
FreeBSD x86 native targets use a static xsave_len instead.

While here, rework the probing of PT_GETXMMREGS on FreeBSD/i386.
Probe the ptrace op once in the target read_description method and
cache the result for the future similar to the way the status of XSAVE
support is probed in the read_description method.  In addition, return
the proper xcr0 mask (X87-only) for old kernels or systems without
either XSAVE or XMM support.

fbsd-nat: Return a bool from fetch_register_set and store_register_set.

Change these helper functions to return true if they did any work.

FreeBSD x86: Use tramp-frame for signal frames.

Use a register map to describe the registers in mcontext_t as part of
the signal frame as is done on several other FreeBSD arches.  This
permits fetching the fsbase and gsbase register values from the signal
frame for both amd64 and i386 and permits fetching additional segment
registers stored as 16-bit values on amd64.

While signal frames on FreeBSD do contain floating point/XSAVE state,
these unwinders do not attempt to supply those registers.  The
existing x86 signal frame uwinders do not support these registers, and
the only existing functions which handle FSAVE/FXSAVE/XSAVE state all
work with regcaches.  In the future these unwinders could create a
tempory regcache, collect floating point registers, and then supply
values out of the regcache into the trad-frame.

Use register maps for gp regsets on FreeBSD/x86 core dumps.

In particular, this permits reporting the value of the $ds, $es, $fs,
and $gs segment registers from amd64 core dumps since they are stored
as 16-bit values rather than the 32-bit size assumed by i386_gregset.

regcache: Zero-extend small registers described by a register map.

When registers are supplied via regcache_supply_register from a
register block described by a register map, registers may be stored in
slots smaller than GDB's native register size (e.g. x86 segment
registers are 16 bits, but the GDB registers for those are 32-bits).
regcache_collect_regset is careful to zero-extend slots larger than a
register size, but regcache_supply_regset just used
regcache::raw_supply_part and did not initialize the upper bytes of a
register value.

trad_frame_set_reg_regmap assumes these semantics (zero-extending
short registers).  Upcoming patches also require these semantics for
handling x86 segment register values stored in 16-bit slots on
FreeBSD.  Note that architecturally x86 segment registers are 16 bits,
but the x86 gdb architectures treat these registers as 32 bits.

FreeBSD x86: Remove fallback for detecting signal trampolines by address.

A few FreeBSD releases did not include the page holding the signal
code in core dumps.  As a workaround, a sysctl was used to fetch the
default location of the signal code instead.  The youngest affected
FreeBSD release is 10.1 released in November 2014 and EOLed in
December 2016.  The fallback only works for native processes and would
require a separate unwinder once the FreeBSD arches are converted to
use tramp_frame for signal frames.

Remove support for pre-5.0 FreeBSD/i386 signal trampolines.

The last relevant release (FreeBSD 4.11) was released in January of
2005.

Remove vestigal FreeBSD/i386 3.x support.

This was orphaned when a.out support was removed as the FreeBSD/i386
ELF support always used the register layouts from 4.0+.

Add Bruno Larsen to gdb/MAINTAINERS

gdb/build: Fix Wpessimizing-move in clang build

When building with clang, I run into an error:

...
tui/tui-disasm.c:138:25: error: moving a temporary object prevents copy
elision [-Werror,-Wpessimizing-move]
      tal.addr_string = std::move (gdb_dis_out.release ());
                        ^
tui/tui-disasm.c:138:25: note: remove std::move call here
      tal.addr_string = std::move (gdb_dis_out.release ());
                        ^~~~~~~~~~~                      ~
...

The error above is caused by the recent commit 5d10a2041eb8 ("gdb: add
string_file::release method").

Fix this by removing std::move.

Build on x86_64-linux with clang 13.0.0.

Add top-level .editorconfig file

Add a .editorconfig [1] file.  This helps configure editors
automatically with the right whitespace settings.  It will help me,
since I need to juggle with different whitespace settings for different
projects.   But I think it can also help newcomers get things right from
the start.

Some editors have native support for reading these files, while others
require a plug-in [2].  And if you don't want to use it, then this file
doesn't change anything to your life.

I added rules for the kinds of files I edit most often, but more can be
added later.  I assumed that the rules were the same for GDB and the
other projects, but if that's not the case, we can always put
.editorconfig files in project subdirectories to override settings.

[1] https://editorconfig.org/
[2] https://editorconfig.org/#download

Change-Id: Ifda136d13877fafcf0d137fec8501f6a34e1367b

Updated French translation for the gas sub-directory.

Set __ehdr_start rel_from_abs earlier

This is just a tidy, making the __ehdr_start symbol flag tweaks all in
one place.

* ldelf.c (ldelf_before_allocation): Don't set rel_from_abs
for __ehdr_start.
* ldlang.c (lang_symbol_tweaks): Set it here instead.

PowerPC64 handling of @tocbase

* elf64-ppc.c (ppc64_elf_relocate_section): Warn if the symbol
on R_PPC64_TOC isn't local.

Update PowerPC64 symtocbase test

Using a symbol other than .TOC. with @tocbase is an extension to the
ABI.  It is never valid to use a symbol without a definition in the
binary, and symbols on these expressions cannot be overridden.  Make
this explicit by using ".hidden" in the testcase.

* testsuite/ld-powerpc/symtocbase-1.s: Align data.  Make function
entry symbol hidden.
* testsuite/ld-powerpc/symtocbase-2.s: Likewise.
* testsuite/ld-powerpc/symtocbase.d: Adjust expected output.

PR28827, assertion building LLVM 9 on powerpc64le-linux-gnu

The assertion is this one in ppc_build_one_stub
  BFD_ASSERT (stub_entry->stub_offset >= stub_entry->group->stub_sec->size);
It is checking that a stub doesn't overwrite the tail of a previous
stub, so not something trivial.

Normally, stub sizing iterates until no stubs are added, detected by
no change in stub section size.  Iteration also continues if no stubs
are added but one or more stubs increases in size, which also can be
detected by a change in stub section size.  But there is a
pathological case where stub section sizing decreases one iteration
then increases the next.  To handle that situation, stub sizing also
stops at more than STUB_SHRINK_ITER (20) iterations when calculated
stub section size is smaller.  The previous larger size is kept for
the actual layout (so that building the stubs, which behaves like
another iteration of stub sizing, will see the stub section sizes
shrink).  The problem with that stopping condition is that it assumes
that stub sizing is only affected by addresses external to the stub
sections, which isn't always true.

This patch fixes that by also keeping larger individual stub_offset
addresses past STUB_SHRINK_ITER.  It also catches a further
pathological case where one stub shrinks and another expands in such a
way that no stub section size change is seen.

PR 28827
* elf64-ppc.c (struct ppc_link_hash_table): Add stub_changed.
(STUB_SHRINK_ITER): Move earlier in file.
(ppc_size_one_stub): Detect any change in stub_offset.  Keep
larger one if past STUB_SHRINK_ITER.
(ppc64_elf_size_stubs): Iterate on stub_changed too.

PR28826 x86_64 ld segfaults building xen

Fallout from commit e86fc4a5bc37

PR 28826
* coffgen.c (coff_write_alien_symbol): Init dummy to zeros.

PR28753, buffer overflow in read_section_stabs_debugging_info

PR 28753
* rddbg.c (read_section_stabs_debugging_info): Don't read past
end of section when concatentating stab strings.

Automatic date update in version.in

gdb: work around negative DW_AT_data_member_location GCC 11 bug

g++ 11.1.0 has a bug where it will emit a negative
DW_AT_data_member_location in some cases:

    $ cat test.cpp
    #include <memory>

    int
    main()
    {
      std::unique_ptr<int> ptr;
    }
    $ g++ -g test.cpp
    $ llvm-dwarfdump -F a.out
    ...
    0x00000964:       DW_TAG_member
                        DW_AT_name [DW_FORM_strp]   ("_M_head_impl")
                        DW_AT_decl_file [DW_FORM_data1]     ("/usr/include/c++/11.1.0/tuple")
                        DW_AT_decl_line [DW_FORM_data1]     (125)
                        DW_AT_decl_column [DW_FORM_data1]   (0x27)
                        DW_AT_type [DW_FORM_ref4]   (0x0000067a "default_delete<int>")
                        DW_AT_data_member_location [DW_FORM_sdata]  (-1)
    ...

This leads to a GDB crash (when built with ASan, otherwise probably
garbage results), since it tries to read just before (to the left, in
ASan speak) of the value's buffer:

    ==888645==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6020000c52af at pc 0x7f711b239f4b bp 0x7fff356bd470 sp 0x7fff356bcc18
    READ of size 1 at 0x6020000c52af thread T0
        #0 0x7f711b239f4a in __interceptor_memcpy /build/gcc/src/gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:827
        #1 0x555c4977efa1 in value_contents_copy_raw /home/simark/src/binutils-gdb/gdb/value.c:1347
        #2 0x555c497909cd in value_primitive_field(value*, long, int, type*) /home/simark/src/binutils-gdb/gdb/value.c:3126
        #3 0x555c478f2eaa in cp_print_value_fields(value*, ui_file*, int, value_print_options const*, type**, int) /home/simark/src/binutils-gdb/gdb/cp-valprint.c:333
        #4 0x555c478f63b2 in cp_print_value /home/simark/src/binutils-gdb/gdb/cp-valprint.c:513
        #5 0x555c478f02ca in cp_print_value_fields(value*, ui_file*, int, value_print_options const*, type**, int) /home/simark/src/binutils-gdb/gdb/cp-valprint.c:161
        #6 0x555c478f63b2 in cp_print_value /home/simark/src/binutils-gdb/gdb/cp-valprint.c:513
        #7 0x555c478f02ca in cp_print_value_fields(value*, ui_file*, int, value_print_options const*, type**, int) /home/simark/src/binutils-gdb/gdb/cp-valprint.c:161
        #8 0x555c478f63b2 in cp_print_value /home/simark/src/binutils-gdb/gdb/cp-valprint.c:513
        #9 0x555c478f02ca in cp_print_value_fields(value*, ui_file*, int, value_print_options const*, type**, int) /home/simark/src/binutils-gdb/gdb/cp-valprint.c:161
        #10 0x555c4760d45f in c_value_print_struct /home/simark/src/binutils-gdb/gdb/c-valprint.c:383
        #11 0x555c4760df4c in c_value_print_inner(value*, ui_file*, int, value_print_options const*) /home/simark/src/binutils-gdb/gdb/c-valprint.c:438
        #12 0x555c483ff9a7 in language_defn::value_print_inner(value*, ui_file*, int, value_print_options const*) const /home/simark/src/binutils-gdb/gdb/language.c:632
        #13 0x555c49758b68 in do_val_print /home/simark/src/binutils-gdb/gdb/valprint.c:1048
        #14 0x555c49759b17 in common_val_print(value*, ui_file*, int, value_print_options const*, language_defn const*) /home/simark/src/binutils-gdb/gdb/valprint.c:1151
        #15 0x555c478f2fcb in cp_print_value_fields(value*, ui_file*, int, value_print_options const*, type**, int) /home/simark/src/binutils-gdb/gdb/cp-valprint.c:335
        #16 0x555c478f63b2 in cp_print_value /home/simark/src/binutils-gdb/gdb/cp-valprint.c:513
        #17 0x555c478f02ca in cp_print_value_fields(value*, ui_file*, int, value_print_options const*, type**, int) /home/simark/src/binutils-gdb/gdb/cp-valprint.c:161
        #18 0x555c4760d45f in c_value_print_struct /home/simark/src/binutils-gdb/gdb/c-valprint.c:383
        #19 0x555c4760df4c in c_value_print_inner(value*, ui_file*, int, value_print_options const*) /home/simark/src/binutils-gdb/gdb/c-valprint.c:438
        #20 0x555c483ff9a7 in language_defn::value_print_inner(value*, ui_file*, int, value_print_options const*) const /home/simark/src/binutils-gdb/gdb/language.c:632
        #21 0x555c49758b68 in do_val_print /home/simark/src/binutils-gdb/gdb/valprint.c:1048
        #22 0x555c49759b17 in common_val_print(value*, ui_file*, int, value_print_options const*, language_defn const*) /home/simark/src/binutils-gdb/gdb/valprint.c:1151
        #23 0x555c478f2fcb in cp_print_value_fields(value*, ui_file*, int, value_print_options const*, type**, int) /home/simark/src/binutils-gdb/gdb/cp-valprint.c:335
        #24 0x555c4760d45f in c_value_print_struct /home/simark/src/binutils-gdb/gdb/c-valprint.c:383
        #25 0x555c4760df4c in c_value_print_inner(value*, ui_file*, int, value_print_options const*) /home/simark/src/binutils-gdb/gdb/c-valprint.c:438
        #26 0x555c483ff9a7 in language_defn::value_print_inner(value*, ui_file*, int, value_print_options const*) const /home/simark/src/binutils-gdb/gdb/language.c:632
        #27 0x555c49758b68 in do_val_print /home/simark/src/binutils-gdb/gdb/valprint.c:1048
        #28 0x555c49759b17 in common_val_print(value*, ui_file*, int, value_print_options const*, language_defn const*) /home/simark/src/binutils-gdb/gdb/valprint.c:1151
        #29 0x555c4760f04c in c_value_print(value*, ui_file*, value_print_options const*) /home/simark/src/binutils-gdb/gdb/c-valprint.c:587
        #30 0x555c483ff954 in language_defn::value_print(value*, ui_file*, value_print_options const*) const /home/simark/src/binutils-gdb/gdb/language.c:614
        #31 0x555c49759f61 in value_print(value*, ui_file*, value_print_options const*) /home/simark/src/binutils-gdb/gdb/valprint.c:1189
        #32 0x555c48950f70 in print_formatted /home/simark/src/binutils-gdb/gdb/printcmd.c:337
        #33 0x555c48958eda in print_value(value*, value_print_options const&) /home/simark/src/binutils-gdb/gdb/printcmd.c:1258
        #34 0x555c48959891 in print_command_1 /home/simark/src/binutils-gdb/gdb/printcmd.c:1367
        #35 0x555c4895a3df in print_command /home/simark/src/binutils-gdb/gdb/printcmd.c:1458
        #36 0x555c4767f974 in do_simple_func /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:97
        #37 0x555c47692e25 in cmd_func(cmd_list_element*, char const*, int) /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:2475
        #38 0x555c4936107e in execute_command(char const*, int) /home/simark/src/binutils-gdb/gdb/top.c:670
        #39 0x555c485f1bff in catch_command_errors /home/simark/src/binutils-gdb/gdb/main.c:523
        #40 0x555c485f249c in execute_cmdargs /home/simark/src/binutils-gdb/gdb/main.c:618
        #41 0x555c485f6677 in captured_main_1 /home/simark/src/binutils-gdb/gdb/main.c:1317
        #42 0x555c485f6c83 in captured_main /home/simark/src/binutils-gdb/gdb/main.c:1338
        #43 0x555c485f6d65 in gdb_main(captured_main_args*) /home/simark/src/binutils-gdb/gdb/main.c:1363
        #44 0x555c46e41ba8 in main /home/simark/src/binutils-gdb/gdb/gdb.c:32
        #45 0x7f71198bcb24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24)
        #46 0x555c46e4197d in _start (/home/simark/build/binutils-gdb-one-target/gdb/gdb+0x77f197d)

    0x6020000c52af is located 1 bytes to the left of 8-byte region [0x6020000c52b0,0x6020000c52b8)
    allocated by thread T0 here:
        #0 0x7f711b2b7459 in __interceptor_calloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:154
        #1 0x555c470acdc9 in xcalloc /home/simark/src/binutils-gdb/gdb/alloc.c:100
        #2 0x555c49b775cd in xzalloc(unsigned long) /home/simark/src/binutils-gdb/gdbsupport/common-utils.cc:29
        #3 0x555c4977bdeb in allocate_value_contents /home/simark/src/binutils-gdb/gdb/value.c:1029
        #4 0x555c4977be25 in allocate_value(type*) /home/simark/src/binutils-gdb/gdb/value.c:1040
        #5 0x555c4979030d in value_primitive_field(value*, long, int, type*) /home/simark/src/binutils-gdb/gdb/value.c:3092
        #6 0x555c478f6280 in cp_print_value /home/simark/src/binutils-gdb/gdb/cp-valprint.c:501
        #7 0x555c478f02ca in cp_print_value_fields(value*, ui_file*, int, value_print_options const*, type**, int) /home/simark/src/binutils-gdb/gdb/cp-valprint.c:161
        #8 0x555c478f63b2 in cp_print_value /home/simark/src/binutils-gdb/gdb/cp-valprint.c:513
        #9 0x555c478f02ca in cp_print_value_fields(value*, ui_file*, int, value_print_options const*, type**, int) /home/simark/src/binutils-gdb/gdb/cp-valprint.c:161
        #10 0x555c478f63b2 in cp_print_value /home/simark/src/binutils-gdb/gdb/cp-valprint.c:513
        #11 0x555c478f02ca in cp_print_value_fields(value*, ui_file*, int, value_print_options const*, type**, int) /home/simark/src/binutils-gdb/gdb/cp-valprint.c:161
        #12 0x555c4760d45f in c_value_print_struct /home/simark/src/binutils-gdb/gdb/c-valprint.c:383
        #13 0x555c4760df4c in c_value_print_inner(value*, ui_file*, int, value_print_options const*) /home/simark/src/binutils-gdb/gdb/c-valprint.c:438
        #14 0x555c483ff9a7 in language_defn::value_print_inner(value*, ui_file*, int, value_print_options const*) const /home/simark/src/binutils-gdb/gdb/language.c:632
        #15 0x555c49758b68 in do_val_print /home/simark/src/binutils-gdb/gdb/valprint.c:1048
        #16 0x555c49759b17 in common_val_print(value*, ui_file*, int, value_print_options const*, language_defn const*) /home/simark/src/binutils-gdb/gdb/valprint.c:1151
        #17 0x555c478f2fcb in cp_print_value_fields(value*, ui_file*, int, value_print_options const*, type**, int) /home/simark/src/binutils-gdb/gdb/cp-valprint.c:335
        #18 0x555c478f63b2 in cp_print_value /home/simark/src/binutils-gdb/gdb/cp-valprint.c:513
        #19 0x555c478f02ca in cp_print_value_fields(value*, ui_file*, int, value_print_options const*, type**, int) /home/simark/src/binutils-gdb/gdb/cp-valprint.c:161
        #20 0x555c4760d45f in c_value_print_struct /home/simark/src/binutils-gdb/gdb/c-valprint.c:383
        #21 0x555c4760df4c in c_value_print_inner(value*, ui_file*, int, value_print_options const*) /home/simark/src/binutils-gdb/gdb/c-valprint.c:438
        #22 0x555c483ff9a7 in language_defn::value_print_inner(value*, ui_file*, int, value_print_options const*) const /home/simark/src/binutils-gdb/gdb/language.c:632
        #23 0x555c49758b68 in do_val_print /home/simark/src/binutils-gdb/gdb/valprint.c:1048
        #24 0x555c49759b17 in common_val_print(value*, ui_file*, int, value_print_options const*, language_defn const*) /home/simark/src/binutils-gdb/gdb/valprint.c:1151
        #25 0x555c478f2fcb in cp_print_value_fields(value*, ui_file*, int, value_print_options const*, type**, int) /home/simark/src/binutils-gdb/gdb/cp-valprint.c:335
        #26 0x555c4760d45f in c_value_print_struct /home/simark/src/binutils-gdb/gdb/c-valprint.c:383
        #27 0x555c4760df4c in c_value_print_inner(value*, ui_file*, int, value_print_options const*) /home/simark/src/binutils-gdb/gdb/c-valprint.c:438
        #28 0x555c483ff9a7 in language_defn::value_print_inner(value*, ui_file*, int, value_print_options const*) const /home/simark/src/binutils-gdb/gdb/language.c:632
        #29 0x555c49758b68 in do_val_print /home/simark/src/binutils-gdb/gdb/valprint.c:1048

Since there are some binaries with this in the wild, I think it would be
useful for GDB to work around this.  I did the obvious simple thing, if
the DW_AT_data_member_location's value is -1, replace it with 0.  I
added a producer check to only apply this fixup for GCC 11.  The idea is
that if some other compiler ever uses a DW_AT_data_member_location value
of -1 by mistake, we don't know (before analyzing the bug at least) if
they did mean 0 or some other value.  So I wouldn't want to apply the
fixup in that case.

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

Fix GDB internal error by using text (instead of data) section offset

Fedora Rawhide is now using gcc-12.0.  As part of updating to the
gcc-12.0 package set, Rawhide is also now using a version of libgcc_s
which lacks a .data section.  This causes gdb to fail in the following
fashion while debugging a program (such as gdb) which uses libgcc_s:

    (top-gdb) run
    Starting program: rawhide-master/bld/gdb/gdb
    ...
    objfiles.h:467: internal-error: sect_index_data not initialized
    A problem internal to GDB has been detected,
    further debugging may prove unreliable.
    ...

I snipped the backtrace from the above output.  Instead, here's a
portion of a backtrace obtained using GDB's backtrace command.
(Obviously, in order to obtain it, I used a GDB which has been patched
with this commit.)

    #0  internal_error (
file=0xc6a508 "gdb/objfiles.h", line=467,
fmt=0xc6a4e8 "sect_index_data not initialized")
at gdbsupport/errors.cc:51
    #1  0x00000000005f9651 in objfile::data_section_offset (this=0x4fa48f0)
at gdb/objfiles.h:467
    #2  0x000000000097c5f8 in relocate_address (address=0x17244, objfile=0x4fa48f0)
at gdb/stap-probe.c:1333
    #3  0x000000000097c630 in stap_probe::get_relocated_address (this=0xa1a17a0,
objfile=0x4fa48f0)
at gdb/stap-probe.c:1341
    #4  0x00000000004d7025 in create_exception_master_breakpoint_probe (
objfile=0x4fa48f0)
at gdb/breakpoint.c:3505
    #5  0x00000000004d7426 in create_exception_master_breakpoint ()
at gdb/breakpoint.c:3575
    #6  0x00000000004efcc1 in breakpoint_re_set ()
at gdb/breakpoint.c:13407
    #7  0x0000000000956998 in solib_add (pattern=0x0, from_tty=0, readsyms=1)
at gdb/solib.c:1001
    #8  0x00000000009576a8 in handle_solib_event ()
at gdb/solib.c:1269
    ...

The function 'relocate_address' in gdb/stap-probe.c attempts to do
its "relocation" by using objfile->data_section_offset().  That
method, data_section_offset() is defined as follows in objfiles.h:

  CORE_ADDR data_section_offset () const
  {
    return section_offsets[SECT_OFF_DATA (this)];
  }

The internal error occurs when the SECT_OFF_DATA macro finds that the
'sect_index_data' field is -1:

    #define SECT_OFF_DATA(objfile) \
 ((objfile->sect_index_data == -1) \
  ? (internal_error (__FILE__, __LINE__, \
     _("sect_index_data not initialized")), -1) \
  : objfile->sect_index_data)

relocate_address() is obtaining the section offset in order to compute
a relocated address.  For some ABIs, such as the System V ABI, the
section offsets will all be the same.  So for those ABIs, it doesn't
matter which offset is used.  However, other ABIs, such as the FDPIC
ABI, will have different offsets for the various sections.  Thus, for
those ABIs, it is vital that this and other relocation code use the
correct offset.

In stap_probe::get_relocated_address, the address to which to add the
offset (thus forming the relocated address) is obtained via
this->get_address (); get_address is a getter for m_address in
probe.h.  It's documented/defined as follows (also in probe.h):

  /* The address where the probe is inserted, relative to
     SECT_OFF_TEXT.  */
  CORE_ADDR m_address;

(Thanks to Tom Tromey for this observation.)

So, based on this, the current use of data_section_offset /
SECT_OFF_DATA is wrong.  This relocation code should have been using
text_section_offset / SECT_OFF_TEXT all along.  That being the
case, I've adjusted the stap-probe.c relocation code accordingly.

Searching the sources turned up one other use of data_section_offset,
in gdb/dtrace-probe.c, so I've updated that code as well.  The same
reasoning presented above applies to this case too.

Summary:

* gdb/dtrace-probe.c (dtrace_probe::get_relocated_address):
Use method text_section_offset instead of data_section_offset.
* gdb/stap-probe.c (relocate_address): Likewise.

gdb, remote, btrace: move switch_to_thread call right before xfer call

In remote_target::remote_btrace_maybe_reopen, we switch to the currently
iterated thread in order to set inferior_ptid for a subsequent xfer.

Move the switch_to_thread call directly before the target_read_stralloc
call to clarify why we need to switch threads.

gdb, gdbserver: update thread identifier in enable_btrace target method

The enable_btrace target method takes a ptid_t to identify the thread on
which tracing shall be enabled.

Change this to thread_info * to avoid translating back and forth between
the two.  This will be used in a subsequent patch.

gdb, btrace: switch threads in remote_btrace_maybe_reopen()

In remote_btrace_maybe_reopen() we iterate over threads and use
set_general_thread() to set the thread from which to transfer the btrace
configuration.

This sets the remote general thread but does not affect inferior_ptid.  On
the xfer request later on, remote_target::xfer_partial() again sets the
remote general thread to inferior_ptid, overwriting what
remote_btrace_maybe_reopen() had done.

In one case, this led to inferior_ptid being null_ptid when we tried to
enable tracing on a newly created thread inside a newly created process
during attach.

This, in turn, led to find_inferior_pid() asserting when we iterated over
threads in record_btrace_is_replaying(), which was called from
record_btrace_target::xfer_partial() when reading the btrace configuration
of the new thread to check whether it was already being recorded.

The bug was exposed by

    0618ae41497 gdb: optimize all_matching_threads_iterator

and found by

    FAIL: gdb.btrace/enable-new-thread.exp: ... (GDB internal error)

Use switch_to_thread() in remote_btrace_maybe_reopen().

gdb, btrace: rename record_btrace_enable_warn()

We use record_btrace_enable_warn() as the new-thread observer callback.
It is not used in other contexts.

Rename it to record_btrace_on_new_thread() to make its role more clear.

Updated Swedish translation for the binutils subdirectory

Automatic date update in version.in

gdb/python: handle non utf-8 characters when source highlighting

This commit adds support for source files that contain non utf-8
characters when performing source styling using the Python pygments
package.  This does not change the behaviour of GDB when the GNU
Source Highlight library is used.

For the following problem description, assume that either GDB is built
without GNU Source Highlight support, of that this has been disabled
using 'maintenance set gnu-source-highlight enabled off'.

The initial problem reported was that a source file containing non
utf-8 characters would cause GDB to print a Python exception, and then
display the source without styling, e.g.:

  Python Exception <class 'UnicodeDecodeError'>: 'utf-8' codec can't decode byte 0xc0 in position 142: invalid start byte
  /* Source code here, without styling...  */

Further, as the user steps through different source files, each time
the problematic source file was evicted from the source cache, and
then later reloaded, the exception would be printed again.

Finally, this problem is only present when using Python 3, this issue
is not present for Python 2.

What makes this especially frustrating is that GDB can clearly print
the source file contents, they're right there...  If we disable
styling completely, or make use of the GNU Source Highlight library,
then everything is fine.  So why is there an error when we try to
apply styling using Python?

The problem is the use of PyString_FromString (which is an alias for
PyUnicode_FromString in Python 3), this function converts a C string
into a either a Unicode object (Py3) or a str object (Py2).  For
Python 2 there is no unicode encoding performed during this function
call, but for Python 3 the input is assumed to be a uft-8 encoding
string for the purpose of the conversion.  And here of course, is the
problem, if the source file contains non utf-8 characters, then it
should not be treated as utf-8, but that's what we do, and that's why
we get an error.

My first thought when looking at this was to spot when the
PyString_FromString call failed with a UnicodeDecodeError and silently
ignore the error.  This would mean that GDB would print the source
without styling, but would also avoid the annoying exception message.

However, I also make use of `pygmentize`, a command line wrapper
around the Python pygments module, which I use to apply syntax
highlighting in the output of `less`.  And this command line wrapper
is quite happy to syntax highlight my source file that contains non
utf-8 characters, so it feels like the problem should be solvable.

It turns out that inside the pygments module there is already support
for guessing the encoding of the incoming file content, if the
incoming content is not already a Unicode string.  This is what
happens for Python 2 where the incoming content is of `str` type.

We could try and make GDB smarter when it comes to converting C
strings into Python Unicode objects; this would probably require us to
just try a couple of different encoding schemes rather than just
giving up after utf-8.

However, I figure, why bother?  The pygments module already does this
for us, and the colorize API is not part of the documented external
API of GDB.  So, why not just change the colorize API, instead of the
content being a Unicode string (for Python 3), lets just make the
content be a bytes object.  The pygments module can then take
responsibility for guessing the encoding.

So, currently, the colorize API receives a unicode object, and returns
a unicode object.  I propose that the colorize API receive a bytes
object, and return a bytes object.

Remove global wrap_here function

This removes the global wrap_here function, so that future calls
cannot be introduced.  Instead, all callers must use the method on the
appropriate ui_file.

This temporarily moves the implementation of this method to utils.c.
This will change once the remaining patches to untangle the pager have
been written.

Always call the wrap_here method

This changes all existing calls to wrap_here to call the method on the
appropriate ui_file instead.  The choice of ui_file is determined by
context.

Add ui_file::wrap_here

Right now, wrap_here is a global function.  In the long run, we'd like
output streams to be relatively self-contained objects, and having a
global function like this is counter to that goal.  Also, existing
code freely mixes writes to some parameterized stream with calls to
wrap_here -- but wrap_here only really affects gdb_stdout, so this is
also incoherent.

This step is a patch toward making wrap_here more sane.  It adds a
wrap_here method to ui_file and changes ui_out implementations to use
it.

Convert wrap_here to use integer parameter

I think it only really makes sense to call wrap_here with an argument
consisting solely of spaces.  Given this, it seemed better to me that
the argument be an int, rather than a string.  This patch is the
result.  Much of it was written by a script.

gdb/python: improve the auto help text for gdb.Parameter

This commit attempts to improve the help text that is generated for
gdb.Parameter objects when the user fails to provide their own
documentation.

Documentation for a gdb.Parameter is currently pulled from two
sources: the class documentation string, and the set_doc/show_doc
class attributes.  Thus, a fully documented parameter might look like
this:

  class Param_All (gdb.Parameter):
     """This is the class documentation string."""

     show_doc = "Show the state of this parameter"
     set_doc = "Set the state of this parameter"

     def get_set_string (self):
        val = "on"
        if (self.value == False):
           val = "off"
        return "Test Parameter has been set to " + val

     def __init__ (self, name):
        super (Param_All, self).__init__ (name, gdb.COMMAND_DATA, gdb.PARAM_BOOLEAN)
        self._value = True

  Param_All ('param-all')

Then in GDB we see this:

  (gdb) help set param-all
  Set the state of this parameter
  This is the class documentation string.

Which is fine.  But, if the user skips both of the documentation parts
like this:

  class Param_None (gdb.Parameter):

     def get_set_string (self):
        val = "on"
        if (self.value == False):
           val = "off"
        return "Test Parameter has been set to " + val

     def __init__ (self, name):
        super (Param_None, self).__init__ (name, gdb.COMMAND_DATA, gdb.PARAM_BOOLEAN)
        self._value = True

  Param_None ('param-none')

Now in GDB we see this:

  (gdb) help set param-none
  This command is not documented.
  This command is not documented.

That's not great, the duplicated text looks a bit weird.  If we drop
different parts we get different results.  Here's what we get if the
user drops the set_doc and show_doc attributes:

  (gdb) help set param-doc
  This command is not documented.
  This is the class documentation string.

That kind of sucks, we say it's undocumented, then proceed to print
the documentation.  Finally, if we drop the class documentation but
keep the set_doc and show_doc:

  (gdb) help set param-set-show
  Set the state of this parameter
  This command is not documented.

That seems OK.

So, I think there's room for improvement.

With this patch, for the four cases above we now see this:

  # All values provided by the user, no change in this case:
  (gdb) help set param-all
  Set the state of this parameter
  This is the class documentation string.

  # Nothing provided by the user, the first string is now different:
  (gdb) help set param-none
  Set the current value of 'param-none'.
  This command is not documented.

  # Only the class documentation is provided, the first string is
  # changed as in the previous case:
  (gdb) help set param-doc
  Set the current value of 'param-doc'.
  This is the class documentation string.

  # Only the set_doc and show_doc are provided, this case is unchanged
  # from before the patch:
  (gdb) help set param-set-show
  Set the state of this parameter
  This command is not documented.

The one place where this change might be considered a negative is when
dealing with prefix commands.  If we create a prefix command but don't
supply the set_doc / show_doc strings, then this is what we saw before
my patch:

  (gdb) python Param_None ('print param-none')
  (gdb) help set print
  set print, set pr, set p
  Generic command for setting how things print.

  List of set print subcommands:

  ... snip ...
  set print param-none -- This command is not documented.
  ... snip ...

And after my patch:

  (gdb) python Param_None ('print param-none')
  (gdb) help set print
  set print, set pr, set p
  Generic command for setting how things print.

  List of set print subcommands:

  ... snip ...
  set print param-none -- Set the current value of 'print param-none'.
  ... snip ...

This seems slightly less helpful than before, but I don't think its
terrible.

Additionally, I've changed what we print when the get_show_string
method is not provided in Python.

Back when gdb.Parameter was first added to GDB, we didn't provide a
show function when registering the internal command object within
GDB.  As a result, GDB would make use of its "magic" mangling of the
show_doc string to create a sentence that would display the current
value (see deprecated_show_value_hack in cli/cli-setshow.c).

However, when we added support for the get_show_string method to
gdb.Parameter, there was an attempt to maintain backward compatibility
by displaying the show_doc string with the current value appended, see
get_show_value in py-param.c.  Unfortunately, this isn't anywhere
close to what deprecated_show_value_hack does, and the results are
pretty poor, for example, this is GDB before my patch:

  (gdb) show param-none
  This command is not documented. off

I think we can all agree that this is pretty bad.

After my patch, we how show this:

  (gdb) show param-none
  The current value of 'param-none' is "off".

Which at least is a real sentence, even if it's not very informative.

This patch does change the way that the Python API behaves slightly,
but only in the cases when the user has missed providing GDB with some
information.  In most cases I think the new behaviour is a lot better,
there's the one case (noted above) which is a bit iffy, but I think is
still OK.

I've updated the existing gdb.python/py-parameter.exp test to cover
the modified behaviour.

Finally, I've updated the documentation to (I hope) make it clearer
how the various bits of help text come together.

gdb/python: add gdb.history_count function

Add a new function gdb.history_count to the Python api, this function
returns an integer, the number of items in GDB's value history.

This is useful if you want to pull items from the history by their
absolute number, for example, if you wanted to show a complete history
list.  Previously we could figure out how many items are in the
history list by trying to fetch the items, and then catching the
exception when the item is not available, but having this function
seems nicer.

Remove unused declaration

This removes an unused declaration from top.h.  This type is not
defined anywhere.

gdb: convert maintenance target-async and target-non-stop settings to callbacks

This simplifies things a bit, as we don't need two variables and think
about reverting target_async_permitted_1 and target_non_stop_enabled_1
values if we can't change the setting.

Change-Id: I36acab045dacf02ae1988486cfdb27c1dff309f6

Reference array of structs instead of first member during memcpy

aarch64-tdep.c defines the following macro:

#define MEM_ALLOC(MEMS, LENGTH, RECORD_BUF) \
        do  \
          { \
            unsigned int mem_len = LENGTH; \
            if (mem_len) \
              { \
                MEMS =  XNEWVEC (struct aarch64_mem_r, mem_len);  \
                memcpy(&MEMS->len, &RECORD_BUF[0], \
                       sizeof(struct aarch64_mem_r) * LENGTH); \
              } \
          } \
          while (0)

This is simlpy allocating a new array and copying it. However, for
the destination address, it is actually copying into the first member
of the first element of the array (`&MEMS->len"). This elicits a
warning with GCC 12:

../../binutils-gdb/gdb/aarch64-tdep.c: In function ‘int aarch64_process_record(gdbarch*, regcache*, CORE_ADDR)’:
../../binutils-gdb/gdb/aarch64-tdep.c:3711:23: error: writing 16 bytes into a region of size 8 [-Werror=stringop-overflow=]
 3711 |                 memcpy(&MEMS->len, &RECORD_BUF[0], \
      |                       ^
../../binutils-gdb/gdb/aarch64-tdep.c:4394:3: note: in expansion of macro ‘MEM_ALLOC’
 4394 |   MEM_ALLOC (aarch64_insn_r->aarch64_mems, aarch64_insn_r->mem_rec_count,
      |   ^~~~~~~~~
../../binutils-gdb/gdb/aarch64-tdep.c:3721:12: note: destination object ‘aarch64_mem_r::len’ of size 8
 3721 |   uint64_t len;    /* Record length.  */
      |            ^~~

The simple fix is to reference the array, `MEMS' as the destination of the copy.

Tested by rebuilding.

# Please enter the commit message for your changes. Lines starting
# with '#' will be kept; you may remove them yourself if you want to.
# An empty message aborts the commit.
#
# Date:      Tue Jan 25 08:28:32 2022 -0800
#
# On branch master
# Your branch is ahead of 'origin/master' by 1 commit.
#   (use "git push" to publish your local commits)
#
# Changes to be committed:
# modified:   aarch64-tdep.c
#

gdb: add string_file::release method

A common pattern for string_file is to want to move out the internal
string buffer, because it is the result of the computation that we want
to return.  It is the reason why string_file::string returns a non-const
reference, as explained in the comment.  I think it would make sense to
have a dedicated method for that instead and make string_file::string
return a const reference.

This allows removing the explicit std::move in the typical case.  Note
that compile_program::compute was missing a move, meaning that the
resulting string was copied.  With the new version, it's not possible to
forget to move.

Change-Id: Ieaefa35b73daa7930b2f3a26988b6e3b4121bb79

Add a way to temporarily set a gdb parameter from Python

It's sometimes useful to temporarily set some gdb parameter from
Python.  Now that the 'endian' crash is fixed, and now that the
current language is no longer captured by the Python layer, it seems
reasonable to add a helper function for this situation.

This adds a new gdb.with_parameter function.  This creates a context
manager which temporarily sets some parameter to a specified value.
The old value is restored when the context is exited.  This is most
useful with the Python "with" statement:

   with gdb.with_parameter('language', 'ada'):
      ... do Ada stuff

This also adds a simple function to set a parameter,
gdb.set_parameter, as suggested by Andrew.

This is PR python/10790.

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

Fix another crash with gdb parameters in Python

While looking into the language-capturing issue, I found another way
to crash gdb using parameters from Python:

(gdb) python print(gdb.parameter('endian'))

(This is related to PR python/12188, though this patch isn't going to
fix what that bug is really about.)

The problem here is that the global variable that underlies the
"endian" parameter is initialized to NULL.  However, that's not a
valid value for an "enum" set/show parameter.

My understanding is that, in gdb, an "enum" parameter's underlying
variable must have a value that is "==" (not just strcmp-equal) to one
of the values coming from the enum array.  This invariant is relied on
in various places.

I started this patch by fixing the problem with "endian".  Then I
added some assertions to add_setshow_enum_cmd to try to catch other
problems of the same type.

This patch fixes all the problems that I found.  I also looked at all
the calls to add_setshow_enum_cmd to ensure that they were all
included in the gdb I tested.  I think they are: there are no calls in
nat-* files, or in remote-sim.c; and I was trying a build with all
targets, Python, and Guile enabled.

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

Change how Python architecture and language are handled

Currently, gdb's Python layer captures the current architecture and
language when "entering" Python code.  This has some undesirable
effects, and so this series changes how this is handled.

First, there is code like this:

  gdbpy_enter enter_py (python_gdbarch, python_language);

This is incorrect, because both of these are NULL when not otherwise
assigned.  This can cause crashes in some cases -- I've added one to
the test suite.  (Note that this crasher is just an example, other
ones along the same lines are possible.)

Second, when the language is captured in this way, it means that
Python code cannot affect the current language for its own purposes.
It's reasonable to want to write code like this:

    gdb.execute('set language mumble')
    ... stuff using the current language
    gdb.execute('set language previous-value')

However, this won't actually work, because the language is captured on
entry.  I've added a test to show this as well.

This patch changes gdb to try to avoid capturing the current values.
The Python concept of the current gdbarch is only set in those few
cases where a non-default value is computed or needed; and the
language is not captured at all -- instead, in the cases where it's
required, the current language is temporarily changed.

bfd: Make bfd.stamp depend on source bfd.texi

Make bfd.stamp depend on source bfd.texi to avoid regenerating
doc/bfd.info for each make run.

PR binutils/28807
* Makefile.in: Regenerate.
* doc/local.mk (%D%/bfd.stamp): Depend on $(srcdir)/%D%/bfd.texi.

ld: Rewrite lang_size_relro_segment_1

1. Compute the desired PT_GNU_RELRO segment base and find the maximum
section alignment of sections starting from the PT_GNU_RELRO segment.
2. Find the first preceding load section.
3. Don't add the 1-page gap between the first preceding load section and
the relro segment if the maximum page size >= the maximum section
alignment.  Align the PT_GNU_RELRO segment first.  Subtract the maximum
page size if therer is still a 1-page gap.

PR ld/28743
PR ld/28819
* ldlang.c (lang_size_relro_segment_1): Rewrite.
* testsuite/ld-x86-64/pr28743-1.d: New file.
* testsuite/ld-x86-64/pr28743-1.s: Likewise.
* testsuite/ld-x86-64/x86-64.exp: Run pr28743-1.

gdb/testsuite: Ensure constant test name in gdb.base/break-interp.exp

When running the testsuite, I have lines similar to the following in the
gdb.sum file:

~~~
PASS: gdb.base/break-interp.exp: ldprelink=NO: ldsepdebug=NO: first backtrace: p /x 0x7f283d2f0fd1
...
PASS: gdb.base/break-interp.exp: ldprelink=NO: ldsepdebug=NO: binprelink=NO: binsepdebug=NO: binpie=NO: INNER: first backtrace: p /x 0x7f00de0317a5
...
~~~

The address part of the command might change between execution of the
test, which adds noise to a diff between two .sum files.

This patch changes to test name to "p /x $pc" in order to have constant
test name.

Tested on x86_64-Linux.

Change-Id: I973c1237a084dd6d424276443cbf0920533c9a21

Automatic date update in version.in

Always print the "host libthread-db" message to stdout

linux-thread-db.c has a bit of unusual code that unconditionally
prints a message, but decides whether to print to gdb_stdout or
gdb_stdlog based on a debug flag.  It seems better to me to simply
always print this; and this is the only spot in gdb where we
conditionally pass gdb_stdout to one of the f*_unfiltered functions.

Reduce explicit use of gdb_stdout

In an earlier version of the pager rewrite series, it was important to
audit unfiltered output calls to see which were truly necessary.

This is no longer necessary, but it still seems like a decent cleanup
to change calls to avoid explicitly passing gdb_stdout.  That is,
rather than using something like fprintf_unfiltered with gdb_stdout,
the code ought to use plain printf_unfiltered instead.

This patch makes this change.  I went ahead and converted all the
_filtered calls I could find, as well, for the same clarity.

Sent timing stats to gdb_stdlog

This changes the time / space / symtab per-command statistics code to
send its output to gdb_stdlog rather than gdb_stdout.  This seems
slightly more correct to me.

Send some error output to gdb_stderr

This changes some code to send some error messages to gdb_stderr
rather than gdb_stdout.

Fix a probem building the binutils on SPARC/amd64

PR 28816
* elf/common.h (AT_SUN_HWCAP): Make definition conditional.

bfd: Regenerate Makefile.in

* Makefile.in: Regenerate.

gold: drop old cygnus install hack

The gold subdir doesn't actually have a manual, so this hack doesn't
do anything.  Plus the automake cygnus option was removed years ago
by Simon in d0ac1c44885daf68f631befa37e ("Bump to autoconf 2.69 and
automake 1.15.1").  So delete it here.

gas: drop old cygnus install hack

This was needed when gas was using the automake cygnus option, but
this was removed years ago by Simon in d0ac1c44885daf68f631befa37e
("Bump to autoconf 2.69 and automake 1.15.1").  So delete it here.
The info pages are already & still installed by default w/out it.

Automatic date update in version.in

bfd: Update doc/local.mk

PR binutils/28807
* Makefile.in: Regenerate.
* doc/local.mk (AM_MAKEINFOFLAGS): Add -I "$(srcdir)/%D%" -I %D%.
(TEXI2DVI): New.
(%D%/bfd.texi): Removed.
(doc/bfd/index.html): Remove -I$(srcdir).  Replace bfd.texi with
%D%/bfd.texi.

bfd/doc: Fix racy build failure from missing mkdir

bfd/
* doc/local.mk (%D%/bfdver.texi): Add mkdir command.

Fix a proble building the libiberty library with gcc-12.

PR 28779
* regex.c: Suppress -Wuse-after-free.

gdb/doc: improve description for Window.click on Python TUI windows

The description of the Window.click method doesn't mention where the
coordinates are anchored (it's the top left corner).

This minor tweak just mentions this point.

Update Bulgarian, French, Romaniam and Ukranian translation for some of the sub-directories

Automatic date update in version.in

Simplify some Rust expression-evaluation code

A few Rust operations do a bit of work in their 'evaluate' functions
and then call another function -- but are also the only caller.  This
patch simplifies this code by removing the extra layer.

Tested on x86-64 Fedora 34.  I'm checking this in.

bfd: Partially revert commit 0e3839bde6f

Partially revert

commit 0e3839bde6f93e1e3eefce815be3636e3d81054d
Author: H.J. Lu <hjl.tools@gmail.com>
Date:   Sun Jan 23 07:29:27 2022 -0800

    bfd: Properly install library and header files

PR binutils/28807
* Makefile.am: Revert bfdlib_LTLIBRARIES and bfdinclude_HEADERS
changes.
* Makefile.in: Regenerate.

bfd: Properly install library and header files

Rename bfdlib_LTLIBRARIES and bfdinclude_HEADERS to lib_LTLIBRARIES and
include_HEADERS to fix the missing installed library and header files in
bfd caused by

commit bd32be01c997f686ab0b53f0640eaa0aeb61fbd3
Author: Mike Frysinger <vapier@gentoo.org>
Date:   Fri Dec 3 00:23:20 2021 -0500

    bfd: merge doc subdir up a level

PR binutils/28807
* Makefile.am (bfdlib_LTLIBRARIES): Renamed to ...
(lib_LTLIBRARIES): This.
(bfdinclude_HEADERS): Renamed to ...
(include_HEADERS): This.
* Makefile.in: Regenerate.
* doc/local.mk (install): Removed.

Regenerate Makefile.in files with automake 1.15.1

Regenerate Makefile.in files with the unmodified automake 1.15.1 to
remove

runstatedir = @runstatedir@

bfd/

* Makefile.in: Regenerate.

binutils/

* Makefile.in: Regenerate.

gas/

* Makefile.in: Regenerate.

gold/

* Makefile.in: Regenerate.
* testsuite/Makefile.in: Likewise.

gprof/

* Makefile.in: Regenerate.

ld/

* Makefile.in: Regenerate.

opcodes/

* Makefile.in: Regenerate.

Regenerate configure files with autoconf 2.69

Regenerate configure files with the unmodified autoconf 2.69 to remove

  --runstatedir=DIR       modifiable per-process data [LOCALSTATEDIR/run]

bfd/

* configure: Regenerate.

binutils/

* configure: Regenerate.

gas/

* configure: Regenerate.

gold/

* configure: Regenerate.

gprof/

* configure: Regenerate.

ld/

* configure: Regenerate.

opcodes/

* configure: Regenerate.

Automatic date update in version.in

bfd: merge doc subdir up a level

This avoids a recursive make into the doc subdir and speeds up the
build slightly.  It also allows for more parallelism.

bfd: rename core.texi to corefile.texi

This is a generated file name from a correspondingly named C file.
Rename it to avoid unique build rules since there's no difference
to the generated manual.

bfd: replace doc header generation with pattern rules

This unifies boilerplate rules for most files with pattern rules.