From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id D059F1A1DF8 for ; Fri, 9 Sep 2016 11:03:21 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id w12so46672107wmf.0 for ; Fri, 09 Sep 2016 11:03:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uoNiWSUdK0x5SgzESmy6pz2NKkOJONXzhLe0WbtFsiI=; b=UTR7lhwZxGaw/hvUvADoUW6cBQ0Q49n9LYAIVh2YyIvKphJNJaqoKt71FPUNKdgSwZ AB9xjoDnTXate+LqhrYTn/CF7LI3/lM2sIyrkmqClPhTvudvqQ5sOf56RxdOxnpmwXM6 kcpsCOuCts9MQU6MRH3RKxReH9lPSVupEjQuW3p8h1mDjpuRb450A2wIsvAuiu0CcUQr vrCpd6iks+nb2oDe0kFpUwSEPrJvyOELA8J8+uYvaujAwD77zOIdLIDvaYav5Ky4UdgY C26Z8JDXXMvxDFmhR5i/HzAPM2XMnmNEXQGBj301vwrOEEkhEpOJ8B+DogSJKRiTVLre FX9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uoNiWSUdK0x5SgzESmy6pz2NKkOJONXzhLe0WbtFsiI=; b=OxzL7vKbiHfVAg+STyZdrvYOUTqov0xWV90MlHv3eKnFYOKQef+4+j0JzbTVQGJTyJ RpIYfXYIzaLv3lMcN/rZC7bCF7tGZevZlr1tW8tA6eGQTr5mKMSCbEVrUl4pQ0FfX+zA L9D13HpiRu5XVD4vUrf1rUJ0veZze6aME3VzOcZ7HRlX60PKtnC53yI9htOXUe3Lu8fB evbO7QKDwyG/Sr4YIWIYwP23vA3Z6xNThaeePmfLxU62QLRLE9gH8tqILmrsA+Ux7NnT TlGCBwOSMt3w7be2iLPis+kXS6gR1SgalnFMrtXlU4ZJ5iajEVXnweb7/qP0lCl9NaSm GIRw== X-Gm-Message-State: AE9vXwN9L4hjX5YqRXcKfUE4ft3GFFzTHd7dFH8F9Scpnxn5aUck7pMZkyII5w7+VR5vRy0GPyYu2IsGzho+Cg== X-Received: by 10.28.161.133 with SMTP id k127mr4029870wme.103.1473444200468; Fri, 09 Sep 2016 11:03:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.36.212 with HTTP; Fri, 9 Sep 2016 11:03:19 -0700 (PDT) In-Reply-To: References: <1473236515-8318-1-git-send-email-ard.biesheuvel@linaro.org> <1473236515-8318-2-git-send-email-ard.biesheuvel@linaro.org> From: Michael Zimmermann Date: Fri, 9 Sep 2016 20:03:19 +0200 Message-ID: To: Ard Biesheuvel Cc: "edk2-devel@lists.01.org" , Leif Lindholm X-Content-Filtered-By: Mailman/MimeDel 2.1.21 Subject: Re: [PATCH 2/2] ArmPkg/DefaultExceptionHandlerLib AARCH64: add minimal backtrace to crash dump X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2016 18:03:22 -0000 Content-Type: text/plain; charset=UTF-8 > In any case, unless you have any information that suggests that GCC in > Thumb2 mode can be coerced into managing the frame pointer in a way > that allows us to do something similar in EDK2, I am going to stick > with my assertion that this is not currently possible on ARM. I think it's not possible because they enable ARM_UNWIND when compiling a THUMB2_KERNEL. porting libunwind would be hard because of UEFI's architecture. every *.efi would need a section with unwind information, and I don't even know if the spec allows additional sections. Thanks Michael On Fri, Sep 9, 2016 at 3:08 PM, Ard Biesheuvel wrote: > On 7 September 2016 at 12:32, Ard Biesheuvel > wrote: > > On 7 September 2016 at 12:25, Michael Zimmermann > > wrote: > >>> However, looking at this > >>> code, this is still not sufficient to find the *next* frame pointer on > >>> the stack. > >> are you sure about that? this code looks like it does just that: > >> https://github.com/torvalds/linux/blob/master/arch/arm/ > kernel/stacktrace.c > >> > > > > First of all, that comment makes little sense: > > > > * With framepointer enabled, a simple function prologue looks like this: > > * mov ip, sp > > * stmdb sp!, {fp, ip, lr, pc} > > > > I assume this should be > > > > stmdb sp!, {fp, ip, lr} > > > > * sub fp, ip, #4 > > * > > * A simple function epilogue looks like this: > > * ldm sp, {fp, sp, pc} > > > > OK, I spoke a bit too soon. The 'pop' does not actually increment the > stack pointer, so while the push does make sense (and pushing the pc > in addition is just informational), the pop should actually be > implemented as > > ldm sp, {fp, sp, lr} > > ... do other stuff including incrementing the sp to its original value ... > > bx lr > > In any case, unless you have any information that suggests that GCC in > Thumb2 mode can be coerced into managing the frame pointer in a way > that allows us to do something similar in EDK2, I am going to stick > with my assertion that this is not currently possible on ARM. > > Thanks, > Ard. >