From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 126896 invoked by alias); 1 Aug 2018 15:56:59 -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 126872 invoked by uid 89); 1 Aug 2018 15:56:58 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=H*f:sk:cc3376c, H*i:sk:cc3376c, HX-Received:sk:m8-v6mr, dear X-HELO: mail-pl0-f41.google.com Received: from mail-pl0-f41.google.com (HELO mail-pl0-f41.google.com) (209.85.160.41) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 01 Aug 2018 15:56:57 +0000 Received: by mail-pl0-f41.google.com with SMTP id t17-v6so8995568ply.13; Wed, 01 Aug 2018 08:56:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=phvpovH4Ey+4bRsZEQbVHRmMJTyBYAJP5DX+7Gx/N3Q=; b=cuOI9+PEZ3LCy7BZMU4HluNHOcwURdMgoOGj10EWj1nFD6FUpQKpFNsqtX01Rs2mpR 8cO9qyx+t5h0DNP4Zr43gbljSbGLT8Q5UpxvU+Q+Mws1r03XB/6LLlu7tiYipmdGzSeE EckTNInJioNvaIfqK0qqKEBcree8lQskTBko2TbSMDHF3Fh0w2L6nVPPugOywidNPLUh 68ujSjVXKSRWWly6auUEVYQA0xJHIbyJVGhSSxMWqxke4/GYfaUTngfbV4IbhRRa8yYM dPh0i/Am5w5PD2tXPvifoHUqWY2HIYlyPOl4le1RzS9lG0RsH3j1JeSqLDZAvsS2O+H3 57Fw== MIME-Version: 1.0 Received: by 2002:a17:90a:35a4:0:0:0:0 with HTTP; Wed, 1 Aug 2018 08:56:55 -0700 (PDT) In-Reply-To: References: From: Alexander Fedotov Date: Wed, 01 Aug 2018 15:56:00 -0000 Message-ID: Subject: Re: AArch64 calling convention in assembly code To: "Richard Earnshaw (lists)" Cc: newlib@sourceware.org, gdb@sourceware.org Content-Type: text/plain; charset="UTF-8" X-SW-Source: 2018-08/txt/msg00007.txt.bz2 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 ? 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 >> >> >> > -- Best regards, AF