DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 56P8Xmov1960077
Authentication-Results: delorie.com; dmarc=pass (p=none dis=none) header.from=cygwin.com
Authentication-Results: delorie.com; spf=pass smtp.mailfrom=cygwin.com
DKIM-Filter: OpenDKIM Filter v2.11.0 delorie.com 56P8Xmov1960077
Authentication-Results: delorie.com;
	dkim=pass (1024-bit key, unprotected) header.d=cygwin.com header.i=@cygwin.com header.a=rsa-sha256 header.s=default header.b=qkJ672jM
X-Recipient: archive-cygwin AT delorie DOT com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 979C23852762
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1753432426;
	bh=N8tRnYji+7c2UMscSL9pgpg0dbkd+IU5XgPRVZU2KxY=;
	h=Date:To:Subject:References:In-Reply-To:List-Id:List-Unsubscribe:
	 List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc:
	 From;
	b=qkJ672jM7a5vyNSEGsspcGMX4LpYoOCo9vl51uCTGqFrPo1piMSW/5a6b9E0LQfS4
	 lTaDC8FvZRoYNJbpNmKtO2nTQO+wixvY0q2S/UjezdMWyTL+shDW+JECCiVWlcN/tS
	 fq4Z1WmW4hD19JbHRCQtTOLcAlbsFF1hTkjf59RI=
X-Original-To: cygwin AT cygwin DOT com
Delivered-To: cygwin AT cygwin DOT com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 0FEB4385275E
Date: Fri, 25 Jul 2025 10:27:45 +0200
To: cygwin AT cygwin DOT com
Subject: Re: new c++ new/delete overloads need wrapping?
Message-ID: <aINAAW2oh-EfgP0V@calimero.vinschen.de>
Mail-Followup-To: cygwin AT cygwin DOT com
References: <81535510-8360-1c72-442a-0b630a6d937f AT jdrake DOT com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <81535510-8360-1c72-442a-0b630a6d937f@jdrake.com>
X-BeenThere: cygwin AT cygwin DOT com
X-Mailman-Version: 2.1.30
Precedence: list
List-Id: General Cygwin discussions and problem reports <cygwin.cygwin.com>
List-Unsubscribe: <https://cygwin.com/mailman/options/cygwin>,
 <mailto:cygwin-request AT cygwin DOT com?subject=unsubscribe>
List-Archive: <https://cygwin.com/pipermail/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-request AT cygwin DOT com?subject=help>
List-Subscribe: <https://cygwin.com/mailman/listinfo/cygwin>,
 <mailto:cygwin-request AT cygwin DOT com?subject=subscribe>
From: Corinna Vinschen via Cygwin <cygwin AT cygwin DOT com>
Reply-To: cygwin AT cygwin DOT com
Cc: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com
Sender: "Cygwin" <cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com>

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