[C++] Use malloc/free instead of k_malloc/k_free in operator new/delete

[vanwinkeljan]

Use malloc/free instead of k_malloc/k_free in operator new/delete and extended test cases to cover new/delete.

Fixes: #18990

[andrewboie]

why was this excluded?

[vanwinkeljan]

I added a test case to cover new/delete and this onde can run in CI, before this change the test case did not contained any runnable test and was only build.

[andrewboie]

right but why did you exclude qemu_x86_coverage

[vanwinkeljan]

For some reason qemu_x86_coverage hangs when running with c++.

[andrewboie]

need a bug filed on this, since this is an indicator that gathering code coverage will fail

[vanwinkeljan]

created bug report #20729, looks like our own coverage code ends up in a endless loop

[aescolar]

@vanwinkeljan What is the motivation for doing this change?

[vanwinkeljan]

@aescolar please see issue #18990 for more background

[pabigot]

This isn't what I expected. Please check my understanding:

• Currently ZEPHYR_CPLUSPLUS is defaulted off, and applies only when MINIMAL_LIBC is disabled and LIB_CPLUSPLUS is enabled. AFAICT ZEPHYR_CPLUSPLUS would be desirable only when using a libc that doesn't support C++ even though it provides a libc++. (?? I'm not sure how that would even work, but I think it was a path to retaining old behavior, so fine.) Its effect is to support new/delete and virtual functions.
• Proposed ZEPHYR_NEW_DELETE is defaulted on when LIBCPLUSPLUS is disabled, requires MINIMAL_LIBC is disabled or supports malloc, and is allowed when LIB_CPLUSPLUS is enabled. It only overrides new/delete, and overriding virtual support is always done with LIB_CPLUSPLUS is disabled.

At this point I have no clue of how all the different C++ and libc Kconfig features interact. I'm particularly concerned here that it might become easy for somebody to replace new/delete in a newlib-based libc++ (which already implements them using malloc), which would be gratuitous and risky.

That mess pre-dates this PR, but I'm uncomfortable with changing it at this point. For the purposes of settling the basic need in #18990 to get rid of using kernel memory for C++ objects is it not sufficient to just replace the k_malloc(free) preprocessor-protected calls in cpp_new.cpp with unprotected malloc(free) calls? And leave the configuration infrastructure unchanged?

[vanwinkeljan]

I'm particularly concerned here that it might become easy for somebody to replace new/delete in a newlib-based libc++ (which already implements them using malloc), which would be gratuitous and risky.

We could just drop the option of using the zephyr version of new/delete if a libc++ is used (it uses malloc internally). Actually this is maybe the most correct and clean way forward and actually the Kconfig could be dropped in this way.

Shall I update the PR to get a feeling how it would look like?

[vanwinkeljan]

@pabigot @andrewboie Another surprise is the failing CI, it seems that virtual destructors are calling operator delete. With the current proposal this requires a libc heap.

[andrewboie]

We could just drop the option of using the zephyr version of new/delete if a libc++ is used (it uses malloc internally).

Yes, why would we not want to do this?

Maybe this is historical cruft but we should not be providing our own versions of these functions if the C library already provides them!

[vanwinkeljan]

@dleach02 do you want this PR in 2.1? It has a medium prio bug associated.

[dleach02]

@vanwinkeljan, yes we should merge this to clear the medium bug.