From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19511 invoked by alias); 6 Apr 2016 15:54:39 -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 19482 invoked by uid 89); 6 Apr 2016 15:54:38 -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=terminate, super X-HELO: mail-pa0-f46.google.com Received: from mail-pa0-f46.google.com (HELO mail-pa0-f46.google.com) (209.85.220.46) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Wed, 06 Apr 2016 15:54:37 +0000 Received: by mail-pa0-f46.google.com with SMTP id zm5so35771131pac.0 for ; Wed, 06 Apr 2016 08:54:37 -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=prN6m/HIAm5xLZUkv+e3/eAoDwSCrfw1T65lSQQZSls=; b=Q1mPKv5b3A/FybYOykDvsOxe8yduXVz3XWUChpJozUdEs/oND58gf2bRjjBmqPpqH8 d/1mZqYk721M3HKKUexO86r0TXsKcOkz0dghn4QZ+YoVkQ1zY4HFzvt7tMd8F492RjAj egg8Akn6G3ftI/E9ihM1ScMK4cdi890Pd4O2Qu0xci9NzT8AgZ84PptmMEXQwhED2AL4 knC34rmQvmMRj47POfarhJ09oZynpXdQ4EmxnZBiIdWOBSDWPWmp7VyM8rqazik5Eod2 j/8OSLW2MwZ3GDEAPJcQaTjlDsmq9P+Q552qoCGWe9FNEhkOEdoI3ATbGNPDGgFDZ43Q 2RuA== X-Gm-Message-State: AD7BkJLLytQgrFqzVKwV34N4ws2FABabLwX7UIPr6tltXMwK7YE6gsOTvc+p6L870cn1vw== X-Received: by 10.66.190.40 with SMTP id gn8mr71575350pac.64.1459958075510; Wed, 06 Apr 2016 08:54:35 -0700 (PDT) Received: from E107787-LIN (gcc1-power7.osuosl.org. [140.211.15.137]) by smtp.gmail.com with ESMTPSA id v74sm5986397pfa.7.2016.04.06.08.54.32 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Wed, 06 Apr 2016 08:54:34 -0700 (PDT) From: Yao Qi To: Pedro Alves Cc: Yao Qi , Antoine Tremblay , gdb-patches@sourceware.org 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: Wed, 06 Apr 2016 15:54:00 -0000 In-Reply-To: <56CEE928.2080704@redhat.com> (Pedro Alves's message of "Thu, 25 Feb 2016 11:44:40 +0000") Message-ID: <86h9fen367.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/msg00131.txt.bz2 Pedro Alves writes: Hi Pedro, > I think it'd work to have an ultimate-fallback unwinder that > frame_unwind_find_by_frame returns instead of the internal error at > the end. This would return UNWIND_UNAVAILABLE or UNWIND_MEMORY_ERROR > in the unwinder->stop_reason method, depending on the error the last regi= stered > unwinder thrown. (That last unwinder will always be the arch's heuristic= unwinder.) > And it would return frame_id_build_unavailable_stack(PC) in the unwinder-= >this_id > method if the last error was UNWIND_UNAVAILABLE, outer_frame_id otherwise > (or we add a new frame_id_build_stackless function, to go along with > frame_id_build_unavailable_stack). I write some code to implement your suggestion here, and it looks OK except that I can't get PC to pass to frame_id_build_unavailable_stack, since PC is extracted from frame cache which varies on different archs and unwinders. I tried to define a super class frame_cache for various frame cache (nowadays, it is defined as void *), frame_cache has one field PC, and various frame caches are the sub class of frame_cache. Many frame unwinding APIs need update, and many places need update too, as a result. I stop here as I am not sure it is a right approach. However, I think we can still do the change you suggested, but in a smaller scope, so the change is less aggressive, and some progress can be made, like this, - Add an unavailable frame unwinder for gdbarch A which supports tracepoint, as the ultimate-fallback. - For the unwinders in gdbarch A, move the code creating frame cache to the sniffer. If the sniffer accepts the frame, creates the frame cache. - Exceptions are allowed to be thrown out in frame cache creation. The exception is caught in the caller of sniffer (frame_unwind_try_unwinder) today, so if exception is thrown, GDB will try the next unwinder, - In this way, only 'sniffer' in 'frame_unwind' may throw exception, so we don't have to worry about other 'frame_unwind' methods. IOW, all unwinders in gdbarch A except unavailable frame unwinder don't worry about the unavailable memory/register. - the unavailable frame unwinder is the last unwinder for gdbarch A, it knows how/where to get PC, if PC is available, return frame_id_build_unavailable_stack (PC), otherwise return outer_frame_id. In this way, the change will be smaller, and we can apply this change to each gdbarch one by one, and in the future, it is possible to have a single gdbarch-independent unavailable frame unwinder once we figure out how to get PC from various frame caches. --=20 Yao (=E9=BD=90=E5=B0=A7)