From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 67293 invoked by alias); 8 Apr 2017 05:00:49 -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 67057 invoked by uid 89); 8 Apr 2017 05:00:41 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.2 spammy=painful, 10k, johannes, corrupted X-HELO: p3plsmtpa09-02.prod.phx3.secureserver.net Received: from p3plsmtpa09-02.prod.phx3.secureserver.net (HELO p3plsmtpa09-02.prod.phx3.secureserver.net) (173.201.193.231) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 08 Apr 2017 05:00:39 +0000 Received: from [10.0.0.13] ([172.14.36.47]) by :SMTPAUTH: with SMTP id wiTkc7R3Oqv68wiTlcSWNP; Fri, 07 Apr 2017 22:00:06 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Subject: Re: Infinite Stack Unwinding ARM From: Duane Ellis In-Reply-To: <6ECCE8A0904A1643BE093611EF2098CE01475738@DE02WEMBXB.internal.synopsys.com> Date: Sat, 08 Apr 2017 05:00:00 -0000 Cc: Yao Qi , "gdb@sourceware.org" , Andreas Ropers , Marc Mones , Kai Schuetz Content-Transfer-Encoding: quoted-printable Message-Id: <8475BB20-B486-4675-AA42-03BAA9FCAF94@duaneellis.com> References: <6ECCE8A0904A1643BE093611EF2098CE0147553E@DE02WEMBXB.internal.synopsys.com> <86pogrp0vj.fsf@gmail.com> <6ECCE8A0904A1643BE093611EF2098CE01475738@DE02WEMBXB.internal.synopsys.com> To: Johannes Stoelp X-CMAE-Envelope: MS4wfMLy5XmbVEuNBJDHoXXjGDf2Wam9DSfIaoGJ8mCusAheffyNoBAJoxMGIBnhVFMeJWjkQ148aN0UkOww+4igoKYc33S9412fyCGschJruYgHsTKNDJez 0G1rc1PRHwznta7x2LfpWreArm6qV0fXfY21VF0NS26lDPodngqgAwAzFuYIBI4eGnA2+Nx5fYjj/ln3d/uECkvu/VMCPlkY/Dqu0wTCUEfs/n88keHr6gji 6v/jZmhn/P0TZgqbkuD2eCzG0pFXeDbvss5/eYyJWl3PtP7V/L/BzxeZQn4Qd86a3GCfq64HTep58iBfM4cVnGI1IInIr53UbTayiwKZaBGmOFd2fIIVi6HF iANcsUm5 X-IsSubscribed: yes X-SW-Source: 2017-04/txt/msg00013.txt.bz2 > On Apr 7, 2017, at 12:15 AM, Johannes Stoelp wrote: >=20 > Yao Qi writes: >=20 >> I don't expect prologue analyzer supporting SYSRegs and instruction MRS.= All the prologue analyzers in GDB are written in a way that understanding= instructions according to the ABI/calling convention of each architecture = and compiler's behavior, so it should be able to parse the instruction in = prologues complying to the ABI. GDB prologue analyzer may not understand w= hat does handwritten assembly do. >=20 >=20 > Hi Yao, >=20 > I see what you are saying about the prologue analyzer and the ABI/calling= conventions.=20 >=20 > I understand that gdb does not have to understand every hand written asse= mbler routine, but I would like to emphasize that gdb in this particular ca= se ends in an "infinite" loop printing the backtrace line by line (I put in= finite in quotes because the loop is limited by the lower boundary of an in= teger).=20 > 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. > In my understanding situations like this can also occur when the stack ge= ts corrupted. There I would also expect gdb to not end in an infinite loop = since gdb is intended to analyze the non-expected situation. >=20 > 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 wh= ile the aarch64 analyzer (gdb/aarch64-tdep.c:aarch64_prologue_analyzer(...)= ) stops when the first unrecognized instruction is hit? >=20 > Best, > Johannes=20 >=20 All of the below are techniques I have used in a custom port of GDB to a cu= stom CPU. Some might already exist, some are not, it is a balancing act between the s= oftware being debugged (helping the debugger) and the debugger trying the b= est it can. It=E2=80=99s not uncommon for some bare metal RTOS to push ZEROS onto the s= tack, or for example on the ARM cores, to set the LR register to ZERO in th= e assembly handler, yes, this is an extra opcode or two - on every interrup= t - in some cases, this is trivial an not a problem if extra opcodes are pa= inful - it can be done in a compile time conditional in other cases the top= 16 bytes or so of the interrupt stack is zeroed Another thing unwinders do - is make sure the stack is still going on the s= ame direction, and it is not a very large distance away from the previous s= tack, it=E2=80=99s a heuristic - for example 90% of code does not have huge= arrays (i.e.: 10K bytes) on the stack, so - as you walk up the stack you m= ake a decision - is distance(THIS_FRAME -vrs- NEXT_FRAME ) greater then MAX= VALUE - abandon the backtrace. Another thing the unwinder can do is inspect a few bytes before the return = address, and make sure (1) the call site is within the application being de= bugged and not in outer space - and (2) the opcodes at that point are actua= lly a subroutine call. If the unwinder has access to current thread information and RTOS informati= on - it might know the range of the current threads stack. Again - along the idea of the target memory map - in an embedded system, RA= M is in a fixed region=E2=80=A6 as is code (flash memory) if you know this = (or it is set-able) you the unwinder can make other educated decisions. -Duane.