DMARC-Filter:	OpenDMARC Filter v1.4.2 delorie.com 56PI5Y112318772
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 56PI5Y112318772
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=AVAAetNT
X-Recipient:	archive-cygwin AT delorie DOT com
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org 00BBA384F00C
DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1753466734;
	bh=UUi4URt9lgp6ZluOfHm0HPMP5qq8zYgGwdHu0ZDq31s=;
	h=Date:To:cc:Subject:In-Reply-To:References:List-Id:
	List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe:
	From:Reply-To:From;
	b=AVAAetNTWhwaetpWpTMPZrEvKxFEnMHi0knEAMU1IgHkPr8mdtFC+ypO5aE9QpFSR
	E4MNEoanVQb0Dy7hfOPcrif2L2WekKBFz6o0qeUBePPFCzmu1TWJYqt61EbSHatAH3
	ZklA7M2G8RhNqa3hf3Kc7+plhfokM4X0KgyEWJaE=
X-Original-To:	cygwin AT cygwin DOT com
Delivered-To:	cygwin AT cygwin DOT com
DMARC-Filter:	OpenDMARC Filter v1.4.2 sourceware.org 610CB384F488
ARC-Filter:	OpenARC Filter v1.0.0 sourceware.org 610CB384F488
ARC-Seal:	i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1753466708; cv=none;
	b=UDIHqRF4QlRZEXd3Mxz9BhUOe7/Rdxkkmmo9fGIiip8uxNG50zb0ytwOdsAPOS0EOuk3FtPIs6kRiUwQwkHczDHm3ikqIfD9PTSNSA45RblAuhHTkoCcRH+TqxkGJ8G/xsKdaAw+ryK2/CSPcVfug31Ehobr/1+dTEb0VcBfjLY=
ARC-Message-Signature:	i=1; a=rsa-sha256; d=sourceware.org; s=key;
	t=1753466708; c=relaxed/simple;
	bh=LYvDs6cnA4YP50PvFdNkNAqycOdlUjVr4Tat4EqJBBQ=;
	h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version;
	b=u1GGE4chMSHkE5WOVOrV41C9AmdkiG0E6vWHPguA3ERMDxc7t9cR0JJ9/l8WWHbgK2q3kFfK+okgKdQP61JPHay9WGTom3YG5+W294l7Mw2QMuF4En+KaXK4flgM9U8nmSIc7+ZEjJDhnU3BMzwUyFmGex8oXnNYh9H9vvkSvWM=
ARC-Authentication-Results:	i=1; server2.sourceware.org
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org 610CB384F488
Date:	Fri, 25 Jul 2025 11:05:08 -0700 (PDT)
X-X-Sender:	jeremyd AT resin DOT csoft DOT net
To:	Corinna Vinschen via Cygwin <cygwin AT cygwin DOT com>
cc:	Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
Subject:	Re: new c++ new/delete overloads need wrapping?
In-Reply-To:	<aINAAW2oh-EfgP0V@calimero.vinschen.de>
Message-ID:	<d2b0c82b-7390-7efe-789f-8d11120ec12a@jdrake.com>
References:	<81535510-8360-1c72-442a-0b630a6d937f AT jdrake DOT com>
	<aINAAW2oh-EfgP0V AT calimero DOT vinschen DOT de>
MIME-Version:	1.0
X-BeenThere:	cygwin AT cygwin DOT com
X-Mailman-Version:	2.1.30
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:	Jeremy Drake via Cygwin <cygwin AT cygwin DOT com>
Reply-To:	Jeremy Drake <cygwin AT jdrake DOT com>
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 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.

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

- Raw text -