From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-f46.google.com (mail-ed1-f46.google.com [209.85.208.46]) by sourceware.org (Postfix) with ESMTPS id 0D206388F057 for ; Mon, 11 May 2020 12:47:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 0D206388F057 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=rtems.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=joel.sherrill@gmail.com Received: by mail-ed1-f46.google.com with SMTP id g9so951237edr.8 for ; Mon, 11 May 2020 05:47:41 -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:reply-to :from:date:message-id:subject:to:cc; bh=F0kVgj4vynNwCyZC5C7WT3c8gFkf02a6n3acU3Tsmwk=; b=s6LlXddRC4LjiXxfhLBsOhsc0nW3PCEZz+EVv8gEbE/cE7GalXlm3eELvfoLkOg08M xyQ8isNhBz/Epje8wVNFxjEWoL1zTY6OZw2QjMJsKsEmoyCbXh1o5LqWswCHHs8QHlFj e+TJjS+T0krzxNImGCS3n0hznLWZGnQ0eVlwcpdJGsU004LqEiOatIkVKKyhutVaJiCp gnj/57+IoHj7/8wV9oC8jB6Q+kEAyHPFPTDibRVWdpCOSdC1iyQcdc9Pa4VWdcO9E6E7 AlouizTglMJPys3pkCHa3ALvWxdmsySm10K1HeWbOw8ofsLMfwefT8nykXrMjMWV7/XN jD2A== X-Gm-Message-State: AGi0Pubus+HuMVZpzCxpINiYfW5jpUwbOLjPy6kYpbznhV+d8I+Mc8FP xUaIJsO499mUxt9ncyS8Pz9Pb1Kk X-Google-Smtp-Source: APiQypK02vzc+IuGKkHy+VRSksKIdFWLS4XUYE+oEmZ29Jz97bAwt0yoPVzQxU3PWj/+iolXYJXCtA== X-Received: by 2002:aa7:d311:: with SMTP id p17mr13305040edq.73.1589201259413; Mon, 11 May 2020 05:47:39 -0700 (PDT) Received: from mail-ed1-f46.google.com (mail-ed1-f46.google.com. [209.85.208.46]) by smtp.gmail.com with ESMTPSA id r19sm1306372edo.12.2020.05.11.05.47.38 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 11 May 2020 05:47:38 -0700 (PDT) Received: by mail-ed1-f46.google.com with SMTP id g9so3304480edw.10 for ; Mon, 11 May 2020 05:47:38 -0700 (PDT) X-Received: by 2002:aa7:d850:: with SMTP id f16mr1579852eds.365.1589201258574; Mon, 11 May 2020 05:47:38 -0700 (PDT) MIME-Version: 1.0 References: <1eabaa19-fb43-e45d-1b16-12edcdf4aa3e@polymtl.ca> <439c535b-67be-4d8c-5d9f-9722310cdbdc@gmail.com> In-Reply-To: <439c535b-67be-4d8c-5d9f-9722310cdbdc@gmail.com> Reply-To: joel@rtems.org From: Joel Sherrill Date: Mon, 11 May 2020 07:40:12 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Stack pointer is 0 in a bare metal AArch64 program To: Orlando Arias Cc: Newlib X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS, HTML_MESSAGE, KAM_DMARC_STATUS, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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:47:44 -0000 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. --joel RTEMS > > Cheers, > Orlando. > >