Using strncpy in full newlibc missbehave on ARC platform.

[fgihl]

strncpy on ARC platform
When building c++ application for ARC em platform and using full newlibc (CONFIG_REQUIRES_FULL_LIBCPP=y, CONFIG_NEWLIB_LIBC=y). strncpy don't copy some string length correctly. It copies to little characters.

arc_em : strncpy copies string with len 23-30 incorrect.
arc_hs : strncpy copies string with len 23-39 incorrect.

The error only show up when using the full version of newlibc. Tested on sdk version 0.16.5-1 & 0.17.0

Repo
I created a small c++ sample to show the error.

west init -m https://github.com/fgihl/zephyr-ds18s20.git
cd zephyr
git checkout fgihl/strncpy-error
west update

west build -p -b qemu_arc/qemu_arc_em samples/strncpy_error/
west build -t run

[keith-packard]

Also broken in picolibc when using the speed-optimized path.

[keith-packard]

Proposed fix here: picolibc/picolibc#969

[fgihl]

@keith-packard : Thanks for the quick response! I'm not sure how this work. Will you upstream your changes to newlibc, and then later Zephyr toolchain pickup a new version of newlibc? Or what is the workflow?

[keith-packard]

@keith-packard : Thanks for the quick response! I'm not sure how this work. Will you upstream your changes to newlibc, and then later Zephyr toolchain pickup a new version of newlibc? Or what is the workflow?

I'm not sure what newlib will do as they don't directly support Zephyr. Can you use picolibc for your application?

[fgihl]

I need the full libc, so I need the precompiled libc that comes with the toolchain.
I tested to use the picolibc from 16.5-1 and my application works, but is slow. So to use picolibc I guess I would need to build my own toolchain, which is not optimal.

[keith-packard]

I need the full libc, so I need the precompiled libc that comes with the toolchain. I tested to use the picolibc from 16.5-1 and my application works, but is slow. So to use picolibc I guess I would need to build my own toolchain, which is not optimal.

Picolibc does come with the Zephyr toolchain, is that version causing you the performance issues mentioned above? Do you need a speed-optimized variant? If so, you can use the picolibc module for Zephyr, which builds the C library along with your application. If you need libstdc++ as well, then you'd need zephyrproject-rtos/zephyr#80762 which builds that library as a module as well.

[fgihl]

Yes I need libstdc++ and the speed optimised path. I'm not sure how much extra time this will add to our build pipeline. We are building a bunch of different flavours, so if the CI pipeline take much longer there will be complains.

[keith-packard]

Yes I need libstdc++ and the speed optimised path. I'm not sure how much extra time this will add to our build pipeline. We are building a bunch of different flavours, so if the CI pipeline take much longer there will be complains.

I've got a pending PR, #821, which builds both -Os and -O2 versions of every library using the existing GCC multilib code patched to allow optimization to be used as a multilib flag. Maybe we can get that moved along?