[PATCH 0/8] gdb/s390: Add regular and fast tracepoint support.

["Marcin Kościelnicki" <koriakin@0x04.net>]

This patchset adds support for regular and fast tracepoints on
s390-ibm-linux-gnu and s390x-ibm-linux-gnu.  It depends on the following
yet-unlanded patches:

- https://sourceware.org/ml/gdb-patches/2016-01/msg00597.html (for 31-bit
  fast tracepoint support)
- https://sourceware.org/ml/gdb-patches/2016-01/msg00596.html (just
  a testsuite fix)
- https://sourceware.org/ml/gdb-patches/2016-01/msg00510.html (fixes
  setting a breakpoint and a tracepoint on the same location)

Patches 1-5 add working regular tracepoint support, patches 6-7 add
working fast tracepoint support on top of that, and patch 8 makes fast
tracepoints use compiled agent expressions.

Patches 1 and 7 are in target-independent code, the remaining ones
are in s390-specific code.

It has been tested on s390-ibm-linux-gnu and s390x-ibm-linux-gnu on
a z13 machine (without vector extensions).  The parts handling vector
extensions are untested.  It has also been regression-tested on x86_64.

There are 2 test failures still left in gdb.trace:

- gdb.trace/unavailable.exp: print derived_whole has 4 failures on 64-bit
  only.  The same failure happens on x86_64, so it's unlikely to be
  s390-specific.
- gdb.trace/mi-tsv-changed.exp: create delete modify: tvariable $tvar3
  modified is an intermittent failure.  It seems to be a race of some
  kind - in the failing runs, gdb shows the same messages, but in
  different order.  I strongly suspect this is a target-independent
  issues that only happens on s390 due to timing factors.

There are also three issues affecting s390 tracepoints that don't show
up in the testsuite:

1. Target independent: tfile format doesn't contain target information
   (tdesc).  While this affects all platforms with multiple tdescs
   (eg. x86_64 is unable to pull AVX registers from tfile for that
   reason), it horribly breaks 31-bit s390 with high GPRs - it has
   a completely different GPR layout from plain 31-bit s390, so the
   collected registers will be garbled.  I suppose the proper fix to
   that would be to add tdesc information to tfile format.  Unfortunately,
   I don't see a way to extend it in a backwards-compatible way.

2. Target independent: 32-bit (or 31-bit for us) IPA cannot be used with
   64-bit gdbserver, due to communication involving lots of structs with
   pointer types.  Fixing that would be quite involved, but possible
   (I don't suppose we have to maintain compatibility between IPA/gdbserver
   from different gdb versions?).

3. s390 specific: 31-bit gdbserver doesn't know about high GPRs, and
   cannot collect them if they're in use.  Seems fixable with average
   effort.  Unfortunately, fixing that will break tfile, unless (1)
   is fixed first...

These three interact in bad ways, summarised below:

- 64-bit linux, 64-bit gdbserver, 64-bit target: works OK, but you won't be
  able to see VX registers in tfile.

- 64-bit linux, 64-bit gdbserver, 31-bit target: 

  - no fast tracepoint support due to (2)
  - tfile completely broken due to (1)

- 64-bit linux, 31-bit gdbserver, 31-bit target:

  - works OK, but you won't be able to see VX registers or high GPRs at all,
    due to (3)
  - if (3) were fixed, tfile will be completely broken due to (1)

- 31-bit linux, 31-bit gdbserver, 31-bit target: works OK

In summary, there's no way at all to use fast tracepoints on 31-bit target
if what you want to collect involves high GPRs.  While there's support for
it in the IPA, it's currently disabled, to match what gdbserver supports.

Fast tracepoint support assumes z900+ CPU.  The g5/g6 CPUs only have jump
instuctions with +-64kiB of range, making them pretty much useless for
our purposes, so not much loss here.