On 08/02/2021 05:51, Chris Johns wrote:
On 8/2/21 2:41 pm, Chris Johns wrote:
Hello,
I see the call `rtems_workspace_greedy_allocate` is in `src/rtems` and publicly
available via the installed header file `rtems/support.h`.
Sorry the code is libcsupport.
Are there tests for this and similar support calls?
I ask because tests in rtems.git and rtems-libbsd.git testsuites depend on this
call and it appears to be broken on psim and PowerPC hardware. Recent psim test
results from Joel show `spprivenv01.exe` failing and I think it is
`rtems_workspace_greedy_allocate` or friends that maybe the issue ..
https://lists.rtems.org/pipermail/build/2021-February/025169.html
The in the test after calling greedy ...
https://git.rtems.org/rtems/tree/testsuites/sptests/spprivenv01/init.c#n58
... calloc ends up being called and the first alloc fails however the allocator
calls `rtems_malloc_extend_handler` and that ends up in the `sbrk` call in
bsps/powerpc/shared/start/sbrk.c.
Should the greedy call consume all memory that could be allocated and so does
the extend handler needs to be called until it has been exhausted as well?
We already have a ticket for this:
https://devel.rtems.org/ticket/3982
I am not sure how to fix this. Maybe we should force the sbrk() support
to first give us all the memory of the system. Another approach is to
remove the sbrk() support. What is the benefit of it?
--
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
