new c++ new/delete overloads need wrapping?

[Jeremy Drake]

On Fri, 25 Jul 2025, Corinna Vinschen via Cygwin wrote:

> 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.
> >
> 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.

Here's my understanding so far:
GCC's spec for linking on Cygwin includes several --wrap X, one for each
of these symbols.  What this parameter does in LD is that any references
to symbol X are rewritten to __wrap_X, and a definition of X is rewritten
to __real_X.  The Cygwin DLL exports the __wrap_X symbols, so any callers
will end up there.

In order to detect attempts to override the symbols, the Cygwin startup
code defines weak symbols for them with asm redirecting to the __real_X
names, and initializes a struct with pointers to them.  These will be NULL
if the symbols are not defined.  Interestingly, this seems to not count
the jump stubs when the symbols are pulled in from a DLL.  (Neither of
these things are true right now with LLD... Bugs, I guess).  This struct
is then merged and copied to the Cygwin DLL's struct, which is used to
dispatch calls in the __wrap_X functions.

As such, I believe that Cygwin would need to be updated first to provide
the __wrap_X functions, and then GCC would need to be updated to add the
--wrap X linker parameters because that would then reference those
symbols.  I believe GCC after that change would be incompatible with
Cygwin before the new symbols are exported, if those symbols are
referenced (and I was seeing one of the new delete symbols referenced by a
simple delete p; of a scalar, so it may be something a newer now-default
C++ version does).

Takashi has been working on a Clang driver that calls the linker directly
(rather than calling gcc to do the link and relying on its spec), so that
will need to be updated with any new --wrap arguments too.