From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x22f.google.com (mail-oi1-x22f.google.com [IPv6:2607:f8b0:4864:20::22f]) by sourceware.org (Postfix) with ESMTPS id 086403890417 for ; Mon, 11 May 2020 12:50:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 086403890417 Received: by mail-oi1-x22f.google.com with SMTP id 19so14938246oiy.8 for ; Mon, 11 May 2020 05:50:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fhQllzZ7YSfAsdEvadu4Fys7J6X/fvrFkVOVgBUq4aM=; b=T7s8ekd00LO8PsL1XjG8e0hRX1jK+DVfMfniWM2t2U1oUBfW3PYO54GBqa/Fu8Fsdw rq5W/Nlir+BCmvU5KZ+5JdBtTqjmf1RJ3IUyPhUe9niVUftVC2ZVp8i2YgVRqgRdvCsZ omyAN/iSrwAdOZZ2luKsbXEtAhUQeCAAmT53tpF6lSn7UflC4EbApL9IcW/MXc0aZz39 uWEiecnui0DxlsBqBVMhbFeBoeoYafTOon3CxzTiqd/sBn4ncw1qOYYUgRqle5jGSB90 fmxIlkBdLq6QFNOo+/KSLlycQ5IUIx718BW4K5jhtgE2v9JxHH5LRM7uo6UqcmhourTN oaAg== X-Gm-Message-State: AGi0PuY98SlX9nt+gH0M2In1c+sg6Oj0uPOQka9uszhtx/kpzd/VDOcT NxLqjjdy1io3ZEWga7ydC+ZVnnD+WmLjC829sQvQNA== X-Google-Smtp-Source: APiQypLI91o/R3OuxfbjKNvsbdP8kwFnZAWXUevlKYSpPKePxpa9iW7H45hQdnufultUmXTeNjbEBZdsCIfBNN3xQrk= X-Received: by 2002:aca:4a45:: with SMTP id x66mr18255132oia.48.1589201406276; Mon, 11 May 2020 05:50:06 -0700 (PDT) MIME-Version: 1.0 References: <1eabaa19-fb43-e45d-1b16-12edcdf4aa3e@polymtl.ca> <439c535b-67be-4d8c-5d9f-9722310cdbdc@gmail.com> In-Reply-To: From: Christophe Lyon Date: Mon, 11 May 2020 14:49:55 +0200 Message-ID: Subject: Re: Stack pointer is 0 in a bare metal AArch64 program To: joel@rtems.org Cc: Orlando Arias , Newlib Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-8.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_SHORT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: newlib@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Newlib mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2020 12:50:17 -0000 Hi, On Mon, 11 May 2020 at 14:47, Joel Sherrill wrote: > > On Sun, May 10, 2020 at 11:04 PM Orlando Arias via Newlib < > newlib@sourceware.org> wrote: > > > Greetings, > > > > On 5/10/20 10:31 PM, Simon Marchi via Newlib wrote: > > > $ ./sim/aarch64/run --trace=on --trace-disasm=on ./sim/aarch64/a.out > > > memory: ERROR: executable is too big: ffffffffffffffff > > > insn: pc = 400168 instr = 58000281 > > > disasm: ldr x1, 0x00000000004001b8 > > > memory: read of 0 (8 bytes) from 4001b8 > > > insn: pc = 40016c instr = 927cec20 > > > disasm: and x0, x1, #0xfffffffffffffff0 > > > insn: pc = 400170 instr = 9100001f > > > disasm: mov sp, x0 > > > insn: pc = 400174 instr = d280001d > > > disasm: mov x29, #0x0 // #0 > > > insn: pc = 400178 instr = a9bf77fd > > > disasm: stp x29, x29, [sp, #-16]! > > > > Within libgloss for Aarch64, the stack is initialized using a weak > > symbol with the value of 0: > > > > .macro GEN_DWORD name > > #if defined(__ILP32__) && __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ > > .word \name > > .word 0 > > #elif defined(__ILP32__) && __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__ > > .word 0 > > .word \name > > #else > > .dword \name > > #endif > > .endm > > > > .Lstack: > > GEN_DWORD __stack > > .weak __stack > > > > > > If the linker script you are utilizing does not define __stack, then the > > weak symbol is used. > > > > As an aside, this behavior in libgloss has always annoyed me. When > > working with Cortex-M cores [both ARMv7-M and ARMv8-M], msp is > > initialized using the value stored in address 0 of the memory map by the > > hardware. Yes, the application is free to change it afterwards, but it > > just seems redundant to me. > > > > Then why isn't a linker script provided which provides this? This behavior > is in sharp contrast with other CPU-elf targets with libgloss support. They > can produce executables out of the box with no requirements like this. > I think this is also related to: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66203 > --joel > RTEMS > > > > > > > Cheers, > > Orlando. > > > >