From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 57723 invoked by alias); 26 Feb 2016 09:12:16 -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 57708 invoked by uid 89); 26 Feb 2016 09:12:15 -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=unwinding X-HELO: mail-pf0-f194.google.com Received: from mail-pf0-f194.google.com (HELO mail-pf0-f194.google.com) (209.85.192.194) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Fri, 26 Feb 2016 09:12:14 +0000 Received: by mail-pf0-f194.google.com with SMTP id t66so125103pfb.0 for ; Fri, 26 Feb 2016 01:12:14 -0800 (PST) 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=EflOxpx9j8GRJ+RFY0HAZcHjwr7T9lZPsY6BnN8Q7tw=; b=Ay3AZ7V1oHohI7EoSuW6YAXIP2m0Qy5+weXQoIgPkrBDt9rwkrrpP5yLJX36gDO4xs vGAwAfxJjax59ZOBa5LX+tX9aZuzP4eP49e+UmqZO7CdWIwcvgTSBSdvc98fJ8qw/dVp VW6aQ+amA8OC5flkO9ekGupe6RNwrs1Z0tK8v8+af9mkvuaQnATEYPqVmwokmf76ytKB PdNk9YmI2Oh8S5jvNyIJh945yEc6O+z+fAwmO7p5b44rQ6upoKjGLgCgglMJmSLe/EXH 6FGW367otSuQgkQ4ZquRa5/l9SrduvOlKkxdYewQHj0TkWNUjz+3L/QxTZfeWbpVKwtf P4xA== X-Gm-Message-State: AD7BkJL/SO+laG5LHL4Cc2YGRgp5zeXxaXWSMyKPRf01RVfZkUM/Hj9Tv8emlI304TrdrA== X-Received: by 10.98.7.14 with SMTP id b14mr615381pfd.40.1456477932877; Fri, 26 Feb 2016 01:12:12 -0800 (PST) Received: from E107787-LIN (gcc1-power7.osuosl.org. [140.211.15.137]) by smtp.gmail.com with ESMTPSA id y68sm17736873pfi.6.2016.02.26.01.12.10 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Fri, 26 Feb 2016 01:12:11 -0800 (PST) From: Yao Qi To: Antoine Tremblay Cc: Yao Qi , Pedro Alves , Subject: Re: [PATCH 1/4] Teach arm unwinders to terminate gracefully References: <1452188697-23870-1-git-send-email-antoine.tremblay@ericsson.com> <1452188697-23870-2-git-send-email-antoine.tremblay@ericsson.com> <86io1ung0a.fsf@gmail.com> <56CEE928.2080704@redhat.com> Date: Fri, 26 Feb 2016 09:12:00 -0000 In-Reply-To: (Antoine Tremblay's message of "Thu, 25 Feb 2016 08:15:17 -0500") Message-ID: <86si0fbzto.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-02/txt/msg00836.txt.bz2 Antoine Tremblay writes: > Reading Pedro's description I'm not against the refactoring but it's non > trivial to me at the moment at least. It is not a simple refacotring... > > I suggest we allow this patch to go in in order to make progress on the > arm tracepoint patchset and do that refactoring in a subsequent patch. > > Would that be OK ? I am afraid not. We should try this approach, because this will benefit all targets. IMO, handling unavailable memory in general frame unwinding is more important. b.t.w, I am still not confident on the arm software single step in GDBserver on some cases, such as branch-to-self (".L2: b .L2") and single step with signal. ARM tracepoint patches can go in after these issues are resolved (I am working on these issues). --=20 Yao (=E9=BD=90=E5=B0=A7)