GCC small lib and OS5

[jeromecoutant]

Hi

We got some issue with tests-mbedmicro-rtos-mbed-threads and "small" OS5 targets like NUCLEO_F072RB (20k RAM)
This test is FAILED with GCC_ARM.
I can make it OK using the small lib, but this needs a patch in gcc.py script :

    if default_lib == "small":
#       self.flags["common"].append("-DMBED_RTOS_SINGLE_THREAD") ==> removed
        self.flags["ld"].append("--specs=nano.specs")

Can someone remind me the reason to forbid multiple thread with GCC nano ?

Thx

[0xc0170]

Nanolib is not thread safe, it is compiled without many hooks that we would need (I recall malloc lock for instance).

cc @c1728p9

[jeromecoutant]

So we should not allow to create thread in case of nanolib,
and add some check in rtos thread files ?

[0xc0170]

Tracked here #4877

and add some check in rtos thread files ?

Please reference the exact files and what changes should be done? The test contains a check that is not supported https://github.com/ARMmbed/mbed-os/blob/master/TESTS/mbedmicro-rtos-mbed/threads/main.cpp#L24

[jeromecoutant]

Test writer is an expert, so the correct check exists :-)
But what about other applications ?
What will avoid any user to use thread and nanolib ?

[0xc0170]

What will avoid any user to use thread and nanolib ?

I recall there was a settting previously for older RTX that would limit number of thread, I can not locate it anymore to be related to MBED_RTOS_SINGLE_THREAD macro.

cc @bulislaw

[0xc0170]

@jeromecoutant Is this issue still relevant? I do not see any fix, but havent seen the failure above reported neither?

[jeromecoutant]

Hi
I still don't have the answer to the question of the OS5 availability for small targets...
There was the same question in #6631...

[0xc0170]

I've been checking where MBED_RTOS_SINGLE_THREAD is used and came back to this issue. It's only used in tests and defined in our tools if small lib is used, but can't find any reference in RTOS. My assumption was we would limit how many threads can be created but this is not the case. Thus using small default lib would still allow to create multithreaded application?

@ARMmbed/mbed-os-core Please review

[bulislaw]

Supporting special mode for small targets makes me uncomfortable, that would add 3rd flavour: RTOS, semi supported RTOS-less and single thread. I would say we should be able to run Mbed OS on 16K+ targets with RTOS. We had some PR with a way to skip tests maybe we should use it to exclude tests requiring more ram?

[deepikabhavnani]

@jeromecoutant Switching to GCC nano was tried in #7604, but was not successful.
Please track progress of Issue: #6571 for small targets. For now only option is to skip test.

[jeromecoutant]

OK

Note that I never saw any clear information
which explicit a minimum RAM and flash value in order to be OS5 compatible.

[deepikabhavnani]

@jeromecoutant - Good point.
CC @AnotherButler - Do we document the RAM/flash requirement for OS5?

[deepikabhavnani]

@jeromecoutant - Would like to know your thoughts on adding this #5285

[evedon]

I've been checking where MBED_RTOS_SINGLE_THREAD is used and came back to this issue. It's only used in tests and defined in our tools if small lib is used, but can't find any reference in RTOS. My assumption was we would limit how many threads can be created but this is not the case. Thus using small default lib would still allow to create multithreaded application?

@ARMmbed/mbed-os-core Please review

I just looked into this because I was curious on the usage of MBED_RTOS_SINGLE_THREAD in mbed-os. Indeed MBED_RTOS_SINGLE_THREAD is used in tests and defined in our tools if small lib is used. It is not used anywhere in the source code except here: https://github.com/ARMmbed/mbed-os/blame/master/rtos/source/TARGET_CORTEX/TOOLCHAIN_IAR/mbed_boot_iar.c/#L90 (I don't understand how this works without manually editing a build profile to remove --threaded_lib and add MBED_RTOS_SINGLE_THREAD for the IAR toolchain).

Is this a legacy flag then? i.e. perhaps it was used at some point in RTX to limit the number of threads but this is no longer the case. If so, perhaps we should remove it?
We are doing some work at the moment to build bare metal with the smaller libraries and we need to modify the build tools to add this falg when using the ARM toolchain...
cc @bulislaw

[kjbracey]

As far as I can see, the flag is there to stop tests failing when you try to make a build using the RTOS and a non-thread-safe library. It skips tests that require multiple threads.

I don't believe you're prevented from making the multiple threads, but they wouldn't be reliable, due to missing library thread protection.

I'm not sure attempting that is useful, given that we now support the bare metal config, and the RTOS API for it.

I would suggest use of non-thread-safe libraries should be limited to bare-metal builds, and RTOS builds should require proper thread-safe libraries.

[bulislaw]

We have to make it clear and easy:

• Mbed OS - include RTOS without any limits on threads
• Mbed OS Bare Metal - no RTOS, main thread + ISRs

The second option could be default for small targets, but that should be made clear in some way in their docs. As far as i can see MBED_RTOS_SINGLE_THREAD is not needed as we have another macro that tells us if we build with or without RTOS.

[kjbracey]

The second option could be default for small targets, but that should be made clear in some way in their docs.

Plausible, if really small - ie blinky doesn't fit otherwise. Maybe many targets which are currently marked "Mbed OS 2-only" in targets.json

[ciarmcom]

@jeromecoutant thank you for raising this issue.Please take a look at the following comments:

Could you add some more detail to the description? A good description should be at least 25 words.
What target(s) are you using?
What toolchain(s) are you using?
What version of Mbed OS are you using (tag or sha)?
It would help if you could also specify the versions of any tools you are using?
How can we reproduce your issue?

NOTE: If there are fields which are not applicable then please just add 'n/a' or 'None'.This indicates to us that at least all the fields have been considered.
Please update the issue header with the missing information, the issue will not be mirroredto our internal defect tracking system or investigated until this has been fully resolved.

[ciarmcom]

@jeromecoutant it has been 5 days since the last reminder. Could you please update the issue header as previously requested?

[LDong-Arm]

Does it make sense to only allow small C libs with bare metal, by having a check in the build system for example? If an application needs RTOS, most likely it uses multiple threads which small C libs are not safe with?

[0xc0170]

I would say yes, same as quote below from @kjbracey-arm

I would suggest use of non-thread-safe libraries should be limited to bare-metal builds, and RTOS builds should require proper thread-safe libraries.

👍