From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 71830 invoked by alias); 25 Jan 2016 13:27:48 -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 71817 invoked by uid 89); 25 Jan 2016 13:27:47 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2 spammy=flexible, Hx-languages-length:2266, tfile, tech X-HELO: usplmg21.ericsson.net Received: from usplmg21.ericsson.net (HELO usplmg21.ericsson.net) (198.24.6.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Mon, 25 Jan 2016 13:27:46 +0000 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id DE.27.32102.EB226A65; Mon, 25 Jan 2016 14:27:26 +0100 (CET) Received: from [142.133.110.95] (147.117.188.8) by smtp-am.internal.ericsson.com (147.117.188.83) with Microsoft SMTP Server id 14.3.248.2; Mon, 25 Jan 2016 08:27:43 -0500 Subject: Re: [PATCH 0/8] gdb/s390: Add regular and fast tracepoint support. To: =?UTF-8?Q?Marcin_Ko=c5=9bcielnicki?= , References: <1453637529-26972-1-git-send-email-koriakin@0x04.net> From: Antoine Tremblay Message-ID: <56A622CF.5030404@ericsson.com> Date: Mon, 25 Jan 2016 13:27:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <1453637529-26972-1-git-send-email-koriakin@0x04.net> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2016-01/txt/msg00621.txt.bz2 On 01/24/2016 07:12 AM, Marcin Ko=C5=9Bcielnicki 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. Unfortunatel= y, > 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=20 creates problems in the test suite see : unavailable locals,=20 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/gdbser= ver > from different gdb versions?). > Note, I've come across other problems with these structs like their=20 alignment, I have a patch to pack them in the pipeline and thus I assume=20 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=20 least it should work when you have a gdbserver connected since the=20 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