PR29270, DW_FORM_udata signed output

PR 29270
* dwarf.c (read_and_display_attr_value): Output DW_FORM_udata
as unsigned.

Automatic date update in version.in

ld: regenerate configure after recent misgeneration

Things work again after this.

ld/ChangeLog:

* configure: Regenerate.

libctf: tests: prune warnings from compiler output

We were failing to call prune_warnings appropriately, leading to
false-positive test failures on some platforms (observed on
sparclinux).

libctf/ChangeLog:

* testsuite/lib/ctf-lib.exp: Prune warnings from compiler and
linker output.
* testsuite/libctf-regression/libctf-repeat-cu.exp: Likewise,
and ar output too.

libctf: avoid mingw warning

A missing paren led to an intended cast to avoid dependence on the size
of size_t in one argument of ctf_err_warn applying to the wrong type by
mistake.

libctf/ChangeLog:

* ctf-serialize.c (ctf_write_mem): Fix cast.

libctf: fix linking together multiple objects derived from the same source

Right now, if you compile the same .c input repeatedly with CTF enabled
and different compilation flags, then arrange to link all of these
together, then things misbehave in various ways.  libctf may conflate
either inputs (if the .o files have the same name, say if they are
stored in different .a archives), or per-CU outputs when conflicting
types are found: the latter can lead to entirely spurious errors when
it tries to produce multiple per-CU outputs with the same name
(discarding all but the last, but then looking for types in the earlier
ones which have just been thrown away).

Fixing this is multi-pronged.  Both inputs and outputs need to be
differentiated in the hashtables libctf keeps them in: inputs with the
same cuname and filename need to be considered distinct as long as they
have different associated CTF dicts, and per-CU outputs need to be
considered distinct as long as they have different associated input
dicts.  Right now there is nothing tying the two together other than the
CU name: fix this by introducing a new field in the ctf_dict_t named
ctf_link_in_out, which (for input dicts) points to the associated per-CU
output dict (if any), and for output dicts points to the associated
input dict.  At creation time the name used is completely arbitrary:
it's only important that it be distinct if CTF dicts are distinct.  So,
when a clash is found, adjust the CU name by sticking the number of
elements in the input on the end.  At output time, the CU name will
appear in the linked object, so it matters a little more that it look
slightly less ugly: in conflicting cases, append an incrementing
integer, starting at 0.

This naming scheme is not very helpful, but it's hard to see what else
we can do.  The input .o name may be the same.  The input .a name is not
even visible to ctf_link, and even *that* might be the same, because
.a's can contain many members with the same name, all of which
participate in the link.  All we really know is that the two have
distinct dictionaries with distinct types in them, and at least this way
they are all represented, any any symbols, variables etc referring to
those types are accurately stored.

(As a side-effect this also fixes a use-after-free and double-free when
errors are found during variable or symbol emission.)

Use the opportunity to prevent a couple of sources of problems, to wit
changing the active CU mappings when a link has already been done
(no effect on ld, which doesn't use CU mappings at all), and causing
multiple consecutive ctf_link's to have the same net effect as just
doing the last one (no effect on ld, which only ever does one
ctf_link) rather than having the links be a sort of half-incremental
not-really-intended mess.

libctf/ChangeLog:

PR libctf/29242
* ctf-impl.h (struct ctf_dict) [ctf_link_in_out]: New.
* ctf-dedup.c (ctf_dedup_emit_type): Set it.
* ctf-link.c (ctf_link_add_ctf_internal): Set the input
CU name uniquely when clashes are found.
(ctf_link_add): Document what repeated additions do.
(ctf_new_per_cu_name): New, come up with a consistent
name for a new per-CU dict.
(ctf_link_deduplicating): Use it.
(ctf_create_per_cu): Use it, and ctf_link_in_out, and set
ctf_link_in_out properly.  Don't overwrite per-CU dicts with
per-CU dicts relating to different inputs.
(ctf_link_add_cu_mapping): Prevent per-CU mappings being set up
if we already have per-CU outputs.
(ctf_link_one_variable): Adjust ctf_link_per_cu call.
(ctf_link_deduplicating_one_symtypetab): Likewise.
(ctf_link_empty_outputs): New, delete all the ctf_link_outputs
and blank out ctf_link_in_out on the corresponding inputs.
(ctf_link): Clarify the effect of multiple ctf_link calls.
Empty ctf_link_outputs if it already exists rather than
having the old output leak into the new link.  Fix a variable
name.
* testsuite/config/default.exp (AR): Add.
(OBJDUMP): Likewise.
* testsuite/libctf-regression/libctf-repeat-cu.exp: New test.
* testsuite/libctf-regression/libctf-repeat-cu*: Main program,
library, and expected results for the test.

Document how GDB searches for files when using -s, -e, and -se options

GDB's documentation of the 'file' command says:

    If you do not specify a directory and the file is not found in the
    GDB working directory, GDB uses the environment variable PATH as a
    list of directories to search, just as the shell does when looking
    for a program to run.

The same is true for files specified via commandline options -s, -e,
and -se.

This commit adds a cross reference to the file command for these options.

Binutils support for dwarf-5 (location and range lists related)

* dwarf.h (struct debug_info): Add rnglists_base field.
* dwarf.c (read_and_display_attr_value): Read attribute DW_AT_rnglists_base.
(display_debug_rnglists_list): While handling DW_RLE_base_addressx,
   DW_RLE_startx_endx, DW_RLE_startx_length items, pass the proper parameter
value to fetch_indexed_addr(), i.e. fetch the proper entry in .debug_addr section.
(display_debug_ranges): Add rnglists_base to the .debug_rnglists base address.
(load_separate_debug_files): Load .debug_addr section, if exists.

Default to disabling the linker warnings about execstack and RWX segments if the target is the HPPA architecture.

PR 29263
* configure.ac (ac_default_ld_warn_execstack): Default to 'no' for
HPPA targets.
(ac_default_ld_warn_rwx_segments): Likewise.
* configure: Regenerate.
* testsuite/ld-elf/elf.exp: Add the --warn-execstack command line
option to the command line when running execstack tests for the
HPPA target.

Automatic date update in version.in

Move finish_print out of value_print_options

'finish_print' does not really belong in value_print_options -- this
is consulted only when deciding whether or not to print a value, and
never during the course of printing.  This patch removes it from the
structure and makes it a static global in infcmd.c instead.

Tested on x86-64 Fedora 34.

PR29262, memory leak in pr_function_type

PR 29262
* prdbg.c (pr_function_type): Free "s" on failure path.

PR29261, memory leak in parse_stab_struct_fields

PR 29261
* stabs.c (parse_stab_struct_fields): Free "fields" on failure path.

Automatic date update in version.in

Automatic date update in version.in

Fix assertion failure in copy_type

PR exp/20630 points out a simple way to cause an assertion failure in
copy_type -- but this was found in the wild a few times as well.

copy_type only works for objfile-owned types, but there isn't a deep
reason for this.  This patch fixes the bug by updating copy_type to
work for any sort of type.

Better would perhaps be to finally implement type GC, but I still
haven't attempted this.

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

Fix the sorting algorithm for reloc entries

The optimized insertion sort algorithm in `elf_link_adjust_relocs`
incorrectly assembled "runs" from unsorted entries and inserted them to an
already-sorted prefix, breaking the loop invariants of insertion sort.
This commit updates the run assembly loop to break upon encountering a
non-monotonic change in the sort key.

PR 29259
bfd/
* elflink.c (elf_link_adjust_relocs): Ensure run being inserted
is sorted.
ld/
* testsuite/ld-elf/pr29259.d,
* testsuite/ld-elf/pr29259.s,
* testsuite/ld-elf/pr29259.t: New test.

gdb/python: Export nibbles to python layer

This patch makes it possible to allow Value.format_string() to return
nibbles output.

When we set the parameter of nibbles to True, we can achieve the
displaying binary values in groups of every four bits.

Here's an example:
  (gdb) py print (gdb.Value (1230).format_string (format='t', nibbles=True))
  0100 1100 1110
  (gdb)

Note that the parameter nibbles is only useful if format='t' is also used.

This patch also includes update to the relevant testcase and
documentation.

Tested on x86_64 openSUSE Tumbleweed.

gdb/doc: Documentation for the new print command

Document the new command "print nibbles" and add a NEWS entry.

gdb: Add new 'print nibbles' feature

Make an introduction of a new print setting that can be set by 'set
print nibbles [on|off]'.  The default value if OFF, which can be changed
by user manually.  Of course, 'show print nibbles' is also included in
the patch.

The new feature displays binary values by group, with four bits per
group.  The motivation for this work is to enhance the readability of
binary values.

Here's a GDB session before this patch is applied.
  (gdb) print var_a
  $1 = 1230
  (gdb) print/t var_a
  $2 = 10011001110

With this patch applied, we can use the new print setting to display the
new form of the binary values.
  (gdb) print var_a
  $1 = 1230
  (gdb) print/t var_a
  $2 = 10011001110
  (gdb) set print nibbles on
  (gdb) print/t var_a
  $3 = 0100 1100 1110

Tested on x86_64 openSUSE Tumbleweed.

Automatic date update in version.in

gdb: NEWS: Move LoongArch gdbserver to the correct section

commit e5ab6af52d38 ("gdbserver: Add LoongArch/Linux support")
was merged into the master since GDB 12, so we should put the
news in the "Changes since GDB 12" section.

Thanks Tom Tromey for your correction [1], sorry for that.

[1] https://sourceware.org/pipermail/gdb-patches/2022-June/190122.html

Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>

PR29256, memory leak in obj_elf_section_name

When handling section names in quotes obj_elf_section_name calls
demand_copy_C_string, which puts the name on the gas notes obstack.
Such strings aren't usually freed, since obstack_free frees all more
recently allocated objects as well as its arg.  When handling
non-quoted names, obj_elf_section_name mallocs the name.  Due to the
mix of allocation strategies it isn't possible for callers to free
names, if that was desirable.  Partially fix this by always creating
names on the obstack, which is more efficient anyway.  (You still
can't obstack_free on error paths due to the xtensa
tc_canonicalize_section_name.)  Also remove a couple of cases where
the name is dup'd for no good reason as far as I know.

PR 29256
* config/obj-elf.c (obj_elf_section_name): Create name on notes
obstack.
(obj_elf_attach_to_group): Don't strdup group name.
(obj_elf_section): Likewise.
(obj_elf_vendor_attribute): Use xmemdup0 rather than xstrndup.

PR29255, memory leak in make_tempdir

PR 29255
* bucomm.c (make_tempdir, make_tempname): Free template on all
failure paths.

PR29254, memory leak in stab_demangle_v3_arg

PR 29254
* stabs.c (stab_demangle_v3_arg): Free dt on failure path.

Fix GDB build with GCC 4.8 & 4.9

With gcc 4.8/4.9, we run into this build failure (and other similar
ones):

  /home/palves/gdb/binutils-gdb/src/gdb/location.h:224:59: error: could not convert ‘{0, LINE_OFFSET_UNKNOWN}’ from ‘<brace-enclosed initializer list>’ to ‘line_offset’
     struct line_offset line_offset = {0, LINE_OFFSET_UNKNOWN};
     ^

The issue is that at around the GCC 4.8/4.9 era, a default member
initializer prevented the struct from being an aggregate, so you
cannot use aggregate initialization on them.  That rule changed after
GCC 4.9 and GCC 5 & later uses new rules.

Fix this by not using aggregate initialization for struct line_offset.
The default member initization already leaves line_offset as {0,
LINE_OFFSET_UNKNOWN}, so initialization to those values can just go
away.  The remaining cases are of the form {0, LINE_OFFSET_NONE}, and
those cases can be better rewritten to delay setting the sign field
until we know we have a valid offset.

Change-Id: I0506ea4a83c5fa2f15e159569db68b3b0a7509b4

Convert set_location_spec_string to a method

This converts set_location_spec_string to a method of location_spec,
and makes the location_spec::as_string field protected, renaming it to
m_as_string along the way.

Change-Id: Iccfb1654e9fa7808d0512df89e775f9eacaeb9e0

Convert location_spec_to_string to a method

This converts location_spec_to_string to a method of location_spec,
simplifying the code using it, as it no longer has to use
std::unique_ptr::get().

Change-Id: I621bdad8ea084470a2724163f614578caf8f2dd5

Convert location_spec_type to a method

This converts location_spec_type to location_spec::type().

Change-Id: Iff4cbfafb1cf3d22adfa142ff939b4a148e52273

Convert location_spec_empty_p to a method

This converts location_spec_empty_p to a method of location_spec,
simplifying users, as they no longer have to use
std::unique_ptr::get().

Change-Id: I83381a729896f12e1c5a1b4d6d4c2eb1eb6582ff

Eliminate copy_location_spec

copy_location_spec is just a wrapper around location_spec::clone(), so
remove it and call clone() directly.  This simplifies users, as they
no longer have to use std::unique_ptr::get().

Change-Id: I8ce8658589460b98888283b306b315a5b8f73976

Eliminate the two-level data structures behind location_specs

Currently, there's the location_spec hierarchy, and then some
location_spec subclasses have their own struct type holding all their
data fields.

I.e., there is this:

 location_spec
   explicit_location_spec
   linespec_location_spec
   address_location_spec
   probe_location_spec

and then these separate types:

  explicit_location
  linespec_location

where:

  explicit_location_spec
     has-a explicit_location
  linespec_location_spec
     has-a linespec_location

This patch eliminates explicit_location and linespec_location,
inlining their members in the corresponding location_spec type.

The location_spec subclasses were the ones currently defined in
location.c, so they are moved to the header.  Since the definitions of
the classes are now visible, we no longer need location_spec_deleter.

Some constructors that are used for cloning location_specs, like:

  explicit explicit_location_spec (const struct explicit_location *loc)

... were converted to proper copy ctors.

In the process, initialize_explicit_location is eliminated, and some
functions that returned the "data type behind a locspec", like
get_linespec_location are converted to downcast functions, like
as_linespec_location_spec.

Change-Id: Ia31ccef9382b25a52b00fa878c8df9b8cf2a6c5a

event_location -> location_spec

Currently, GDB internally uses the term "location" for both the
location specification the user input (linespec, explicit location, or
an address location), and for actual resolved locations, like the
breakpoint locations, or the result of decoding a location spec to
SaLs.  This is expecially confusing in the breakpoints module, as
struct breakpoint has these two fields:

  breakpoint::location;
  breakpoint::loc;

"location" is the location spec, and "loc" is the resolved locations.

And then, we have a method called "locations()", which returns the
resolved locations as range...

The location spec type is presently called event_location:

  /* Location we used to set the breakpoint.  */
  event_location_up location;

and it is described like this:

  /* The base class for all an event locations used to set a stop event
     in the inferior.  */

  struct event_location
  {

and even that is incorrect...  Location specs are used for finding
actual locations in the program in scenarios that have nothing to do
with stop events.  E.g., "list" works with location specs.

To clean all this confusion up, this patch renames "event_location" to
"location_spec" throughout, and then all the variables that hold a
location spec, they are renamed to include "spec" in their name, like
e.g., "location" -> "locspec".  Similarly, functions that work with
location specs, and currently have just "location" in their name are
renamed to include "spec" in their name too.

Change-Id: I5814124798aa2b2003e79496e78f95c74e5eddca

gprofng: fix build with -Werror=format-truncation

gprofng/ChangeLog
2022-06-16  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

* configure.ac: Remove -Wno-format-truncation.
* src/Makefile.am: Likewise.
* configure: Rebuild.
* src/Makefile.in: Rebuild.
* common/hwctable.c: Fix -Werror=format-truncation errors.
* src/ipc.cc: Likewise.
* src/parse.cc: Likewise.

Automatic date update in version.in

[gdb/testsuite] Fix have_mpx test

When testing on openSUSE Leap 15.4 I ran into this FAIL:
...
FAIL: gdb.arch/i386-mpx-map.exp: NULL address of the pointer
...
and likewise for all the other mpx tests.

The problem is that have_mpx is supposed to return 0, but it doesn't because
it tries to match this output:
...
builtin_spawn -ignore SIGHUP temp/20294/have_mpx-2-20294.x^M
No MPX support^M
No MPX support^M
...
using:
...
                   && ![string equal $output "No MPX support\r\n"]]
...

Fix this by matching using a regexp instead.

Tested on x86_64-linux.

use of uninitialised value in input_file_open

Triggered by a file containing just "#N" or "#A".  fgets when hitting
EOF before reading anything returns NULL and does not write to buf.
strchr (buf, '\n') then is reading from uninitialised memory.

* input-file.c (input_file_open): Don't assume buf contains
zero string terminator when fgets returns NULL.

Always free matching vector from bfd_check_format_matches

At least one place calling list_matching_formats failed to free the
"matching" vector from bfd_check_format_matches afterwards.  Fix that
by calling free inside list_matching_formats.

binutils/
* bucomm.c (list_matching_formats): Free arg.
* addr2line.c (process_file): Adjust to suit.
* ar.c (open_inarch, ranlib_touch): Likewise.
* coffdump.c (main): Likewise.
* nm.c (display_archive, display_file): Likewise.
* objcopy.c (copy_file): Likewise.
* objdump.c (display_object_bfd): Likewise.
* size.c (display_bfd): Likewise.
* srconv.c (main): Likewise.
ld/
* ldlang.c (load_symbols): Free "matching".

Revert "Revert "Fix fbsd core matching""

This reverts commit 476288fa2bddecf0f0e13dee826a076309bf01fe.

Restore readelf -wF

Commit 94585d6d4495 resulted in readelf -wF failing with
Unrecognized debug letter option 'F'

binutils/
* dwarf.c (debug_dump_long_opts): Add letter.
(debug_option_table): New, replacing..
(opts_table, letter_table): ..these.
(dwarf_select_sections_by_names): Adjust to suit.  Set
do_debug_frames outside of loop.
(dwarf_select_sections_by_letters): Similarly.
gas/
* testsuite/gas/i386/ehinterp.d: Use readelf -wF.

PR29250, readelf erases CIE initial register state

PR 29250
binutils/
* dwarf.c (display_debug_frames): Set col_type[reg] on sizing
pass over FDE to cie->col_type[reg] if CIE specifies reg.
Handle DW_CFA_restore and DW_CFA_restore_extended on second
pass using the same logic.  Remove unnecessary casts.  Don't
call frame_need_space on second pass over FDE.
gas/
* testsuite/gas/i386/ehinterp.d,
* testsuite/gas/i386/ehinterp.s: New test.
* testsuite/gas/i386/i386.exp: Run it.

Automatic date update in version.in

sim: fix BFD_VMA format arguments on 32-bit hosts [PR gdb/29184]

Noticed format mismatch when attempted to build gdb on i686-linux-gnu
in --enable-64-bit-bfd mode:

    sim/../../sim/cris/sim-if.c:576:28:
        error: format '%lx' expects argument of type 'long unsigned int',
        but argument 4 has type 'bfd_size_type' {aka 'long long unsigned int'} [-Werror=format=]
      576 |       sim_do_commandf (sd, "memory region 0x%" BFD_VMA_FMT "x,0x%lx",
          |                            ^~~~~~~~~~~~~~~~~~~
      577 |          interp_load_addr, interpsiz);
          |                            ~~~~~~~~~
          |                            |
          |                            bfd_size_type {aka long long unsigned int}

While at it fixed format string for time-related types.

Check for listeners in emit_exiting_event

I noticed that emit_exiting_event does not check whether there are any
listeners before creating the event object.  All other event emitters
do this, so this patch updates this one as well.

Add to documentation of Python 'dont_repeat' method

PR python/28533 points out that the Python 'dont_repeat' documentation
is a bit ambiguous about when the method ought to be called.  This
patch spells it out.

gdb/arm: Make sp alias for one of the other stack pointers

For Cortex-M targets, SP register is never detached from msp or
psp, it always has the same value as one of them.  Let GDB treat
ARM_SP_REGNUM as an alias similar to what is done in hardware.

Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
Signed-off-by: Yvan Roux <yvan.roux@foss.st.com>

gdb/arm: Track msp and psp

For Arm Cortex-M33 with security extensions, there are 4 different
stack pointers (msp_s, msp_ns, psp_s, psp_ns).  To be compatible
with earlier Cortex-M derivates, the msp and psp registers are
aliases for one of the 4 real stack pointer registers.

These are the combinations that exist:
sp -> msp -> msp_s
sp -> msp -> msp_ns
sp -> psp -> psp_s
sp -> psp -> psp_ns

This means that when the GDB client is to show the value of "msp",
the value should always be equal to either "msp_s" or "msp_ns".
Same goes for "psp".

To add a bit more context; GDB does not really use the register msp
(or psp) internally, but they are part of the set of registers which
are provided by the target.xml file.  As a result, they will be part
of the set of registers printed by the "info r" command.

Without this particular patch, GDB will hit the assert in the bottom
of arm_cache_get_sp_register function.

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

Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
Signed-off-by: Yvan Roux <yvan.roux@foss.st.com>

gdb/arm: Fetch initial sp value prior to compare

For Arm Cortex-M33 with security extensions, there are 4 different
stack pointers (msp_s, msp_ns, psp_s, psp_ns).  In order to
identify the active one, compare the values of the different
stacks. The value of the initial sp register needs to be fetched to
perform this comparison.

Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
Signed-off-by: Yvan Roux <yvan.roux@foss.st.com>

gdb: unify two dis_asm_read_memory functions in disasm.c

After the recent restructuring of the disassembler code, GDB has ended
up with two identical class static functions, both called
dis_asm_read_memory, with identical implementations.

My first thought was to move these out of their respective classes,
and just make them global functions, then I'd only need a single
copy.

And maybe that's the right way to go.  But I disliked that by doing
that I loose the encapsulation of the method with the corresponding
disassembler class.

So, instead, I placed the static method into its own class, and had
both the gdb_non_printing_memory_disassembler and gdb_disassembler
classes inherit from this new class as an additional base-class.

In terms of code generated, I don't think there's any significant
difference with this approach, but I think this better reflects how
the function is closely tied to the disassembler.

There should be no user visible changes after this commit.

gdb: refactor the non-printing disassemblers

This commit started from an observation I made while working on some
other disassembler patches, that is, that the function
gdb_buffered_insn_length, is broken ... sort of.

I noticed that the gdb_buffered_insn_length function doesn't set up
the application data field if the disassemble_info structure.

Further, I noticed that some architectures, for example, ARM, require
that the application_data field be set, see gdb_print_insn_arm in
arm-tdep.c.

And so, if we ever use gdb_buffered_insn_length for ARM, then GDB will
likely crash.  Which is why I said only "sort of" broken.  Right now
we don't use gdb_buffered_insn_length with ARM, so maybe it isn't
broken yet?

Anyway to prove to myself that there was a problem here I extended the
disassembler self tests in disasm-selftests.c to include a test of
gdb_buffered_insn_length.  As I run the test for all architectures, I
do indeed see GDB crash for ARM.

To fix this we need gdb_buffered_insn_length to create a disassembler
that inherits from gdb_disassemble_info, but we also need this new
disassembler to not print anything.

And so, I introduce a new gdb_non_printing_disassembler class, this is
a disassembler that doesn't print anything to the output stream.

I then observed that both ARC and S12Z also create non-printing
disassemblers, but these are slightly different.  While the
disassembler in gdb_non_printing_disassembler reads the instruction
from a buffer, the ARC and S12Z disassemblers read from target memory
using target_read_code.

And so, I further split gdb_non_printing_disassembler into two
sub-classes, gdb_non_printing_memory_disassembler and
gdb_non_printing_buffer_disassembler.

The new selftests now pass, but otherwise, there should be no user
visible changes after this commit.

gdb/python: implement the print_insn extension language hook

This commit extends the Python API to include disassembler support.

The motivation for this commit was to provide an API by which the user
could write Python scripts that would augment the output of the
disassembler.

To achieve this I have followed the model of the existing libopcodes
disassembler, that is, instructions are disassembled one by one.  This
does restrict the type of things that it is possible to do from a
Python script, i.e. all additional output has to fit on a single line,
but this was all I needed, and creating something more complex would,
I think, require greater changes to how GDB's internal disassembler
operates.

The disassembler API is contained in the new gdb.disassembler module,
which defines the following classes:

  DisassembleInfo

      Similar to libopcodes disassemble_info structure, has read-only
  properties: address, architecture, and progspace.  And has methods:
  __init__, read_memory, and is_valid.

      Each time GDB wants an instruction disassembled, an instance of
  this class is passed to a user written disassembler function, by
  reading the properties, and calling the methods (and other support
  methods in the gdb.disassembler module) the user can perform and
  return the disassembly.

  Disassembler

      This is a base-class which user written disassemblers should
  inherit from.  This base class provides base implementations of
  __init__ and __call__ which the user written disassembler should
  override.

  DisassemblerResult

      This class can be used to hold the result of a call to the
  disassembler, it's really just a wrapper around a string (the text
  of the disassembled instruction) and a length (in bytes).  The user
  can return an instance of this class from Disassembler.__call__ to
  represent the newly disassembled instruction.

The gdb.disassembler module also provides the following functions:

  register_disassembler

      This function registers an instance of a Disassembler sub-class
  as a disassembler, either for one specific architecture, or, as a
  global disassembler for all architectures.

  builtin_disassemble

      This provides access to GDB's builtin disassembler.  A common
  use case that I see is augmenting the existing disassembler output.
  The user code can call this function to have GDB disassemble the
  instruction in the normal way.  The user gets back a
  DisassemblerResult object, which they can then read in order to
  augment the disassembler output in any way they wish.

      This function also provides a mechanism to intercept the
  disassemblers reads of memory, thus the user can adjust what GDB
  sees when it is disassembling.

The included documentation provides a more detailed description of the
API.

There is also a new CLI command added:

  maint info python-disassemblers

This command is defined in the Python gdb.disassemblers module, and
can be used to list the currently registered Python disassemblers.

gdb: add extension language print_insn hook

This commit is setup for the next commit.

In the next commit I will add a Python API to intercept the print_insn
calls within GDB, each print_insn call is responsible for
disassembling, and printing one instruction.  After the next commit it
will be possible for a user to write Python code that either wraps
around the existing disassembler, or even, in extreme situations,
entirely replaces the existing disassembler.

This commit does not add any new Python API.

What this commit does is put the extension language framework in place
for a print_insn hook.  There's a new callback added to 'struct
extension_language_ops', which is then filled in with nullptr for Python
and Guile.

Finally, in the disassembler, the code is restructured so that the new
extension language function ext_lang_print_insn is called before we
delegate to gdbarch_print_insn.

After this, the next commit can focus entirely on providing a Python
implementation of the new print_insn callback.

There should be no user visible change after this commit.

gdb: add new base class to gdb_disassembler

The motivation for this change is an upcoming Python disassembler API
that I would like to add.  As part of that change I need to create a
new disassembler like class that contains a disassemble_info and a
gdbarch.  The management of these two objects is identical to how we
manage these objects within gdb_disassembler, so it might be tempting
for my new class to inherit from gdb_disassembler.

The problem however, is that gdb_disassembler has a tight connection
between its constructor, and its print_insn method.  In the
constructor the ui_file* that is passed in is replaced with a member
variable string_file*, and then in print_insn, the contents of the
member variable string_file are printed to the original ui_file*.

What this means is that the gdb_disassembler class has a tight
coupling between its constructor and print_insn; the class just isn't
intended to be used in a situation where print_insn is not going to be
called, which is how my (upcoming) sub-class would need to operate.

My solution then, is to separate out the management of the
disassemble_info and gdbarch into a new gdb_disassemble_info class,
and make this class a parent of gdb_disassembler.

In arm-tdep.c and mips-tdep.c, where we used to cast the
disassemble_info->application_data to a gdb_disassembler, we can now
cast to a gdb_disassemble_info as we only need to access the gdbarch
information.

Now, my new Python disassembler sub-class will still want to print
things to an output stream, and so we will want access to the
dis_asm_fprintf functionality for printing.

However, rather than move this printing code into the
gdb_disassemble_info base class, I have added yet another level of
hierarchy, a gdb_printing_disassembler, thus the class structure is
now:

  struct gdb_disassemble_info {};
  struct gdb_printing_disassembler : public gdb_disassemble_info {};
  struct gdb_disassembler : public gdb_printing_disassembler {};

In a later commit my new Python disassembler will inherit from
gdb_printing_disassembler.

The reason for adding the additional layer to the class hierarchy is
that in yet another commit I intend to rewrite the function
gdb_buffered_insn_length, and to do this I will be creating yet more
disassembler like classes, however, these will not print anything,
thus I will add a gdb_non_printing_disassembler class that also
inherits from gdb_disassemble_info.  Knowing that that change is
coming, I've gone with the above class hierarchy now.

There should be no user visible changes after this commit.

gdb/python: convert gdbpy_err_fetch to use gdbpy_ref

Convert the gdbpy_err_fetch class to make use of gdbpy_ref, this
removes the need for manual reference count management, and allows the
destructor to be removed.

There should be no functional change after this commit.

I think this cleanup is worth doing on its own, however, in a later
commit I will want to copy instances of gdbpy_err_fetch, and switching
to using gdbpy_ref means that I can rely on the default copy
constructor, without having to add one that handles the reference
counts, so this is good preparation for that upcoming change.

x86: drop print_operand_value()'s "hex" parameter

For quite some  time all callers have been passing 1 / true. While there
fold the final oappend_with_style() calls.

[gdb/build] Fix build for gcc < 11

When building trunk on openSUSE Leap 15.3 with system gcc 7.5.0, I run into:
...
In file included from ../bfd/bfd.h:46:0,
                 from gdb/defs.h:37,
                 from gdb/debuginfod-support.c:19:
gdb/debuginfod-support.c: In function ‘bool debuginfod_is_enabled()’:
gdb/../include/diagnostics.h:42:3: error: unknown option after \
  ‘#pragma GCC diagnostic’ kind [-Werror=pragmas]
   _Pragma (DIAGNOSTIC_STRINGIFY (GCC diagnostic ignored option))
   ^
gdb/../include/diagnostics.h:80:3: note: in expansion of macro \
  ‘DIAGNOSTIC_IGNORE’
   DIAGNOSTIC_IGNORE ("-Wstringop-overread")
   ^~~~~~~~~~~~~~~~~
gdb/debuginfod-support.c:201:4: note: in expansion of macro \
  ‘DIAGNOSTIC_IGNORE_STRINGOP_OVERREAD’
    DIAGNOSTIC_IGNORE_STRINGOP_OVERREAD
    ^
...

The problem is that the warning -Wstringop-overread has been introduced for
gcc 11, and we can only tell gcc to ignore if it knows about it.

Fix this by guarding the DIAGNOSTIC_IGNORE_STRINGOP_OVERREAD definition in
diagnostics.c with '#if __GNUC__ >= 11'.

Tested on x86_64-linux, by completing a build.

PR29230, segv in lookup_symbol_in_variable_table

The PR23230 testcase uses indexed strings without specifying
SW_AT_str_offsets_base.  In this case we left u.str with garbage (from
u.val) which then led to a segfault when attempting to access the
string.  Fix that by clearing u.str.  The patch also adds missing
sanity checks in the recently committed read_indexed_address and
read_indexed_string functions.

PR 29230
* dwarf2.c (read_indexed_address): Return uint64_t.  Sanity check idx.
(read_indexed_string): Use uint64_t for str_offset.  Sanity check idx.
(read_attribute_value): Clear u.str for indexed string forms when
DW_AT_str_offsets_base is not yet read or missing.

gdb: Always suppress stringop-overread warning in debuginfod-support.c

Just like on s390x with g++ 11.2.1 and ppc64le with g++ 11.3.1 g++ 11
on hppa produces a spurious warning for stringop-overread in
debuginfod_is_enabled for url_view. Just always suppress it on all
arches.

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

gdb/ChangeLog:

* debuginfod-support.c (debuginfod_is_enabled): Always use
DIAGNOSTIC_IGNORE_STRINGOP_OVERREAD.

Automatic date update in version.in

gprofng docs: provide help for <rate> == <interval>

The help message from 'gprofng collect app -h', in
the section on <rate> == <interval>, had a dangling
reference to a non-existent manpage. Provide basic
info, including reasons for caution.

gprofng docs: mention HTML / PDF in the gprofng README

The HTML and PDF formats are described in the gprofng tutorial (info
topic "Other Document Formats"). In addition, describe them in the
README because: they are important; they are easily searchable; and the
README is primarily oriented to the person who is installing gprofng,
who may differ from the person who follows a user tutorial.

gprofng: fix build with -Werror=format-security

gprofng/ChangeLog
2022-06-13  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

PR gprofng/28968
* src/src/Hist_data.cc (print_row): Make param const.
* src/src/Hist_data.h (print_row): Likewise.
* src/src/Print.h: Remove unused functions and variables.
* src/Print.cc: Fix -Werror=format-security errors.
* src/parse.cc: Likewise.

[gdb/testsuite] Handle unordered dict in gdb.python/py-mi-cmd.exp

When running test-case gdb.python/py-mi-cmd.exp on openSUSE Leap 42.3 with
python 3.4, I occasionally run into:
...
Expecting: ^(-pycmd dct[^M
]+)?(\^done,result={hello="world",times="42"}[^M
]+[(]gdb[)] ^M
[ ]*)
-pycmd dct^M
^done,result={times="42",hello="world"}^M
(gdb) ^M
FAIL: gdb.python/py-mi-cmd.exp: -pycmd dct (unexpected output)
...

The problem is that the data type used here in py-mi-cmd.py:
...
        elif argv[0] == "dct":
            return {"result": {"hello": "world", "times": 42}}
...
is a dictionary, and only starting version 3.6 are dictionaries insertion
ordered, so using PyDict_Next in serialize_mi_result doesn't guarantee a
fixed order.

Fix this by allowing the alternative order.

Tested on x86_64-linux.

Implement lazy FPU initialization for ravenscar

Some ravenscar runtimes implement lazy FPU handling.  On these
runtimes, the FPU is only initialized when a task tries to use it.
Furthermore, the FP registers aren't automatically saved on a task
switch -- instead, the save is deferred until the new task tries to
use the FPU.  Furthermore, each task's context area has a flag
indicating whether the FPU has been initialized for this task.

This patch teaches GDB to understand this implementation.  When
fetching or storing registers, GDB now checks to see whether the live
FP registers should be used.  If not, the task's saved FP registers
will be used if the task has caused FPU initialization.

Currently only AArch64 uses this code.  bb-runtimes implements this
for ARM as well, but GDB doesn't yet have an arm-ravenscar-thread.c.

Reimplement ravenscar registers using tables

Currently, the ravenscar-thread implementation for each architecture
is written by hand.  However, these are actually written by
copy-paste.  It seems better to switch to a table-driven approach.

The previous code also fetched all registers whenever any register was
requested.  This is corrected in the new implementation.

Fix bugs in aarch64-ravenscar-thread.c

We found a few bugs in aarch64-ravenscar-thread.c.

First, some of the register offsets were incorrect.  The "bb-runtimes"
file for this runtime had the wrong offsets in comments, which GDB
took to be correct.  However, those comments didn't account for
alignment.  This patch adjusts the offsets.

Next, the "FPU Saved field" is not a register -- it is an
implementation detail of the runtime.  This is removed.

Finally, I think the FP registers are actually named V0-V31, and the
"Q" names are pseudo-registers.  This patch fixes the comment.

Allow 'interrupt -a' in all-stop mode

PR gdb/17160 points out that "interrupt -a" errors in all-stop mode,
but there's no good reason for this.  This patch removes the error.

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

gdbserver: Add LoongArch/Linux support

Implement LoongArch/Linux support, including XML target description
handling based on features determined, GPR regset support, and software
breakpoint handling.

In the Linux kernel code of LoongArch, ptrace implements PTRACE_POKEUSR
and PTRACE_PEEKUSR in the arch_ptrace function, so srv_linux_usrregs is
set to yes.

With this patch on LoongArch:

  $ make check-gdb TESTS="gdb.server/server-connect.exp"
  [...]
  # of expected passes 18
  [...]

Signed-off-by: Youling Tang <tangyouling@loongson.cn>
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>

Revert "Fix fbsd core matching"

This reverts commit a7e29f797cecd5a2f73c27838b09eae1f1b6c657.

I accidentally pushed this, so revert.

[gdb/testsuite] Fix regexp in gdb.ada/mi_var_access.exp

With gcc-12 and target board unix/-m32, we run into:
...
(gdb) ^M
Expecting: ^(-var-create A_String_Access \* A_String_Access[^M
]+)?(\^done,name="A_String_Access",numchild="1",.*[^M
]+[(]gdb[)] ^M
[ ]*)
-var-create A_String_Access * A_String_Access^M
^error,msg="Value out of range."^M
(gdb) ^M
FAIL: gdb.ada/mi_var_access.exp: Create varobj (unexpected output)
...

What happens is easier to understand if we take things out of the mi context:
...
$ gdb -q -batch \
    outputs/gdb.ada/mi_var_access/mi_access \
    -ex "b mi_access.adb:19" \
    -ex run \
    -ex "p A_String_Access"
  ...
Breakpoint 1, mi_access () at mi_access.adb:19
19         A_String : String (3 .. 5) := "345"; -- STOP
$1 = (pck.string_access) <error reading variable: Value out of range.>
...
while with target board unix we have instead:
...
$1 = (pck.string_access) 0x431b40 <ada_main.sec_default_sized_stacks>
...

The var-create command samples the value of the variable at a location where
the variable is not yet initialized, and with target board unix we
accidentally hit a valid address, but with target board unix/-m32 that's not
the case.

Fix the FAIL by accepting the error message.

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

Fix fbsd core matching

On Thu, Jun 09, 2022 at 08:59:37AM -0700, John Baldwin wrote:
> On 6/9/22 1:58 AM, Tom de Vries via Gdb-patches wrote:
> > Hi,
> >
> > With an --enable-targets=all build and target board unix/-m32 I run into a
> > FAIL in test-case gdb.base/corefile.exp:
> > ...
> > (gdb) file outputs/gdb.base/corefile/corefile^M
> > Reading symbols from outputs/gdb.base/corefile/corefile...^M
> > (gdb) core-file outputs/gdb.base/corefile/corefile.core^M
> > warning: core file may not match specified executable file.^M
> > [New LWP 12011]^M
> > Core was generated by `outputs/gdb.base/corefile/co'.^M
> > Program terminated with signal SIGABRT, Aborted.^M
> > (gdb) FAIL: gdb.base/corefile.exp: core-file warning-free
> > ...
> >
> > The warning is there because of this mismatch between core and exec:
> > ...
> > (gdb) p core_bfd->xvec
> > $3 = (const struct bfd_target *) 0x20112a0 <i386_elf32_fbsd_vec>
> > (gdb) p exec_bfd->xvec
> > $4 = (const struct bfd_target *) 0x2010b00 <i386_elf32_vec>
> > ...
> >
> > In the exec case, the detected architecture is i386_elf32_vec because this bit
> > of code in elfcode.h:elf_object_p():
> > ...
> >    if (ebd->elf_machine_code != EM_NONE
> >        && i_ehdrp->e_ident[EI_OSABI] != ebd->elf_osabi
> >        && ebd->elf_osabi != ELFOSABI_NONE)
> >      goto got_wrong_format_error;
> > ...
> > prevents i386_elf32_fbsd from matching.
> >
> > Fix the core matching by copying that code to elfcore.h:elf_core_file_p().
> >
> > Tested on x86_64-linux.
> >
> > Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29227
> >
> > Any comments?

Looks good.

> Looking at elfcore.h, it seems to have not gotten changes made to elfcode.h over
> time and is a bit rotted.  I suspect that all of changes made in commit 0aabe54e6222
> that added these lines in elfcode.h (along with several other changes) need to
> be applied to this function in elfcore.h, not just adding these lines.

Yes, the commit 0aabe54e6222 changes likely should go in too.  I'm a
little wary of adding all the sanity checks to elf_core_file_p since
that might result in some core files not being recognised at all.  For
example, despite the FIXME I'd guess leaving out the EI_VERSION check
was deliberate.  The following seems reasonable to me.  Please test.

Debug support for global alias variable

Starting with (future) Clang 15 (since
https://reviews.llvm.org/D120989), Clang emits the DWARF information
of global alias variables as DW_TAG_imported_declaration.  However,
GDB does not handle it.  It incorrectly always reads this tag as
C++/Fortran imported declaration (type alias, namespace alias and
Fortran module).  This commit adds support to handle this tag as an
alias variable.

This change fixes the failures in the gdb.base/symbol-alias.exp
testcase with current git Clang.  This testcase is also updated to
test nested (recursive) aliases.

BFD_RELOC_MIPS_16

MIPS should not be using BFD_RELOC_16 for its R_MIPS_16 relocation,
since R_MIPS_16 specifies a 16-bit field in a 32-bit word.
BFD_RELOC_16, emitted by generic code to handle fixups on 16-bit data
directives, expects fixups to operate on the whole of a 16-bit word.

This patch corrects the problem by using BFD_RELOC_MIPS_16, a new bfd
reloc that is used to generate R_MIPS_16.  BFD_RELOC_16 is handled in
md_apply_fix for cases where the fixup can be applied at assembly
time.  Like BFD_RELOC_8, BFD_RELOC_16 now has no corresponding object
file relocation, and thus .half, .hword, .short and .dc.w must be
resolved at assembly time.  BFD_RELOC_MIPS_REL16 is removed by this
patch since it isn't used.

PR 3243
PR 26542
* reloc.c (BFD_RELOC_MIPS_16): Rename from BFD_RELOC_MIPS_REL16.
* elf32-mips.c (mips_reloc_map): Map BFD_RELOC_MIPS_16 to R_MIPS_16.
* elf64-mips.c (mips_reloc_map): Likewise, delete BFD_RELOC_MIPS_REL16.
* elfn32-mips.c (mips_reloc_map): Likewise.
* libbfd.h: Regenerate.
* bfd-in2.h: Regenerate.
gas/
* config/tc-mips.c (append_insn): Handle BFD_RELOC_MIPS_16.
(macro_build): Likewise.
(mips_percent_op <%half>): Generate BFD_RELOC_MIPS_16.
(md_apply_fix): Handle BFD_RELOC_16 and BFD_RELOC_MIPS_16 when fx_done.
ld/
* testsuite/ld-mips-elf/reloc-local-overflow.d,
* testsuite/ld-mips-elf/reloc-local-overflow.s: Rewrite.

Correct R_MIPS_16 n32 howto

If the howto is actually used, an all-zero dst_mask will result in
unchanged section contents on attempting to apply R_MIPS_16.

* elfn32-mips.c (elf_mips_howto_table_rela <R_MIPS_16>): Correct
dst_mask.

asan: applying zero offset to NULL pointer

* dwarf.c (fetch_indexed_string): Move initialisation of "curr"
and "end" after checking for missing section.

gas dwarf2dbg.c tidy

Make it a little more obvious that remap_debug_filename returns an
allocated string (that should be freed) by returning a char * rather
than const char *.  Free a few missed cases in dwarf2dbg.c, and free
other memory allocated in dwarf2dbg.c.  Also remove static
initialisation of variables and initialise in dwarf2_init instead,
in order to ensure gas state is saner for oss-fuzz.

* remap.c (remap_debug_filename): Remove const from return.
* as.h (remap_debug_filename): Update prototype.
* config/obj-elf.c (obj_elf_ident): Simplify free of
remap_debug_filename output.
* stabs.c (stabs_generate_asm_file): Likewise.
* dwarf2dbg.c (dirs, dirs_in_use, dirs_allocated, current): Don't
initialise statically..
(dwarf2_init): ..do so here, along with most other static vars.
(assign_file_to_slot): Don't set files_allocated until we
succeed in allocating memory.
(purge_generated_debug): Add bool param, free more stuff if true.
(dwarf2_directive_filename): Adjust purge_generated_debug call.
(process_entries): Don't free line_entry here..
(dwarf2_cleanup): ..do so here instead, new function.
(dwarf2_finish): Call dwarf2_cleanup.  When chaining together
subseg line entries, unhook entries from old subseg list.
(dwarf2_directive_loc): Free remap_debug_filename string.
(out_dir_and_file_list): Likewise.
(out_debug_str): Likewise.

Automatic date update in version.in

[gdb/testsuite] Fix gdb.reverse/test_ioctl_TCSETSW.exp with libc debuginfo

When running test-case gdb.reverse/test_ioctl_TCSETSW.exp with glibc debuginfo
installed, I run into:
...
(gdb) PASS: gdb.reverse/test_ioctl_TCSETSW.exp: at TCSETSW call
step^M
__tcsetattr (fd=0, optional_actions=1, termios_p=0x7fffffffcf50) at \
  ../sysdeps/unix/sysv/linux/tcsetattr.c:45^M
45      {^M
(gdb) FAIL: gdb.reverse/test_ioctl_TCSETSW.exp: handle TCSETSW
...

The problem is that the step is expected to step over the call to tcsetattr,
but due to glibc debuginfo being installed, we step into the call.

Fix this by using next instead of step.

Tested on x86_64-linux.

[gdb] Avoid warnings in cooked_{read,write}_test for m68hc11

With --enable-targets=all we have:
...
$ gdb -q -batch -ex "maint selftest"
  ...
Running selftest regcache::cooked_read_test::m68hc11.
warning: No frame soft register found in the symbol table.
Stack backtrace will not work.
Running selftest regcache::cooked_read_test::m68hc12.
warning: No frame soft register found in the symbol table.
Stack backtrace will not work.
Running selftest regcache::cooked_read_test::m68hc12:HCS12.
warning: No frame soft register found in the symbol table.
Stack backtrace will not work.
...

Likewise for regcache::cooked_write_test.

The warning has no use in the selftest context.

Fix this by skipping the specific selftests.

Tested on x86_64-linux.

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

gdb: LoongArch: Deal with atomic sequence

We can't put a breakpoint in the middle of a ll/sc atomic sequence,
so look for the end of the sequence and put the breakpoint there.

Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>

gdb: don't use bashism in configure test

Results in configure output like:
```
checking for X... no
/var/tmp/portage/sys-devel/gdb-12.1/work/gdb-12.1/gdb/configure: 18837: test: yes: unexpected operator
checking whether to use babeltrace... auto
```

... when /bin/sh is provided by a POSIX-compliant shell, like dash,
instead of bash.

gdb:csky add support target-descriptions for CSKY arch

Registers in CSKY architecture included:
1. 32 gprs
2. 16 ars (alternative gprs used for quick interrupt)
3. hi, lo, pc
4. fr0~fr31, fcsr, fid, fesr
5. vr0~vr15
6. ((32 banks) * 32) cr regs (max 32 banks, 32 control regs a bank)

For register names:
Except over control registers, other registers, like gprs, hi, lo ...
are fixed names. Among the 32*32 control registers, some used registers
will have fixed names, others will have a default name "cpxcry". 'x'
refers to bank, y refers index in the bank(a control register in bank
4 with index 14 will has a default name cp4cr14).

For register numbers in GDB:
We assign a fixed number to each register in GDB, like:
r0~r31 with 0~31
hi, lo with 36, 37
fpu/vpu with 40~71
...
described in function csky_get_supported_register_by_index().

Function csky_get_supported_tdesc_registers_count():
To calculate the total number of registers that GDB can analyze,
including those with fixed names and those with default register names.

Function csky_get_supported_register_by_index():
To find a supported struct csky_supported_tdesc_register, return a
struct include name with regnum via index.

Arrays csky_supported_tdesc_feature_names[]:
Include all supported feature names in tdesc-xmls.

We use the information described above to load the register description
file of the target from the stub. When loading, do a little check that
whether the register description file contains SP, LR and PC.

[gdb/testsuite] Handle quotes in gdb_py_module_available

On openSUSE Leap 42.3 with python 3.4, I run into:
...
(gdb) python import pygments^M
Traceback (most recent call last):^M
  File "<string>", line 1, in <module>^M
ImportError: No module named 'pygments'^M
Error while executing Python code.^M
(gdb) FAIL: gdb.base/style.exp: python import pygments
ERROR: unexpected output from python import
...
because gdb_py_module_available doesn't handle the single quotes around the
module name in the ImportError.

Fix this by allowing the single quotes.

Tested on x86_64-linux.

x86: fix incorrect indirection

Commit 384e201e5aec ("x86: properly initialize struct instr_info
instance(s)") was based on an improperly refreshed patch. Correct the
oversight.

x86: replace global scratch buffer

With its movement to the stack, and with the subsequent desire to
initialize the entire instr_info instances, this has become doubly
inefficient. Individual users have better knowledge of how big a buffer
they need, and in a number of cases going through an intermediate buffer
can be avoided altogether.

Having got confirmation that it wasn't intentional to print memory
operand displacements with inconsistent style, print_displacement() is
now using dis_style_address_offset consistently (eliminating the need
for callers to pass in a style).

While touching print_operand_value() also convert its "hex" parameter to
bool. And while altering (and moving) oappend_immediate(), fold
oappend_maybe_intel_with_style() into its only remaining caller. Finally
where doing adjustments, use snprintf() in favor of sprintf().

x86: avoid string copy when swapping Vex.W controlled operands

Now that op_out[] is an array of pointers, there's no need anymore to
copy strings. Simply swap the pointers.

x86: shrink prefix related disassembler state fields

By changing the values used for "artificial" prefix values,
all_prefixes[] can be shrunk to array of unsigned char. All that
additionally needs adjusting is the printing of possible apparently
standalone prefixes when recovering from longjmp(): Simply check
whether any prefixes were successfully decoded, to avoid converting
opcode bytes matching the "artificial" values to prefix mnemonics.

Similarly by re-arranging the bits assigned to PREFIX_* mask values
we can fit all segment register masks in a byte and hence shrink
active_seg_prefix to unsigned char.

Somewhat similarly with last_*_prefix representing offsets into the
opcode being disassembled, signed char is sufficient to hold all possible
values.

x86: properly initialize struct instr_info instance(s)

Commit 39fb369834a3 ("opcodes: Make i386-dis.c thread-safe") introduced
a lot of uninitialized data. Alan has in particular observed ubsan
taking issue with the loop inverting the order of operands, where
op_riprel[] - an array of bool - can hold values other than 0 or 1.

Move instantiation of struct instr_info into print_insn() (thus having
just a single central point), and make use of C99 dedicated initializers
to fill fields right in the initializer where possible. This way all
fields not explicitly initialized will be zero-filled, which in turn
allows dropping of some other explicit initialization later in the
function or in ckprefix(). Additionally this removes a lot of
indirection, as all "ins->info" uses can simply become "info".

Make one further arrangement though, to limit the amount of data needing
(zero)initializing on every invocation: Convert the op_out structure
member to just an array of pointers, with the actual arrays living
inside print_insn() (and, as befoe, having just their 1st char filled
with nul).

While there, instead of adjusting print_insn()'s forward declaration,
arrange for no such declaration to be needed in the first place.

Automatic date update in version.in

Fix self-test failure in addrmap

Mark pointed out that my recent addrmap C++-ficiation changes caused a
regression in the self-tests.  This patch fixes the problem by
updating this test not to allocate the mutable addrmap on an obstack.

Remove psymtab_addrmap

While working on addrmaps, I noticed that psymtab_addrmap is no longer
needed now.  It was introduced in ancient times as an optimization for
DWARF, but no other symbol reader was ever updated to use it.  Now
that DWARF does not use psymtabs, it can be deleted.

Use malloc for mutable addrmaps

Mutable addrmaps currently require an obstack.  This was probably done
to avoid having to call splay_tree_delete, but examination of the code
shows that all mutable obstacks have a limited lifetime -- now it's
simple to treat them as ordinary C++ objects, in some cases
stack-allocating them, and have a destructor to make the needed call.
This patch implements this change.

Remove addrmap::create_fixed

addrmap::create_fixed is just a simple wrapper for 'new', so remove it
in favor of uses of 'new'.

Remove addrmap_create_mutable

This removes addrmap_create_mutable in favor of using 'new' at the
spots where the addrmap is created.

Remove addrmap wrapper functions

This removes the various addrmap wrapper functions in favor of simple
method calls on the objects themselves.

Move addrmap classes to addrmap.h

This moves the addrmap class definitions to addrmap.h.  This is safe
to do now that the contents are private.

Privacy for addrmap_mutable

This changes addrmap_mutable so that its data members are private.

Privacy for addrmap_fixed

This changes addrmap_fixed so that its data members are private.
It also makes struct addrmap_transition private as well.

Use inheritance for addrmap

This is a simply C++-ification of the basics of addrmap: it uses
virtual methods rather than a table of function pointers, and it
changes the concrete implementations to be subclasses.

Trivial fixes to Cygwin build after 8fea1a81

* Remove a stray semicolon
* Restore dropped nullptr program argument in use of create_process() under CYGWIN