[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.
----------------
mstorsjo wrote:
> 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.
If you'd prefer, I could narrow it down to the windows+dll case - that'd be a bit more verbose, but should be doable.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100219