Is it planned to enable the optional locks again in nano-mallocr.c in upstream newlib?

Newlib nano is mainly built for small code size purpose. Do you evaluate the code size impact if we enable those functions?

On my platform (Cortex-M3) __malloc_lock and __malloc_unlock takes up 136 bytes compiled with -O0.

The locks are accessed by these modules: lib_a-mlock.o lib_a-nano-freer.o lib_a-nano-mallinfor.o lib_a-nano-mallocr.o only.

Calling to the lock functions passing a reent structure pointer as argument 0 in r0 takes up minimal space as the callers of the lock functions already had the same reent structure passed to them as argument 0 in r0 so the compiler does not load them again.

So in most of the times calling to the locks are assembled as a single bl <address> jump that consumes 4 bytes of flash / call.

In a linked test application with malloc and free calls __malloc_lock() and __malloc_unlock() are called only 9 times.

So my locks related overhead is less than 200 bytes of flash/rom. My lock implementation requires no additional RAM thanks to my RTOS.

Now if I would be required to use the base malloc_r from newlib instead of nano-malloc_r I would lose tons of additional resources (+3kB of ROM and +1kB of RAM).

As mainline newlib enables multi threaded configurations used together with nano-mallocr.c in my opinion the locks should not be disabled as this way the end result is not really thread safe, even though end users may assume so.

Tamas, as newlib-nano is fully upstreamed to newlib mainline now, it is
welcome to post patch to newlib community for change like this. We will be
happy to review patches regarding newlib-nano.

Thanks,
Joey

On Mon, Dec 8, 2014 at 7:46 PM, Tamas Kleiber <
<email address hidden>> wrote:

> Question #258710 on GCC ARM Embedded changed:
> https://answers.launchpad.net/gcc-arm-embedded/+question/258710
>
> Tamas Kleiber posted a new comment:
> On my platform (Cortex-M3) __malloc_lock and __malloc_unlock takes up
> 136 bytes compiled with -O0.
>
> The locks are accessed by these modules: lib_a-mlock.o lib_a-nano-
> freer.o lib_a-nano-mallinfor.o lib_a-nano-mallocr.o only.
>
> Calling to the lock functions passing a reent structure pointer as
> argument 0 in r0 takes up minimal space as the callers of the lock
> functions already had the same reent structure passed to them as
> argument 0 in r0 so the compiler does not load them again.
>
> So in most of the times calling to the locks are assembled as a single
> bl <address> jump that consumes 4 bytes of flash / call.
>
> In a linked test application with malloc and free calls __malloc_lock()
> and __malloc_unlock() are called only 9 times.
>
> So my locks related overhead is less than 200 bytes of flash/rom. My
> lock implementation requires no additional RAM thanks to my RTOS.
>
> Now if I would be required to use the base malloc_r from newlib instead
> of nano-malloc_r I would lose tons of additional resources (+3kB of ROM
> and +1kB of RAM).
>
> As mainline newlib enables multi threaded configurations used together
> with nano-mallocr.c in my opinion the locks should not be disabled as
> this way the end result is not really thread safe, even though end users
> may assume so.
>
> --
> You received this question notification because you are an answer
> contact for GCC ARM Embedded.
>