From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 117686 invoked by alias); 12 Feb 2016 14:46:22 -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 117676 invoked by uid 89); 12 Feb 2016 14:46:22 -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=termination X-HELO: mail-pf0-f196.google.com Received: from mail-pf0-f196.google.com (HELO mail-pf0-f196.google.com) (209.85.192.196) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Fri, 12 Feb 2016 14:46:20 +0000 Received: by mail-pf0-f196.google.com with SMTP id 71so4074460pfv.1 for ; Fri, 12 Feb 2016 06:46:20 -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-type :content-transfer-encoding; bh=Iq+82iJ82SxKIh2uXjtVbIB29zvxNzuELl4fJIlx1DU=; b=aeubOlvP5zq6GhSVWoh6zV3Taj8zkmN5LQoqLj4QgU+g+jaUzr7nKUVqX+jmih+MIF I3yfLKSJwQNzQMBRfQ6pRdMj1sy3gkNLOs5402hCRDto/+YMkbgixVXsxz3Qw42ANVTo 9fT8aMSaUuEVwQG8ODu2To984MB02Md0V8I8iCYlKhLTzmz6QdgjnKKrjT3SiPoqLWiu qZVic1Hr9UC+AFVBruheUktT+t5ZfGh8lltlMVkzF9ui7ka/6RMvLZLIED099sSMRrMk AmQ9beLEqydrOJ3CYyjqJmCYcPPhIaIlrMMjn/+CDzoTJ3LUFhoqAjgb1MGjeA+Fjx5t bmLA== X-Gm-Message-State: AG10YOTg3dhC8mTaQVHjymzSMommXS/Ky0PxFW/e5LS6i/ILcsa9nOvIjGhVIYKKWKdQHg== X-Received: by 10.98.18.8 with SMTP id a8mr2663862pfj.41.1455288379262; Fri, 12 Feb 2016 06:46:19 -0800 (PST) Received: from E107787-LIN (gcc1-power7.osuosl.org. [140.211.15.137]) by smtp.gmail.com with ESMTPSA id v66sm20040503pfi.56.2016.02.12.06.46.16 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Fri, 12 Feb 2016 06:46:18 -0800 (PST) From: Yao Qi To: Antoine Tremblay Cc: , 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> Date: Fri, 12 Feb 2016 14:46:00 -0000 In-Reply-To: <1452188697-23870-2-git-send-email-antoine.tremblay@ericsson.com> (Antoine Tremblay's message of "Thu, 7 Jan 2016 12:44:54 -0500") Message-ID: <86io1ung0a.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/msg00410.txt.bz2 Antoine Tremblay writes: Hi Antoine, > The reason for this is that the target's stack pointer is unavailable > when examining the trace buffer. What we are seeing is due to the > 'tfind' command creating a sentinel frame and unwinding it. If an > exception is thrown, we are left with the sentinel frame being displayed > at level #-1. The exception is thrown when the prologue unwinder tries > to read the stack pointer to construct an ID for the frame. > > This patch fixes this and similar issues by making all the arm unwinders > catch NOT_AVAILABLE_ERROR exceptions when either register or memory is > unreadable and report back to the frame core code with UNWIND_UNAVAILABLE. > > Note this commit log adapted from 7dfa3edc033c443036d9f2a3e01120f7fb54f498 > which fixed a similar issue for aarch64. It is right to follow aarch64 patch, but I am wondering whether we can do it better. Nowadays, the unwind termination due to unavailable memory is handled in unwinders in each arch backend. However, as we support more and more arch for tracepoint, can we handle the unwind termination in target independent code? The initial work of unwind termination due to unavailable memory was done by Pedro https://www.sourceware.org/ml/gdb-patches/2011-02/msg00611.ht= ml in a way that each unwinder was taught to terminate with UNWIND_UNAVAILABLE. At that moment, only x86 supports tracepoint, so it was reasonable to handle UNWIND_UNAVAILABLE inside unwinders of one arch. = Now, the situation changes, because we have more and more arch need tracepoint support, if we can handle UNWIND_UNAVAILABLE in the callers of each unwinder, each unwinder doesn't have to worry about the unavailable at all. In fact, GDB has done that way when calling unwinder->= sniffer, in frame_unwind_try_unwinder TRY { res =3D unwinder->sniffer (unwinder, this_frame, this_cache); } CATCH (ex, RETURN_MASK_ERROR) { if (ex.error =3D=3D NOT_AVAILABLE_ERROR) { /* This usually means that not even the PC is available, thus most unwinders aren't able to determine if they're the best fit. Keep trying. Fallback prologue unwinders should always accept the frame. */ do_cleanups (old_cleanup); return 0; } throw_exception (ex); } END_CATCH we can wrap methods of 'struct frame_unwind' with try/catch, and handle NOT_AVAILABLE_ERROR properly. In this way, each unwinder doesn't have to worry about unavailable memory at all. Pedro, what do you think? Did you try this approach in the rest of 9 different ways :) (you said you "implemented this differently in about 10 different ways" in your email) ? --=20 Yao (=E9=BD=90=E5=B0=A7)