From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 34190 invoked by alias); 27 Apr 2016 13:57:25 -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 34140 invoked by uid 89); 27 Apr 2016 13:57:25 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=publish X-HELO: mail-pa0-f52.google.com Received: from mail-pa0-f52.google.com (HELO mail-pa0-f52.google.com) (209.85.220.52) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Wed, 27 Apr 2016 13:57:15 +0000 Received: by mail-pa0-f52.google.com with SMTP id r5so19832543pag.1 for ; Wed, 27 Apr 2016 06:57:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=Mnt93fkN+xfyM5QMir31gXyrwSxqA8msUFVVE0oGphQ=; b=Oe8CI5f2OtpBkhqMMJ+YXDWQctYSAaP+AYd34g/KDVZbKogh2nL38yx1PuBpFlc/dm pzJNKUi+t3tu9XrJYSTqzjWlH/qqiUKYVpLJeFPZOMjBz4q4IZ1Zb707E/FAZAd3aZPc ck5aLeXlPI3/NtJo6CIbQq3q6fvdJwc+1RwqhD4wwh52HWKGkOAYw9cc8LGjnFoFHsKp O5GDtxoSVKBNK3G7b8uUPf8Aa/GDlJl4548gxyz6E+lMN/fOdJ1hmo8L6L39NPXsSS9u uyzwN99W+B1uBUfrcC3cL1G/T5IZDN+HLPGFN3uAM+sRyA2CLh0mc0qdA/MFTt5y5SU0 lTSA== X-Gm-Message-State: AOPr4FWrfLxlq8ovl5tw9xWrQho6f71T/XTbvGDtpiMPh50QAdvti/HlcXu6Tw/T27lgag== X-Received: by 10.67.23.161 with SMTP id ib1mr11659479pad.156.1461765433258; Wed, 27 Apr 2016 06:57:13 -0700 (PDT) Received: from E107787-LIN (gcc1-power7.osuosl.org. [140.211.15.137]) by smtp.gmail.com with ESMTPSA id u63sm6905398pfu.18.2016.04.27.06.57.09 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Wed, 27 Apr 2016 06:57:12 -0700 (PDT) From: Yao Qi To: Antoine Tremblay Cc: Yao Qi , Subject: Re: [PATCH 0/4] Support tracepoints for ARM linux in GDBServer References: <1452188697-23870-1-git-send-email-antoine.tremblay@ericsson.com> <867fjgwbsh.fsf@gmail.com> <86lh3zfpn2.fsf@gmail.com> Date: Wed, 27 Apr 2016 13:57:00 -0000 In-Reply-To: (Antoine Tremblay's message of "Wed, 27 Apr 2016 08:07:19 -0400") Message-ID: <86a8kff93g.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2016-04/txt/msg00592.txt.bz2 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. I don't mind if you guys jump in the muddy puddles together with me. > >> >>> 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. --=20 Yao (=E9=BD=90=E5=B0=A7)