From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) by sourceware.org (Postfix) with ESMTPS id 3A6F9388F049 for ; Mon, 11 May 2020 16:00:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 3A6F9388F049 Received: by mail-qk1-x736.google.com with SMTP id c64so10235067qkf.12 for ; Mon, 11 May 2020 09:00:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:references:from:autocrypt:subject :message-id:date:user-agent:mime-version:in-reply-to; bh=jPBFsuckuJrH5gRU7wHZVoZJV8ZYtiSJzKiYTNZm8rU=; b=qwJp5bB0x5DwwXI2UGY4H7TkszxFkh9vaPN0HSo2l1a+pgA8B4jnSnVxVoznVoBQcX CtV3H/zIZ/ffZYyBWlKvp1BIcDF7fJRCwZ5pHDbzWqsdwpu35besgeYtYgR/voDvr1Ft 5lHKKuCf7RrBsLFk4kvrIwuioF0nbTvpTvuAOjsOKeecQGGLXAH/7HeEMz46kl1/qoiu l8p4u4Kg3zeNTuDNWBYhgQdCM8h0nkdb5haAxzKItwseevWlIYwJrjVouVrv7JGg96xn uqjyLneacWTYxDtSzePP5NbUu/MWt7lUrDg4eh3jd+yBzs+BmsBWoOi8tBk6kqXkBeBv tCNg== X-Gm-Message-State: AOAM530EltvAwQSpKu+TFgxJ/5zUg2JEVQ+JFYu4Vmb8/7JY2gFTaPVK fqX6ES6kEXtqMqDdEydmIc7jhIgL X-Google-Smtp-Source: ABdhPJxWcYRfmERI5sbQE1rh6Wy/LmNlqWC/52/OKqGc/a5m/tRD7Gn8hM1YIIslISeF4YT8XuE48w== X-Received: by 2002:a37:4397:: with SMTP id q145mr2229213qka.117.1589212838358; Mon, 11 May 2020 09:00:38 -0700 (PDT) Received: from [192.168.1.233] (050-089-177-152.res.spectrum.com. [50.89.177.152]) by smtp.googlemail.com with ESMTPSA id h33sm9671615qtc.21.2020.05.11.09.00.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 11 May 2020 09:00:36 -0700 (PDT) To: joel@rtems.org Cc: Newlib References: <1eabaa19-fb43-e45d-1b16-12edcdf4aa3e@polymtl.ca> <439c535b-67be-4d8c-5d9f-9722310cdbdc@gmail.com> From: Orlando Arias Autocrypt: addr=orlandoarias@gmail.com; prefer-encrypt=mutual; keydata= mQGiBEdjh9ARBADvS6iwWeg4Ge5QEdivsrDye6VJDebt4g+U3NVo+7/CmCsTzeYBKa28X7Mg UJFrsHEGZgoZvZ6N69/ERwBuVkZ8Vi6GOYDhVjMnHzMV5+uFcegYzQpH5mekSsdd4NVGS8sz 1AsOxKpH/7dEDPYkqOaDnK7XZjW35D/KPsEevSOhCwCgvJQDiPZm1ygrI37GMqSqUbXcGjkD /2hH42NeYtZZbmPcEobe74FdxL6sqIbu0KHEK/khA9Y06/WqEoFPqVMexX1yY9p6thEl7+27 LQ2LYEiUCTTAX+liUBsm+lyhEhtlDjC2lsjgA7xqO6wiHMCKLRJbx2NzpxQb/5LNSOYlbnBp Fv62BsBo5w+EzUOrKtzu0M6gbCQsBACMI6wALPOBZhggg7IWY+I+r7BTkrE/Af09HIAB+rAd yi9MjFCizqnMlx6dXk84DyEJXOJYfZ71k54daiM+YBWd+JWdZ5qzGNqnrXFGkHB7H3EDXEKl W6BLhSHrprx65H9AhDdz+ITYSKNeHKxC/Bell6v2flvr6hfe2FlLyEVOWLQ8T3JsYW5kbyBB cmlhcyAoT3JsYW5kbydzIEdtYWlsIEtleSkgPG9ybGFuZG9hcmlhc0BnbWFpbC5jb20+iHsE ExECADsCGyMCHgECF4ACGQEWIQQNWDJzd34+k5noE3NTFb9QFn4uoQUCXqJlUwULCQgHAgYV CgkICwIEFgIDAQAKCRBTFb9QFn4uoQq/AJ9+CMy8nYDvucKU07oS/G4TQl2/yQCgtwmT1Pj3 sAIHgIc7gu3XubnuPIq5Ag0ER2OH0BAIAIbCj0xIR0ZioCc/TXd0FU/uic+FKMaO/XbmbliM JzgJ/d0kK+/x6oHDd1+rudjlv3hJQnn2q9wQPwfOHD6N0pU1nvddOVX40XbDDgUNyW1PbQea W3qoZCfEc6XQleYWSJ2QECV5DCihpsJY0QFL6gbVPrQhJprSggLsDOAJqd2nA+cuyesXVZd1 4Q6qTtO0y4AJsR4HqtkuuprsGY0sk/ZBldHOtJw9a/VB291tdFTtXCB0yV1+VjQjXzo8qw7r d9pEmBefMXz4B89qxSC8TrLV5V5aEX3X9wkXPYMQNETsadg0cqhU0CVgHoQ7hCePAhabv20H 4ggkByw0qgeLf88AAwUH/2xx4OwgjWpcCoFyGxdzxDjdVrYrEVLHmCz3e09+IaATOTOFFCEd rYb1KeLIYccK88VYSFyd0SfWIFR4vvAa9qrUxmOl/8TaU5Mq30NLvkPV3k7b20wZBewfenlW ti/caEXaFvEWeevWF4naJix7YouAQoKH8Om1vU6OTWsXZCFTI1yFAqSkbLu9C78xPa8TwNFh fL5Trn5lzCMaDP4uK2L2DPAz9ExOJDmHLlycJHPw50S4m6I/fYFmpHPnTdY8eRSrSZsCji2G Nl5t1WkyNHUEQ7v8kE81wlaVpYmzxOL9GYYngOZhvuCks+e3o1ZbLEdX2V3wQ4eMN7Kjiz+h LlaISQQYEQIACQUCR2OH0AIbDAAKCRBTFb9QFn4uoYiqAJ9JL/UL6Styb5BYbtsW/Nqy5Sfr vwCgpUiPm3gKcjaEq2PRRsRstBUMH08= Subject: Re: Stack pointer is 0 in a bare metal AArch64 program Message-ID: <21165695-026a-5081-a036-72b6a2b8446d@gmail.com> Date: Mon, 11 May 2020 12:00:53 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Zq3OvCVmtxqffqkyELTwahY610KsrbpUD" X-Spam-Status: No, score=0.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_NONE, 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 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 16:00:40 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Zq3OvCVmtxqffqkyELTwahY610KsrbpUD Content-Type: multipart/mixed; boundary="bEt4XjZOSXwz7WejDuWzUI2vdwdhfVY5W"; protected-headers="v1" From: Orlando Arias To: joel@rtems.org Cc: Newlib Message-ID: <21165695-026a-5081-a036-72b6a2b8446d@gmail.com> Subject: Re: Stack pointer is 0 in a bare metal AArch64 program References: <1eabaa19-fb43-e45d-1b16-12edcdf4aa3e@polymtl.ca> <439c535b-67be-4d8c-5d9f-9722310cdbdc@gmail.com> In-Reply-To: --bEt4XjZOSXwz7WejDuWzUI2vdwdhfVY5W Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Greetings, On 5/11/20 8:40 AM, Joel Sherrill wrote: > Then why isn't a linker script provided which provides this? This behav= ior > 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 am afraid I do not have a good answer for this. A cursory look indicates that the default linker script for Aarch64 is being provided by ld from binutils [or whatever other linker is being used], and not newlib. The linker script in question may not fit the requirements of the simulator, or vice versa. I believe a more proper question would be ``why does the default linker script not create a binary that is readily runnable in the simulator?'' but I can not say whether this is proper, and I do not have an answer either. For actual hardware platforms, the norm is to provide your own linker script. This is because the linker script helps tailor the binary to the memory map of the device. For example, in the M profile for both ARMv{6,7} and ARMv8, the SRAM region starts at address 0x20000000 and can for up to 512 MiB [excluding any bit banding regions that may be present]. However, an MCU using these architectures will have various amounts of memory. The linker script then sets the stack pointer by providing a symbol that gets populated at address 0 of the vector table. In my linker script for an STM32F407, I have: OUTPUT_FORMAT("elf32-littlearm", "elf32-bigarm", "elf32-littlearm") OUTPUT_ARCH(arm) ENTRY(__reset) /* the hardware does not care about this */ MEMORY { FLASH (rx) : ORIGIN =3D 0x08000000, LENGTH =3D 1024K RAM (rxw) : ORIGIN =3D 0x20000000, LENGTH =3D 128K } SECTIONS { .vector_table : { KEEP(*(.vector_table)) } > FLASH /* [snip] */ __ram_end =3D ORIGIN(RAM) + LENGTH(RAM); /* initial msp value */ } Then, in my initialization code: .syntax unified .thumb .section .vector_table, "aw" .globl __vector_table __vector_table: .word __ram_end /* initial stack pointer */ .word __reset /* reset vector/entry point */ .word __vector_2 /* non-maskable interrupt */ /* rest of the vector table */ .section .text .global __reset .type __reset, %function __reset: /* initialize .data region */ ldr r0, =3D__data_start ldr r1, =3D__data_end ldr r2, =3D__data_init /* more initialization code */ When the CPU boots, it reads the vector table, initializes msp [main stack pointer] using the value in entry 0, then initializes pc using the value in entry 1. It then goes into thread mode and starts executing the __reset vector. Yes, this completely bypasses libgloss, but I don't really use most of newlib's or libgloss's facilities on my projects, only the sporadic call to some basic C function. I believe the simulator instead uses whatever the ELF says the entry point is and initializes pc using that value. Technically speaking, on actual freestanding hardware we use whatever CMSIS package the vendor gives us. The CMSIS package provides both vector table initialization, and memory region initialization, completely bypassing the C runtime code in libgloss. CMSIS can go to do other things, like enabling the FPU, and setting up the PLL for the CPU to achieve a desired frequency. For the most part, CMSIS-Core is standard across vendors, with only minor variations in the vector table creation, peripheral/clock initialization code, and linker scripts. Cheers, Orlando. --bEt4XjZOSXwz7WejDuWzUI2vdwdhfVY5W-- --Zq3OvCVmtxqffqkyELTwahY610KsrbpUD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EAREKAB0WIQQNWDJzd34+k5noE3NTFb9QFn4uoQUCXrl2tQAKCRBTFb9QFn4u oYcCAJ4rrfb/1v4f/Ch/MTNH/w+MMiK/uQCfRVacm80osD1bv3ygC1I/m8yyUes= =zf+5 -----END PGP SIGNATURE----- --Zq3OvCVmtxqffqkyELTwahY610KsrbpUD--