From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 89877 invoked by alias); 10 Apr 2017 12:01:47 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 88840 invoked by uid 89); 10 Apr 2017 12:01:46 -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,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=H*Ad:D*synopsys.com, HTo:D*synopsys.com X-HELO: mail-wm0-f53.google.com Received: from mail-wm0-f53.google.com (HELO mail-wm0-f53.google.com) (74.125.82.53) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 10 Apr 2017 12:01:44 +0000 Received: by mail-wm0-f53.google.com with SMTP id u2so35413763wmu.0 for ; Mon, 10 Apr 2017 05:01:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=G3d4fUREgP/UboTnUfEvRH6qqRXJUo3p4iGE4qEcC7U=; b=RCSqsKCcIxl+8PySDpXzsKqKZWnr+p1Tt+CoSqMFKZt7HxJTn2VV4osEekMRHvHc0S HYUoe39Dt7DWtcUEZyvboJ0K7boYBULgagz/jSLBv62NWGxTV7D0jfME8anj/27dKhlK WZg8D5GT6IsJYByJUtKDs3zj+0K1nCpYzx5WoAl//bjwXrJeu855jdl9GjO4nRuM+M1D uIX4lYEntSyosJ2Jqyj0HsARZZt5kdw4sn7wstDGoWfXFz6G3iGiaoHFOxrjGP4m2OMX ufegzh/zrA8GP9t7Ja5zJHI96EMQAbGzfEca0fZgDRxti1qw1c8Cao4Uwn/jt03wohNA T13w== X-Gm-Message-State: AN3rC/7fFT2eiGfqEVtLm68KhJRx8L83YZTftoqNVqQMsVWyn3pIrXDq 3Rz85m4iV8pYsA== X-Received: by 10.28.229.140 with SMTP id c134mr9549527wmh.29.1491825704289; Mon, 10 Apr 2017 05:01:44 -0700 (PDT) Received: from E107787-LIN ([194.214.185.158]) by smtp.gmail.com with ESMTPSA id s82sm10046307wmb.33.2017.04.10.05.01.43 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Mon, 10 Apr 2017 05:01:43 -0700 (PDT) From: Yao Qi To: Johannes Stoelp Cc: "gdb\@sourceware.org" , Andreas Ropers , Marc Mones , "Kai Schuetz" Subject: Re: Infinite Stack Unwinding ARM References: <6ECCE8A0904A1643BE093611EF2098CE0147553E@DE02WEMBXB.internal.synopsys.com> <86pogrp0vj.fsf@gmail.com> <6ECCE8A0904A1643BE093611EF2098CE01475738@DE02WEMBXB.internal.synopsys.com> Date: Mon, 10 Apr 2017 12:01:00 -0000 In-Reply-To: <6ECCE8A0904A1643BE093611EF2098CE01475738@DE02WEMBXB.internal.synopsys.com> (Johannes Stoelp's message of "Fri, 7 Apr 2017 07:15:21 +0000") Message-ID: <8660iclbdo.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: 2017-04/txt/msg00014.txt.bz2 Johannes Stoelp writes: > I understand that gdb does not have to understand every hand written > assembler routine, but I would like to emphasize that gdb in this > particular case ends in an "infinite" loop printing the backtrace line > by line (I put infinite in quotes because the loop is limited by the > lower boundary of an integer). > I would expect gdb to be more defensive in this case and either try > other unwinding techniques like backward unwinding (from bottom up) or > just stop unwinding because of to less information. Don't understand what do you mean by "backward unwinding". IIUC, el1_irq are vector entry points, so I expect GDB unwinding stops on el1_irq, but I want to check with kernel people to see their expectation. Can you post me the backtrace, as a sample output? We may end up with having some Linux kernel specific stuff, and this should fall in "Linux kernel debugging for aarch64". Note that we had patches for general Linux kernel debugging https://sourceware.org/ml/gdb-patches/2017-03/msg00268.html (well, I need to review them soon) > In my understanding situations like this can also occur when the stack > gets corrupted. There I would also expect gdb to not end in an > infinite loop since gdb is intended to analyze the non-expected > situation. > > One other question that came up by comparing the arm and the aarch64 anal= yzer: > * Is there a special reason/trick why the arm analyzer > (gdb/arm-tdep.c:arm_analyze_prologue(...)) skips instructions that it > doesn't recognize while the aarch64 analyzer > (gdb/aarch64-tdep.c:aarch64_prologue_analyzer(...)) stops when the > first unrecognized instruction is hit? I don't see any reason here, just because they are two different architectures. --=20 Yao (=E9=BD=90=E5=B0=A7)