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

Antoine Tremblay
2016-01-25T13:27:48Z

On 01/24/2016 07:12 AM, Marcin Kościelnicki wrote:
>
> 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.

I've had this problem too with tracepoint support for arm.. for me it
creates problems in the test suite see : unavailable locals,
https://sourceware.org/ml/gdb-patches/2016-01/msg00113.html

I'm also wondering how this could be fixed...

This patch might also be of interest for targets with multiple tdesc:
https://sourceware.org/ml/gdb-patches/2016-01/msg00115.html

>
> 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?).
>

Note, I've come across other problems with these structs like their
alignment, I have a patch to pack them in the pipeline and thus I assume
we don't have to keep compatibility too.

A more flexible ABI to communicate would be nice.

> 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...
>

It seems a good idea to tech 31-bit gdbserver about the high GPRS, at
least it should work when you have a gdbserver connected since the
proper tdesc would be read, even if tfile doesn't work it would be a plus ?

And using set tdesc could then be a workaround for tfile to work too ?
At least until there's a better solution.

Regards,
Antoine