On Jul 24 22:41, Jeremy Drake via Cygwin wrote: > I was looking into C++ new/delete --wrap linker options, and noticed that > in a quick test the wrapper for delete was not being called. This was > because delete is being compiled to _ZdlPvm and that symbol is not present > in the --wrap arguments in the GCC spec, and is not part of the > per_process_cxx_malloc struct. I'm not seeing anything in that cxx_malloc > struct like a size or version number, so I don't know a good way to > extend it given that it is part of the startup code linked into every > binary. > > Here are the current symbols from libc++ and how they demangle: > > _ZdaPv operator delete[](void*) > _ZdaPvm operator delete[](void*, unsigned long) > _ZdaPvmSt11align_val_t operator delete[](void*, unsigned long, > std::align_val_t) > _ZdaPvRKSt9nothrow_t operator delete[](void*, std::nothrow_t const&) > _ZdaPvSt11align_val_t operator delete[](void*, std::align_val_t) > _ZdaPvSt11align_val_tRKSt9nothrow_t operator delete[](void*, > std::align_val_t, std::nothrow_t const&) > _ZdlPv operator delete(void*) > _ZdlPvm operator delete(void*, unsigned long) > _ZdlPvmSt11align_val_t operator delete(void*, unsigned long, > std::align_val_t) > _ZdlPvRKSt9nothrow_t operator delete(void*, std::nothrow_t const&) > _ZdlPvSt11align_val_t operator delete(void*, std::align_val_t) > _ZdlPvSt11align_val_tRKSt9nothrow_t operator delete(void*, > std::align_val_t, std::nothrow_t const&) > _Znam operator new[](unsigned long) > _ZnamRKSt9nothrow_t operator new[](unsigned long, std::nothrow_t const&) > _ZnamSt11align_val_t operator new[](unsigned long, std::align_val_t) > _ZnamSt11align_val_tRKSt9nothrow_t operator new[](unsigned long, > std::align_val_t, std::nothrow_t const&) > _Znwm operator new(unsigned long) > _ZnwmRKSt9nothrow_t operator new(unsigned long, std::nothrow_t const&) > _ZnwmSt11align_val_t operator new(unsigned long, std::align_val_t) > _ZnwmSt11align_val_tRKSt9nothrow_t operator new(unsigned long, > std::align_val_t, std::nothrow_t const&)
Wow, these got a lot more since we started to support this back in 2009 and ported to 64 bit in 2013. But first I have to tell you that I'm fuzzy on how this exactly is working together. I can't tell you how this affects GCC or LD. Nevertheless, the code overriding the members in per_process_cxx_malloc is living in the app (_cygwin_crt0_common.cc). If you just append members to per_process_cxx_malloc nad implement the wrappers in cxx.cc and libstdcxx_wrapper.cc, then old apps using the old _cygwin_crt0_common.cc will just not see the new functions. So that should work out of the box, shouldn't it? Corinna -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation: https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
