From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 72720 invoked by alias); 1 Aug 2018 16:19:51 -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 72690 invoked by uid 89); 1 Aug 2018 16:19:50 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-26.9 required=5.0 tests=BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,SPF_PASS autolearn=ham version=3.3.2 spammy=H*i:sk:wbeOtxg, H*f:sk:wbeOtxg, simplifies, dear X-HELO: foss.arm.com Received: from foss.arm.com (HELO foss.arm.com) (217.140.101.70) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 01 Aug 2018 16:19:49 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id EBB3A80D; Wed, 1 Aug 2018 09:19:47 -0700 (PDT) Received: from e120077-lin.cambridge.arm.com (e120077-lin.cambridge.arm.com [10.2.207.74]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 2EAD53F5BA; Wed, 1 Aug 2018 09:19:47 -0700 (PDT) Subject: Re: AArch64 calling convention in assembly code To: Alexander Fedotov Cc: newlib@sourceware.org, gdb@sourceware.org References: From: "Richard Earnshaw (lists)" Openpgp: preference=signencrypt Message-ID: <4fae7e81-fcf0-59e7-0770-f0eea9e96d44@arm.com> Date: Wed, 01 Aug 2018 16:19:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/mixed; boundary="------------B518A3468ECBAEC867B41FBE" X-SW-Source: 2018-08/txt/msg00008.txt.bz2 This is a multi-part message in MIME format. --------------B518A3468ECBAEC867B41FBE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-length: 2291 On 01/08/18 16:56, Alexander Fedotov wrote: > Yes, but X29 is not saved in original version. I can understand this > with 'frame-less functions" approach. So this code has a right for a > life. > > I suspect that such a problem could happen if user will pass > "-fomit-frame-pointer" option to GCC as well. > >>> All we really need is a CFI unwind record that GDB can understand. > For plain assembly code ? > Yep, see attached. This also simplifies the entry/exit sequences slightly. * aarch64/cpu-init/rdimon-aem-el3.S (cpu_init_hook): Simplify entry/exit sequences. Add CFI unwind rules. R. > Alex > > On Wed, Aug 1, 2018 at 6:48 PM, Richard Earnshaw (lists) > wrote: >> On 01/08/18 14:28, Alexander Fedotov wrote: >>>>> Pushing LR on the stack resolves a problem >>> FP of course, not LR. >>> So the correct code must be like this: >>> >>> _cpu_init_hook: >>> stp x29, x30, [sp, #-16]! >>> mov x29, sp >>> bl _init_vectors >>> bl _flat_map >>> ldp x29, x30, [sp], #16 >>> ret >>> >>> But still my point is that GDB should catch such an error and do not hang. >>> >>> Alex >>> >>> On Tue, Jul 31, 2018 at 9:34 PM, Alexander Fedotov wrote: >>>> Hello dear AArch64 maintainers >>>> Please look into code snippet below from newlib/libgloss/aarch64/rdimon-aem-el3. >>>> >>>> Seems to me this code violates AArch64 calling convention and actually >>>> breaks debugging in GDB. GDB tries to unwind call stack and got >>>> endless reentrancy... >>>> >>>> FUNCTION (_cpu_init_hook): >>>> sub sp, sp, #16 >>>> str x30, [sp, xzr] >>>> bl _init_vectors >>>> bl _flat_map >>>> ldr x30, [sp, xzr] >>>> add sp, sp, #16 >>>> ret >>>> >>>> >>>> We have couple of calls there (_init_vectors, _flat_map). If you'll >>>> try to step into any subroutine you will found that GDB hangs and >>>> can't step anymore. >>>> >>>> Pushing LR on the stack resolves a problem. >> >> X30 is LR. >> >> All we really need is a CFI unwind record that GDB can understand. >> >> R. >> >>>> >>>> So my message is that: >>>> 1. Current code in _cpu_init_hook is incorrect >>>> 2. GDB should handle this and do not hang >>>> >>>> Alex >>> >>> >>> >> > > > --------------B518A3468ECBAEC867B41FBE Content-Type: text/x-diff; name="rdimon-cfi.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="rdimon-cfi.patch" Content-length: 725 diff --git a/libgloss/aarch64/cpu-init/rdimon-aem-el3.S b/libgloss/aarch64/cpu-init/rdimon-aem-el3.S index 41db8f9..9edbccd 100644 --- a/libgloss/aarch64/cpu-init/rdimon-aem-el3.S +++ b/libgloss/aarch64/cpu-init/rdimon-aem-el3.S @@ -157,12 +157,16 @@ ttb: .align 2 .global FUNCTION (_cpu_init_hook) .type FUNCTION (_cpu_init_hook), %function + .cfi_sections .debug_frame FUNCTION (_cpu_init_hook): - sub sp, sp, #16 - str x30, [sp, xzr] + .cfi_startproc + str x30, [sp, -16]! + .cfi_def_cfa_offset 16 + .cfi_offset 30, -16 bl _init_vectors bl _flat_map - ldr x30, [sp, xzr] - add sp, sp, #16 + ldr x30, [sp], 16 + .cfi_restore 30 ret + .cfi_endproc .size FUNCTION (_cpu_init_hook), .-FUNCTION (_cpu_init_hook) --------------B518A3468ECBAEC867B41FBE--