From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-4319.protonmail.ch (mail-4319.protonmail.ch [185.70.43.19]) by sourceware.org (Postfix) with ESMTPS id 40C273858D33 for ; Wed, 15 Feb 2023 12:41:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 40C273858D33 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=protonmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=protonmail.com Date: Wed, 15 Feb 2023 12:40:50 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1676464861; x=1676724061; bh=tXEGdnrtwdU5ExJvOca0WK7QPFCOtBJ4BYsXyWzzCgc=; h=Date:To:From:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=nv3gqL5+rYTIR+rkjavX/Pww8cetdrJcyvLbHx/NY0h/GE5VcEARYWxXoyBji25zw OWpb2dr7dKwep5Wr364I/9A0ZR/WGfUa18cWsqD9nuDxK4bZpP4JNo1Ya8SzbUsljF YjaxTlozgnP2h8hPzL1EqhXwb4rG1HnUieU27ewuqAM6ksZzHbEzvglqpkqDT6j5or EORg4OecGUt8fR739CeQvuDqmCODn3/Yio4f2MG3GhyW6sV/XItbwNt34bYryHNi9/ 75dmiPSYWbDUoidNrzzca+uNHZGPEz2+xFUShj61n8bv3rKgBYwBOBkw8rKL242zZ8 tp+uz4se9+Zbw== To: cygwin@cygwin.com From: w6b7rk5yu4mt25v3 Subject: Re: Fw: Re: Why do these mprotect always fail? Message-ID: <0Qjpbo0t_1WTd9--kVw5gLR1PdJzG7myKYzhxdzDIqnWYwLnywFCtSbekykskWViaSJM_bcLQBEFT_wg4-IApgEYrX5bHFIZH7Ro40oDYGs=@protonmail.com> In-Reply-To: References: Feedback-ID: 67221101:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: You misunderstood what I said. It's really just a naming conflict and a coincident. On the context of the = source code (it's an interpreter), PAGE_SIZE is indeed JIT_PAGE_SIZE (not t= he system page size, but the page size defined internally by the interprete= r). On Linux, the name doesn't conflict. On Cygwin, I found on limits.h and= cygwin/limits.h already defined PAGE_SIZE so it caused a naming conflict: #define __PAGESIZE 65536 #define PAGESIZE __PAGESIZE #define PAGE_SIZE PAGESIZE But the problem not related to the naming conflict. If I renamed PAGE_SIZE = to JIT_PAGE_SIZE, the problem is still there. The problem is Cygwin will no= t work with JIT_PAGE_SIZE =3D 4096. Please have a look at the code I posted= . It will always error with "Unable to mprotect". Sent with Proton Mail secure email. ------- Original Message ------- On Wednesday, February 15th, 2023 at 19:13, Corinna Vinschen wrote: > On Feb 15 11:14, w6b7rk5yu4mt25v3 via Cygwin wrote: >=20 > > Corinna Vinschen wrote: > >=20 > > > cygwin-developers is for developers woking on Cygwin itself, not for > > > developers using Cygwin to develop something else. I dropped the ML > > > from the recipient list. > > >=20 > > > And please don't top-post. Thanks. > > >=20 > > > On Feb 15 09:43, w6b7rk5yu4mt25v3 via Cygwin wrote: > > >=20 > > > > Almost forgot, PAGE_SIZE is set to 4096. This is a Linux applicatio= n, > > > > when I compile on Cygwin it complained that PAGE_SIZE is redefined = but > > > > the compilation was success nevertheless. Only when I run the > > > > application, I always exited with "Unable to mprotect". > > >=20 > > > PAGESIZE is 64K on Cygwin. If you change that, it breaks and you can > > > keep the pieces. > > >=20 > > > It would be nice to send a complete, self-contained STC() in plain C, > > > so reproducing your issue is simple and doesn't require to rework > > > your code to get a running, debuggable testcase. > >=20 > > PAGE_SIZE is just a naming conflict. If you change it to something > > else, JIT_PAGE_SIZE for example, it still fails. >=20 >=20 > You're misunderstanding what PAGESIZE or PAGE_SIZE means. It's the > system page size used for mappings, and it's a fixed value defined by > the system and provided to you by the system headers and, especially, > sysconf(_SC_PAGE_SIZE). >=20 > It's NOT something you can just change and think the result will still > work. Especially given that mmap doesn't know that you changed a macro > in your application code... >=20 > > The problem is Cygwin > > is not fine with the particular value 4096 but the program needs the > > value to be exactly 4096. >=20 >=20 > Sorry, but that can't work. If the program actually demands it, it's > non-portable. >=20 >=20 > Corinna