From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (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 B60071A1E77 for ; Fri, 9 Sep 2016 06:08:34 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id c198so13115056ith.0 for ; Fri, 09 Sep 2016 06:08:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=eu7X9iS49mao0WJhmgi8ggFzYGz5NoDG+iBGHVERlEU=; b=L5V9Ukmd9uSWIduWIuebnhHtlJYEDuOBBB1THKE3h4VTszK+X8dU3ggQMSoZwcmDma gFqezjMMJkT3I6Bhq25U0m6BKvbwt9BtppJ0A07XxGW26UEg33hSOkqEDiDu/aJFf/+q b0z4TVnXelBXOlpNhtmsCFqlBm5zbsTvsv874= 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=eu7X9iS49mao0WJhmgi8ggFzYGz5NoDG+iBGHVERlEU=; b=cSYTD04V8sP+ufiWKOzWRY+Rks7HGHkyQ36/xflu1PmsiWYAwgkiTgFipJXdZ6heo8 CUh0H75n7qEYdxLM6+oIarjMt8iHhX7ulvmO4YWXcHrmi2Ee7ijbD/0MmpwdtWN4mNX7 zb7xbz3GzZXjLDz+JY33Bfdu1PqsqfjNVElD46pMbDC/I6PO1W893kr4fewUKQsO7wcM FlJP0DgI8+LqijOrIbX73LpyVwBw7GPScKoz8qzPhucmCPqJuolqybCofxX5TIBBg9cq rFPlMzNjUeTcbatfjei38GskfhWeQJOnXf0rYrU619E3zSDGuE/n1F61Y8bU2Em8Ndpf ouaQ== X-Gm-Message-State: AE9vXwNt2L0o9PL3pUaQe2Jvt/BrljXWvLmEcAS7CDZUvFUbFK9sWgWlcCSk0NS+KeP48wlNd28iDzs0JyvITeuM X-Received: by 10.157.30.201 with SMTP id n67mr4978833otn.133.1473426514101; Fri, 09 Sep 2016 06:08:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.204.195 with HTTP; Fri, 9 Sep 2016 06:08:33 -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: Ard Biesheuvel Date: Fri, 9 Sep 2016 14:08:33 +0100 Message-ID: To: Michael Zimmermann Cc: "edk2-devel@lists.01.org" , Leif Lindholm 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 13:08:35 -0000 Content-Type: text/plain; charset=UTF-8 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.