From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13655 invoked by alias); 24 Jan 2016 12:12:24 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 13631 invoked by uid 89); 24 Jan 2016 12:12:22 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.1 required=5.0 tests=AWL,BAYES_50,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=tfile, UD:unavailable.exp, unavailable.exp, unavailableexp X-HELO: xyzzy.0x04.net Received: from xyzzy.0x04.net (HELO xyzzy.0x04.net) (109.74.193.254) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 24 Jan 2016 12:12:20 +0000 Received: from hogfather.0x04.net (89-65-66-135.dynamic.chello.pl [89.65.66.135]) by xyzzy.0x04.net (Postfix) with ESMTPS id 60E573FE6A for ; Sun, 24 Jan 2016 13:13:01 +0100 (CET) Received: by hogfather.0x04.net (Postfix, from userid 1000) id CDED55800A9; Sun, 24 Jan 2016 13:12:16 +0100 (CET) From: =?UTF-8?q?Marcin=20Ko=C5=9Bcielnicki?= To: gdb-patches@sourceware.org Subject: [PATCH 0/8] gdb/s390: Add regular and fast tracepoint support. Date: Sun, 24 Jan 2016 12:12:00 -0000 Message-Id: <1453637529-26972-1-git-send-email-koriakin@0x04.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2016-01/txt/msg00599.txt.bz2 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.