DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 56SJw9HQ290953
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 56SJw9HQ290953
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=BswtdofV
X-Recipient: archive-cygwin AT delorie DOT com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 45EB43858CDB
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1753732687;
	bh=fyVAJniaGKbyy+qJK+Pd2hBn+vZb4pcCoRLKZjq23kk=;
	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=BswtdofV+BhzD4gLDHcCyvyvIafDn9jHNRq8F7fSAIkwz+J+2xBJFsR2O9jdYmWzv
	 EDObhgNhX17g3sPoyIgvdkRgwzn10MdLsYPQAX3LV/WkfYFzykcwOywIMCK7xN0x4T
	 Vn0vBk2fGHexwzLiK8UrLvtmYfqHgRVNf92gjxxc=
X-Original-To: cygwin AT cygwin DOT com
Delivered-To: cygwin AT cygwin DOT com
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5169D3858D35
ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 5169D3858D35
ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1753732623; cv=none;
 b=U7XJFj7oxyjllP+8gfLMwgzaKZO80Gii0oy7d2YvNeaX6ZvPQ6C9TcMufygZn1pAP9rskAwgMHFL10yXQWZWUT8Ix7lGK0655f3cJl3Q8BenhMKrYYyC75MZer2yY77Ln9weeIsxOZfnNHwhESBBgg1iYBN9HnKAm7qXUjYNGA8=
ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key;
 t=1753732623; c=relaxed/simple;
 bh=ifjWl8b4Yky5FJjBy6rWRUwehyrGiSoc4/mhA3Azrrc=;
 h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version;
 b=na4JzXKbwUBK1ypw4kPdYwBZtYdHUpXLoKTjti0J3otcuwMkALGFZIUzNqhaCNpHCyM/wK2uuOaoSkt54hjRfbU5eQzauPUB4wOnWyPAkcNOuQG8Wr+vC3+RFCgEOjwGNhUTlvJkE1OemOU5V4cZ8i1E3RL+dpfdLggfEYwLlIM=
ARC-Authentication-Results: i=1; server2.sourceware.org
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5169D3858D35
Date: Mon, 28 Jul 2025 12:57:02 -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: <aIdBw5iSaIonAPbI@calimero.vinschen.de>
Message-ID: <80497791-d323-4204-66ef-4b1a8ff45aa9@jdrake.com>
References: <81535510-8360-1c72-442a-0b630a6d937f AT jdrake DOT com>
 <aINAAW2oh-EfgP0V AT calimero DOT vinschen DOT de>
 <d2b0c82b-7390-7efe-789f-8d11120ec12a AT jdrake DOT com>
 <aIdBw5iSaIonAPbI AT calimero DOT vinschen DOT de>
MIME-Version: 1.0
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: Jeremy Drake via Cygwin <cygwin AT cygwin DOT com>
Reply-To: Jeremy Drake <cygwin AT jdrake 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 Mon, 28 Jul 2025, Corinna Vinschen via Cygwin wrote:

> On Jul 25 11:05, Jeremy Drake via Cygwin wrote:
> > 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).
>
> Unless there's some automatism referencing the __wrap_X functions even
> if the --wrap option isn't present, I don't see this incompatibility as
> much of a problem.  We're trying to maintain backward compat, but that
> doesn't mean an executable created under  and for a newer Cygwin DLL
> has to run under an older DLL.

OK, then the patch adds support for wrapping these functions ends up in a
stable Cygwin release, then GCC is updated to add additional --wrap
parameters for them, and that GCC and binaries it produces will no longer
be compatible with older Cygwin DLLs.  libstdc++ will need to be rebuilt
for that GCC, but this is a time when it's handy that libstdc++ is built
as part of GCC so that's automatic.

Clang & libc++ will need the same treatment.

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