[libcxx-commits] [libcxx] [libc++] Fix missing 'get_new_handler()' for Windows builds (PR #150182)

[Martin Storsjö via libcxx-commits]

mstorsjo wrote:

> Actually, I've misread it again. We're storing the new handler in two separate places now, so this doesn't work if someone calls `set_new_handler` from MSVC and calls `get_new_handler` from libc++. IoW, the value returned from `get_new_handler` may not be the same as `operator new` would be calling.
> 
> This already breaks down if both libc++ and the MSVC STL DLLs are loaded,

In essentially all cases, we have both libc++ and MSVC STL symbols loaded, as libc++ on MSVC still relies on a bunch of ABI symbols provided by the MSVC STL (essentially corresponding to libc++abi in the Itanium world) - either linked dynamically or statically.

> since there is no guarantee which one is actually used AFAICT.

Once linked, there are guarantees (contrary to ELF, each imported symbol is tied to be imported from a specific named DLL). On the linking stage, I guess it depends on which library is provided first to the linker.


> Do we try to load the MSVC STL in other places already possibly? IIRC we have some similar sharing elsewhere. If so, maybe we should just use the MSVC provided functions instead and don't bother providing our own. That should address any concerns I have.

I'm sorry I haven't had time to keep up with this PR thread in detail - but this overall also mirrors my concern. But do I understand things correctly, that we so far have been using the function from vcruntime, and MS STL also reimplements this on top of vcruntime? And we can't use those functions from MS STL, but also need to reimplement it on top of vcruntime separately?

https://github.com/llvm/llvm-project/pull/150182