From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 85464 invoked by alias); 27 Apr 2016 14:41:03 -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 85451 invoked by uid 89); 27 Apr 2016 14:41:02 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS autolearn=ham version=3.3.2 spammy=our X-HELO: usplmg20.ericsson.net Received: from usplmg20.ericsson.net (HELO usplmg20.ericsson.net) (198.24.6.45) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Wed, 27 Apr 2016 14:40:52 +0000 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id 99.D2.09012.838C0275; Wed, 27 Apr 2016 16:10:00 +0200 (CEST) Received: from elxa4wqvvz1 (147.117.188.8) by smtps-am.internal.ericsson.com (147.117.188.87) with Microsoft SMTP Server (TLS) id 14.3.248.2; Wed, 27 Apr 2016 10:40:42 -0400 References: <1452188697-23870-1-git-send-email-antoine.tremblay@ericsson.com> <867fjgwbsh.fsf@gmail.com> <86lh3zfpn2.fsf@gmail.com> <86a8kff93g.fsf@gmail.com> User-agent: mu4e 0.9.17; emacs 24.4.1 From: Antoine Tremblay To: Yao Qi CC: Antoine Tremblay , Subject: Re: [PATCH 0/4] Support tracepoints for ARM linux in GDBServer In-Reply-To: <86a8kff93g.fsf@gmail.com> Date: Wed, 27 Apr 2016 14:41:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2016-04/txt/msg00595.txt.bz2 Yao Qi writes: > Antoine Tremblay writes: > >> Is your tree public somewhere btw ? As we're (Simon and I) almost done >> with the fast tracepoints if we can help with this (2. 3.) we would be >> glad to. > > This tree https://github.com/qiyao/gdb/tree/arm-sw-single-step-2 > includes two commits that > 1) forces GDB use vCont;s with arm-linux gdbserver, > 2) enable range stepping on arm-linux, > > they'll cause some test failures, and you can start from them. I am not > sure what is the best fix could be so far, so I don't publish my fixes. > My patches might be completely wrong. > That's completly fine, thanks for sharing your work in progress, it should give us a good start. > I don't mind if you guys jump in the muddy puddles together with me. > Thanks, we'll do our best. >> >>> >>>> On my end we have fast tracepoints for arm almost ready with JIT >>>> conditions and pc relative instructions relocation. >>>> >>>> I would like to post that in the next few weeks, but it would be >>>> better if the normal tracepoints were in before that. >>>> >>>> Is it a good time to review these patches now? >>> >>> - handle unavailable memory/register in frame unwinding in target >>> independent part, so that we don't have to worry about the >>> unavailable memory in arm backend. >>> I am writing a prototype according to Pedro's thoughts, >>> https://sourceware.org/ml/gdb-patches/2016-02/msg00778.html >>> but it is blocked by a patch related PR 19947, >>> https://sourceware.org/ml/gdb-patches/2016-04/msg00429.html >>> we need an approach to test each unwinder, the discussion is still >>> ongoing. >>> >> >> Thanks for working on that one! >> >> Note however that this only affects the tracing of pseudo registers >> iirc, maybe we can live without this at first and add it as an >> improvement. >> >> Moreover, the required code changes to fix this issue have >> no impact on the tracepoint patches afaik, so I don't see it as a hard >> prerequisite for tracepoints. > > I don't think so. If that is done, unwinders in each target don't have > to worry about the unavailable memory/register, your patch 1/4 in this > series is no longer needed. Yes the 1/4 patch is no longer needed, that's a given we can abandon it, but I don't see it impacting anything else code wise. We can try to coordonate a bit too if you want since for us the unwinder patch seems harder than the single step fixing, if you want to focus on the unwinder, we will focus on the vCont/range and hopefully we'll make faster progress ? Thanks, Antoine