From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 109251 invoked by alias); 1 Aug 2018 18:03:29 -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 109225 invoked by uid 89); 1 Aug 2018 18:03:29 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: =?ISO-8859-1?Q?No, score=-1.1 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.2 spammy=bl, add=c2, H*c:alternative, dear?= X-HELO: mail-it0-f47.google.com Received: from mail-it0-f47.google.com (HELO mail-it0-f47.google.com) (209.85.214.47) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 01 Aug 2018 18:03:27 +0000 Received: by mail-it0-f47.google.com with SMTP id s7-v6so10919833itb.4 for ; Wed, 01 Aug 2018 11:03:27 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:8d0a:0:0:0:0:0 with HTTP; Wed, 1 Aug 2018 11:03:25 -0700 (PDT) In-Reply-To: <4fae7e81-fcf0-59e7-0770-f0eea9e96d44@arm.com> References: <4fae7e81-fcf0-59e7-0770-f0eea9e96d44@arm.com> From: Jeff Johnston Date: Wed, 01 Aug 2018 18:03:00 -0000 Message-ID: Subject: Re: AArch64 calling convention in assembly code To: "Richard Earnshaw (lists)" Cc: Alexander Fedotov , Newlib , gdb@sourceware.org Content-Type: text/plain; charset="UTF-8" X-SW-Source: 2018-08/txt/msg00009.txt.bz2 I have pushed Richard's patch to master. -- Jeff J. On Wed, Aug 1, 2018 at 12:19 PM, Richard Earnshaw (lists) < Richard.Earnshaw@arm.com> wrote: > 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 < > alfedotov@gmail.com> 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 > >>> > >>> > >>> > >> > > > > > > > >