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 cc: Corinna Vinschen Subject: Re: new c++ new/delete overloads need wrapping? In-Reply-To: Message-ID: References: <81535510-8360-1c72-442a-0b630a6d937f AT jdrake DOT com> 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Jeremy Drake via Cygwin Reply-To: Jeremy Drake 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" 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