This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: [AArch64] libgloss nosys.specs
- From: Alexander Fedotov <alfedotov at gmail dot com>
- To: newlib at sourceware dot org
- Date: Wed, 9 Aug 2017 17:46:57 +0300
- Subject: Re: [AArch64] libgloss nosys.specs
- Authentication-results: sourceware.org; auth=none
- References: <CAN8C2CrOGZbmcHWxv5ZdK85D8dfMvLE+Roxnnrrr1f_08_t4aw@mail.gmail.com> <20170808103426.GD8039@1170ee0b50d5>
For archeologists related messages are here:
https://sourceware.org/ml/newlib/2017/msg00741.html
https://sourceware.org/ml/newlib/2017/msg00745.html
On Tue, Aug 8, 2017 at 1:34 PM, Yao Qi <qiyaoltc@gmail.com> wrote:
> On 17-08-08 12:46:02, Alexander Fedotov wrote:
>> Hello
>>
>> Could anyone describe main idea how to use newlib for AArch64
>> baremetal with nosys.specs ?
>
> It doesn't work, unfortunately. I had some local patches to get it
> working.
>
>>
>> I'm observing following problems:
>> 1. crt0.s always build with ARM_RDI_MONITOR, while ARM port has
>> different way with rdimon-crt0.s. ARM rdimon.specs utilize
>> rdimon-crt0.s, while AArch64 is not.
>
> Revert this commit cd26662dc590235e27e17eec773c5a308e6d863f
>
>> 2. how to run it with disabled semihosting and nosys.specs ? Core just
>> stuck on HLT instruction on third line of _start ( AngelSVCAsm
>> AngelSVC) and that's all.
>
> Wrap them with #ifdef ARM_RDI_MONITOR. libgloss/aarch64/crt0.S still
> pulls in semi-hosting stuff unconditionally,
>
> 1. Get memory layout (stack, heap) via semi-hosting. You can wrap it
> by ARM_RDI_MONITOR, but give the stack a fixed value, like this,
>
> exposed here in the HeapInfo Angel call. */
> ldr x0, .LC0 /* point at returned values */
> ldr x1, [x0, #8] /* get heap_limit */
> +#else
> + /* Set up the stack pointer to a fixed value. */
> + ldr x1, .Lstack
> +#endif
>
> @@ -243,6 +249,10 @@ FUNCTION (_cpu_init_hook):
> GEN_DWORD __bss_start__
> .LC2:
> GEN_DWORD __bss_end__
> +
> +.Lstack:
> + GEN_DWORD 0x800000
>
> It is a hack, but good enough to get my work done. You need to give
> a reasonable stack address for your configuration.
>
> 2. Get command line options via semi-hosting. You can wrap it by
> ARM_RDI_MONITOR, and set argc 0 and argv = NULL, like this,
>
> @@ -219,6 +220,11 @@
> and x4, x1, ~15
> mov sp, x4
>
> +#else
> + mov x0, #0 /* argc = 0 */
> + mov x1, #0 /* argv = NULL */
> +#endif
> +
> bl FUNCTION (main)
>
> b FUNCTION (exit) /* Cannot return. */
>
> this change above is reasonable, IMO, and I plan to upstream it.
>
> With these stuff put together, I managed to get executable running
> compiled with --spec=nosys.specs. I am not sure your target env, device
> or simulator etc. With nosys.specs, in my side, there is no instruction
> to initialize FPU, and _start in crt0.S calls memset. The first
> instruction in memset is a FPU instruction, which triggers exception
> because FPU is not initialized. I have to explicitly initialize FPU in
> crt0.S.
>
> Hope it helps, and good luck!
>
> --
> Yao (齐尧)
--
Best regards,
AF