K_KERNEL_STACK_MEMBER causes linker error when used with picolibc and dynamic memory allocation in C++

[r2r0]

Describe the bug
When you try to allocate structure/class with K_KERNEL_STACK_MEMBER as its member and you have enabled HW_STACK_PROTECTION and picolibc then there is observed a linker error as below.
When newlib is used or HW_STACK_PROTECTION is disabled then the same application is built without problems.

To Reproduce
Code:

#include <zephyr/kernel.h>
#include <memory>

struct ThreadStack
{
	K_KERNEL_STACK_MEMBER(threadStack, 1024) {};
};

int main(void)
{
	{
		auto ptr = std::make_unique<ThreadStack>();
	}

	return 0;
}

Configuration:

CONFIG_CPP=y
CONFIG_CPP_MAIN=y
CONFIG_COMMON_LIBC_MALLOC_ARENA_SIZE=4096
#CONFIG_NEWLIB_LIBC=y
CONFIG_PICOLIBC=y

CONFIG_STD_CPP17=y
CONFIG_GLIBCXX_LIBCPP=y

CONFIG_ARM_MPU=y
CONFIG_HW_STACK_PROTECTION=y

Build command (the same for nrf52840_mdk, npcx7m6fb_evb or any other platform with HW stack protection capability):

west build -p always -b nucleo_wb55rg  .

Expected behavior
Application should build without errors.

Impact
showstopper

Logs and console output

/opt/zephyr-sdk/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld.bfd: /opt/zephyr-sdk/arm-zephyr-eabi/bin/../lib/gcc/../../picolibc/arm-zephyr-eabi/lib/thumb/v7e-m/nofp/libc.a(nano-malloc-memalign.c.o): in function `memalign':
nano-malloc-memalign.c:(.text.memalign+0x0): multiple definition of `aligned_alloc'; zephyr/lib/libc/common/liblib__libc__common.a(malloc.c.obj):/home/hid/aurora/zephyr/lib/libc/common/source/stdlib/malloc.c:138: first defined here
/opt/zephyr-sdk/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld.bfd: /opt/zephyr-sdk/arm-zephyr-eabi/bin/../lib/gcc/../../picolibc/arm-zephyr-eabi/lib/thumb/v7e-m/nofp/libc.a(nano-malloc-free.c.o): in function `free':
nano-malloc-free.c:(.text.free+0x0): multiple definition of `free'; zephyr/lib/libc/common/liblib__libc__common.a(malloc.c.obj):/home/hid/aurora/zephyr/lib/libc/common/source/stdlib/malloc.c:223: first defined here
/opt/zephyr-sdk/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld.bfd: /opt/zephyr-sdk/arm-zephyr-eabi/bin/../lib/gcc/../../picolibc/arm-zephyr-eabi/lib/thumb/v7e-m/nofp/libc.a(nano-malloc-malloc.c.o): in function `malloc':
nano-malloc-malloc.c:(.text.malloc+0x0): multiple definition of `malloc'; zephyr/lib/libc/common/liblib__libc__common.a(malloc.c.obj):/home/hid/aurora/zephyr/lib/libc/common/source/stdlib/malloc.c:119: first defined here
/opt/zephyr-sdk/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld.bfd: /opt/zephyr-sdk/arm-zephyr-eabi/bin/../lib/gcc/../../picolibc/arm-zephyr-eabi/lib/thumb/v7e-m/nofp/libc.a(libc_picolib_picosbrk.c.o): in function `sbrk':
picosbrk.c:(.text.sbrk+0x2c): undefined reference to `__heap_start'
/opt/zephyr-sdk/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld.bfd: picosbrk.c:(.text.sbrk+0x30): undefined reference to `__heap_end'
/opt/zephyr-sdk/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld.bfd: /opt/zephyr-sdk/arm-zephyr-eabi/bin/../lib/gcc/../../picolibc/arm-zephyr-eabi/lib/thumb/v7e-m/nofp/libc.a(libc_picolib_picosbrk.c.o):(.data.brk+0x0): undefined reference to `__heap_start'
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.

Environment (please complete the following information):

• OS: Linux
• Toolchain Zephyr SDK 0.16.1 (the same effect on 0.16.0)
• a4341bb

[keith-packard]

This is somehow pulling in the 'memalign' function, which is not part of the common C library api. This causes the linker to pull in the picolibc internal malloc implementation which no longer works. What is using memalign()?

[keith-packard]

ah, I wonder if the compiler is using memalign internally? I'll provide a PR that you can review to see if it fixes the problem.

[keith-packard]

@cfriedt encouraged me to write a test in #58012, so I've copied your code from above and stuffed it into the existing libcxx test case, which already required c++ 17.