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

Marcin Kościelnicki
2016-01-24T12:12:24Z

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.