Fix PR10378 which is SH relax bug.
Fix PR10373 which is SH relax bug.
x64-windows: Fix extraction of chained UNWIND_INFO

On x86_64-windows, GDB is unable to unwind past some code in
mswsock.dll. For instance:

    (gdb) bt
    #0  0x00000000778712fa in ntdll!ZwWaitForSingleObject ()
       from C:\Windows\SYSTEM32\ntdll.dll
    #1  0x000007fefcfb0f75 in WSPStartup ()
       from C:\Windows\system32\mswsock.dll
    Backtrace stopped: previous frame inner to this frame (corrupt stack?)

The UNWIND_INFO record for frame #1's PC has a UNW_FLAG_CHAININFO
flag, and so after having decoded this unwind record, GDB's decoder
next tries to locate the next unwind record on the chain. Unfortunately,
the location of that unwind info appears to be miscomputed. This is
the expression used:

         chain_vma = cache->image_base + unwind_info
           + sizeof (ex_ui) + ((codes_count + 1) & ~1) * 2 + 8;

The chain-info is expected to be right after the "Unwind codes
array" which is itself after all the fields of ex_ui's struct.
So the "+ 8" offset at the end should not be there.

Because of that extra offset, we were reading no longer processing
correct unwind info, leading the unwinder computing the wrong frame
size, computing the wrong return address, etc.

gdb/ChangeLog:

        * amd64-windows-tdep.c (amd64_windows_frame_decode_insns):
        Remove "+ 8" offset in computation of CHAIN_VMA.
Add debug trace in amd64-windows-tdep.c::amd64_windows_frame_decode_insns

This is a trace which would have been useful when trying to understand
why the debugger was not decoding the stream of unwind codes I was
expecting.  This patch adds a trace first informing us that we are
following the unwind info to the next unwind record in that chain.

gdb/ChangeLog:

        * amd64-windows-tdep.c (amd64_windows_frame_decode_insns):
        Add debug trace.
Handle variable-sized fields in the interior of structure type

In Ada, variable-sized field can be located at any position of
a structure. Consider for instance the following declarations:

   Dyn_Size : Integer := 1;

   type Table is array (Positive range <>) of Integer;

   type Inner is record
      T1 : Table (1 .. Dyn_Size) := (others => 1);
      T2 : Table (1 .. Dyn_Size) := (others => 2);
   end record;

   type Inner_Array is array (1 .. 2) of Inner;

   type Outer is
      record
         I0 : Integer := 0;
         A1 : Inner_Array;
         Marker : Integer := 16#01020304#;
      end record;

   Rt : Outer;

What this does is declare a variable "Rt" of type Outer, which
contains 3 fields where the second (A1) is of type Inner_Array.
type Inner_Array is an array with 2 elements of type Inner.
Because type Inner contains two arrays whose upper bound depend
on a variable, the size of the array, and therefore the size of
type Inner is dynamic, thus making field A1 a dynamically-size
field.

When trying to print the value of Rt, we hit the following limitation:

    (gdb) print rt
    Attempt to resolve a variably-sized type which appears in the interior of
    a structure type

The limitation was somewhat making sense in C, but needs to be lifted
for Ada. This patch mostly lifts that limitation. As a result of this
patch, the type length computation had to be reworked a little bit.

gdb/ChangeLog:

        * gdbtypes.c (resolve_dynamic_struct): Do not generate an error
        if detecting a variable-sized field that is not the last field.
        Fix struct type length computation.

gdb/testsuite/ChangeLog:

        * gdb.base/vla-datatypes.c (vla_factory): Add new variable
        inner_vla_struct_object_size.
        * gdb.base/vla-datatypes.exp: Adjust last test, and mark it
        as xfail.
[gdb/doc] Add target triplet to man files

After applying hash 43662968, gdb.1 and other man pages are not added
target triplet even if we configure with --target=.

It causes conflicts on some distributions.
And uninstall rules requires $(transform) variable.

gdb/doc/ChangeLog:

	* Makefile.in (transform): New variable.
	(install-man1, install-man5): Apply $(transform) to man file names.

Tested by installing both native and cross debugger.
daily update