On 18/11/2022 06:32, Kinsey Moore wrote:
On Thu, Nov 17, 2022 at 4:49 PM Chris Johns <chr...@rtems.org
<mailto:chr...@rtems.org>> wrote:
On 18/11/2022 2:39 am, Kinsey Moore wrote:
> I recently added FDT support to the AArch64 ZynqMP BSPs to
support an optional
> management console and managing ethernet parameters for LibBSD.
Use of the
> rtems_fdt_* functions implies use of malloc which adds 4 bytes in
the TLS space.
> The sp01 test uses rtems_task_construct and specifies a maximum
TLS size of 0
> bytes which causes a failure which the non-zero TLS size is
checked against the
> maximum TLS size of 0.
Does this mean there exists a requirement a BSPs cannot internally
use the heap?
That appears to be the case, at least practically. It works fine, but it
causes a test failure...
You can use the heap during system initialization. However, you should
avoid dependencies on errno, so instead of using malloc()/calloc() use
rtems_malloc()/rtems_calloc(). Independent of this, if the BSP
initialization can easily avoid the heap, then it should not use the heap.
Maybe the test needs to be adjusted?
That's part of why I sent this to the list. I was unsure whether it was
allowed or whether the test had bad assumptions baked into it.
The tests check specific aspects of the thread-local storage support and
this works only if the BSP does not depend on TLS objects such as errno.
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel