From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from m0.truegem.net (m0.truegem.net [69.55.228.47]) by sourceware.org (Postfix) with ESMTPS id 4DF4A3865488 for ; Fri, 5 Mar 2021 09:18:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 4DF4A3865488 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=maxrnd.com Authentication-Results: sourceware.org; spf=none smtp.mailfrom=mark@maxrnd.com Received: (from daemon@localhost) by m0.truegem.net (8.12.11/8.12.11) id 1259IFqV018150 for ; Fri, 5 Mar 2021 01:18:15 -0800 (PST) (envelope-from mark@maxrnd.com) Received: from 162-235-43-67.lightspeed.irvnca.sbcglobal.net(162.235.43.67), claiming to be "[192.168.1.20]" via SMTP by m0.truegem.net, id smtpd0BOSZE; Fri Mar 5 01:18:07 2021 Subject: Re: segfault on 32bit cygwin snapshot To: cygwin@cygwin.com References: <9d7b9dc2-cb92-498b-7655-e9c618114c87@gmail.com> <20210221072954.db2dcbd523ed366e4dfcb0d0@nifty.ne.jp> <7480c946-8e02-aba2-c06f-6b39f630699f@gmail.com> <20210301095546.dce31a474bd0cec2c3518f87@nifty.ne.jp> <20210301212542.8b1749f92af62c01b008f25a@nifty.ne.jp> <20210302200308.62db4fe01f78fb35a538784f@nifty.ne.jp> <20210303185621.b048287526901af6a4c8200a@nifty.ne.jp> From: Mark Geisert Message-ID: <00624789-7d57-4e80-26f0-a48e9893b6c9@maxrnd.com> Date: Fri, 5 Mar 2021 01:18:08 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.4 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.5 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, NICE_REPLY_A, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: cygwin@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Mar 2021 09:18:17 -0000 Hi Corinna, Corinna Vinschen via Cygwin wrote: > On Mar 4 01:05, Mark Geisert wrote: >> Corinna Vinschen via Cygwin wrote: >>> Is there a way around that? I'm not quite sure, so let's brain storm >>> a bit, ok? >>> >>> - One thing we could try is to remove the above code, but add a python >>> hack to dlsym instead. This would let the "old" DLLs work again as >>> before and for python we could add a hack to dlsym, along these lines: >>> >>> if (CYGWIN_VERSION_CHECK_FOR_UNAME_X >>> && modulehandle == cygwin1.dll >>> && strcmp (symname, "uname")) >>> symname = "uname_x"; >>> >>> Thoughts? Other ideas? >> >> That's a sly fix, but it seems that it would do the job. That's good! >> >> On a different tack, I was thinking about how run time code could tell the [...somewhat of a dead-end tangent elided...] > However, it's not clear how this fixes the actual problem. We just > don't have a way to know what size the caller expects. > > Having version or size info in structs like the Win32 API does in a > couple of cases makes a lot more sense now... Indeed. I like your dlsym proposal, but I would code the "modulehandle == cygwin1.dll" first as it's less likely to be true than the version check. I think "the above code" you mentioned still needs to be retained to deal with old exes calling uname directly and needing the old version. Shall I write up a patch and submit it? Thanks & Regards, ..mark