[libcxx-commits] [PATCH] D100219: [libcxx] [test] Skip alloc counter checks for operations within the libc++ DLL

[Martin Storsjö via Phabricator via libcxx-commits]

mstorsjo added inline comments.


================
Comment at: libcxx/test/std/input.output/filesystems/class.path/path.member/path.concat.pass.cpp:144-146
+  // In DLL builds on Windows, the overridden operator new won't pick up
+  // allocations done within the DLL, so the RequireAllocationGuard below
+  // won't necessarily see allocations in the cases where they're expected.
----------------
ldionne wrote:
> Should this be considered a bug in the Windows runtime? If so, it's not doing any good to work around it in our test suite, we should instead:
> 1. File a bug report to get it fixed, and
> 2. Mark the whole test as being broken until they fix it.
It's not a bug in the Windows runtime that can be fixed reasonably, it's only between libc++ and the executable formats used on the platform.

The root cause is that PE-COFF DLLs are "sealed" two-level namespaces.

If you provide operator new in user code, this overrides libc++'s operator new within that executable, and within libc++ if it is linked statically.

If libc++ is linked as a DLL, all references to operator new within the DLL are hardwired at link time to the operator new provided there. It doesn't have the ELF/MachO feature of a GOT where the executable can override any symbol used in libraries loaded.

So here, the operator new that is overridden in the test, to count allocations, isn't invoked and doesn't count allocations that happen within the libc++ DLL. It does count the ones that are done by calls in the test executable.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D100219/new/

https://reviews.llvm.org/D100219