X-Recipient: archive-cygwin AT delorie DOT com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 66898386C591
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1708019300;
	bh=g1rxD6HXwGcDVBw0oQW9sWZgpDV1E09kCe8dWftJR9c=;
	h=References:In-Reply-To:Date:Subject:To:List-Id:List-Unsubscribe:
	 List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:
	 From;
	b=ExVFeUqbLV5yWVhfO8HlR39FzzdNw8KJZZsoylZ4RLbCW15VwTT//kMlYBVk7O950
	 rLEbC0dUesFxKIqXg6ujCf+BLETWeBieDa1rDVAP9Fs0cbHSN9/CpNs8anddNeMSwr
	 g96qlW58XGWZZzR92mA7zUMom/pxXdFPcEgRuxGY=
X-Original-To: cygwin AT cygwin DOT com
Delivered-To: cygwin AT cygwin DOT com
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2CCE7384CBBA
ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 2CCE7384CBBA
ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1708019241; cv=none;
 b=wWj1ZWf/88PTV0RZCR+8p3DItlxpWeQjMFmU6rVy9IJOdbalghp/rtVFMlwg2ZuIARxbJZ4P3x+33O9gmLN2+d20h8jP4/bFd3O+EyaKDFJHlX6C77n83ihQqeIf/NQMh4QiQrXV7EFn9ZjQI0AoFGrDJgHmTVZuYCuUOCKGSMw=
ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key;
 t=1708019241; c=relaxed/simple;
 bh=LrIfKninHued+lQ3fNouXjRuI6QvoEyvjPPnu/2MBG0=;
 h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To;
 b=HQXpn37miCaJoTF7VEdmqUYkLKPWYi3cUGaJBzCZcaItpPf3uWIH7atrm9TIAjVEXj0lBHE1Ah2oW/yKHIsQOTGlAP3EpqDeuvFbWkV22zCLSKkxeEXFG8YBO5m+cdx8DevCfV5H0YzxVT4eYVAofxPHZT1cq4c18UxN+l5DKCA=
ARC-Authentication-Results: i=1; server2.sourceware.org
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1708019237; x=1708624037;
 h=content-transfer-encoding:to:subject:message-id:date:from
 :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
 :subject:date:message-id:reply-to;
 bh=6Gnb8ZvfRJ8t1Sn4hc8Gjg5tcRP98rWm7LrgkcfPqgE=;
 b=qYezUzyUqsOIY5Qd3BAhc6tNI4Y/PfNAZ47gJ8F7ESzd0EDK/9COpct5G9UxS0wCC/
 ClLin2yPMs8I3nx2yoaSaw1AVW62z79Hg+dnpXkGqTvK6MBgDcqVK/guAJZVOMb+aqR7
 yva5g4YiOFruKsOJBXK95EfB45ppgTZ1C451K/sPB91ax1/p8BO7wvinqqBBRC4CwKk4
 5LpH162oH5IkXq80UZ9YuT1ehu+ehuhjPH7BwEKd0QrMWjTz+u2dJsndJ/xZyVjD3SwJ
 r22VJ6Ui9aLumwLEcCKz/owGk2QB6AQMhPVl3NJznY0IX5in8c1sA4hUKs0GLJ8++UPZ
 yHsw==
X-Gm-Message-State: AOJu0YwqIfc1QSP1OUl24I7NxIGXPw3+Evo8OvZ+h4Pwq4KcfmS05W6J
 RYjqc3MSHWfSj4wUsn1j3nBc7ujWBAS+TYDVsfOYHtj9/Myfwh/35Fqdc1Q3y8N6jDQXKTb3mo9
 ER1ClWzEcN55hOxu6+I7a06xaAOuv4FKHdP8=
X-Google-Smtp-Source: AGHT+IEtI4tLabQ5ermQV//E1jmV3+KS7L5wW6SsnJhHCkpGEQGrwjRrVK9hzTHkPmaMH9XjNrl9LZ3p15KVIW8WHHs=
X-Received: by 2002:a81:7cc5:0:b0:607:e374:762e with SMTP id
 x188-20020a817cc5000000b00607e374762emr1522475ywc.16.1708019237485; Thu, 15
 Feb 2024 09:47:17 -0800 (PST)
MIME-Version: 1.0
References: <CAJXgQP0ZpcQXON_oKbgE=S8Y-M=9+b00cZ6s4Het01TCTp3ajA AT mail DOT gmail DOT com>
 <Zcs_54Sakt48iAUd AT calimero DOT vinschen DOT de>
 <ZcuYBL3D2rSjlhNu AT calimero DOT vinschen DOT de>
 <CAJXgQP3YzDiomDUvOG30JfSAbe5d3EgLDRvbsT8yN73aAswPLA AT mail DOT gmail DOT com>
 <Zcu761ZXudxviCKv AT calimero DOT vinschen DOT de>
 <CAJXgQP3L5Wq9ZmVUJ2K+wt04Nh15QTjt2e9SF07TYwS8Bg15rg AT mail DOT gmail DOT com>
 <ZcyNTIuY728RhUTg AT calimero DOT vinschen DOT de>
 <ZczAeBlaEk7Syuwd AT calimero DOT vinschen DOT de>
 <CAJXgQP2ueV4tuTvW5Axm_R6PFX_yHKUuYRwvTy98aPsZCdj8uQ AT mail DOT gmail DOT com>
 <Zc3ggLcaKHjtDjLD AT calimero DOT vinschen DOT de>
In-Reply-To: <Zc3ggLcaKHjtDjLD@calimero.vinschen.de>
Date: Thu, 15 Feb 2024 09:46:39 -0800
Message-ID: <CAJXgQP3ru1OLyw+fg0Oyy1XmsaDyBbedKQgwzpMmJoaX5nLanQ@mail.gmail.com>
Subject: Re: Cygwin installer hangs when running post-install scripts
To: cygwin AT cygwin DOT com, Kevin Ushey <kevinushey AT gmail DOT com>
X-Spam-Status: No, score=-0.7 required=5.0 tests=BAYES_00, DKIM_SIGNED,
 DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,
 SPF_HELO_NONE, SPF_PASS, TXREP,
 T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
 server2.sourceware.org
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-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: Kevin Ushey via Cygwin <cygwin AT cygwin DOT com>
Reply-To: Kevin Ushey <kevinushey AT gmail DOT com>
Content-Type: text/plain; charset="utf-8"
Sender: "Cygwin" <cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by delorie.com id 41FHmNuh006305

Thanks -- I've put the associated WinDbg output up at
https://gist.github.com/kevinushey/cdbd15cdf22e5cdcd094b0ad80347dce.
(Sharing it externally just because it's relatively large.)

The important thing to note is that #RtlGetCurrentDirectory_U appears
to be valid ARM assembly, but not x86_64 assembly. My hypothesis here
is that the stub is used to allow emulated x86_64 processes to call
back into native ARM code... which would further confirm that
disabling the find_fast_cwd_pointer checks for ARM is the correct
choice.

Best,
Kevin

On Thu, Feb 15, 2024 at 1:59 AM Corinna Vinschen
<corinna-cygwin AT cygwin DOT com> wrote:
>
> On Feb 14 13:49, Kevin Ushey via Cygwin wrote:
> > Thanks for your patience. Here's what I've got for the assembly around
> > get_dir. I added a bit of debug logging just so I could get the
> > function addresses:
>
> First of all, thanks for taking the time to debug this further!
>
> > C:\cygwin\bin>cygpath
> > get_dir = 0x7FFB85E251B0
> > rcall = 0x7FFB85E251CB
> >
> > And here's what WinDbg reports:
> >
> >     ntdll!EXP+#RtlGetCurrentDirectory_U:
> > 00007ffb`85e251b0 488bc4     mov     rax, rsp
> > 00007ffb`85e251b3 48895820   mov     qword ptr [rax+20h], rbx
> > 00007ffb`85e251b7 55         push    rbp
> > 00007ffb`85e251b8 5d         pop     rbp
> > 00007ffb`85e251b9 e9721e2b00 jmp     ntdll!#RtlGetCurrentDirectory_U
> > (7ffb860d7030)
> > 00007ffb`85e251be cc         int     3
> > 00007ffb`85e251bf cc         int     3
> >     ntdll!EXP+#RtlGetCurrentPeb:
> > 00007ffb`85e251c0 488bc4     mov     rax, rsp
> > 00007ffb`85e251c3 48895820   mov     qword ptr [rax+20h], rbx
> > 00007ffb`85e251c7 55         push    rbp
> > 00007ffb`85e251c8 5d         pop     rbp
> > 00007ffb`85e251c9 e9e2e82400 jmp     ntdll!#RtlGetCurrentPeb (7ffb86073ab0)
> > 00007ffb`85e251ce cc         int     3
> > 00007ffb`85e251cf cc         int     3
> >
> > I'm not sure what the "EXP+#" prefix here means, but it appears to
> > just be a stub that calls into the real implementation now?
>
> Yes, that seems to be the case, same EXP+#for RtlGetCurrentPeb.
>
> > So, if I'm understanding correctly:
> >
> > 1. Cygwin was expecting to find a 'call' instruction somewhere
> > following (the procedure address for) RtlGetCurrentDirectory_U;
> > 2. The expected 'call' instruction no longer exists; however, by
> > chance, there is a 'jmp' later on that includes '0xe8' in the bytes of
> > the address to be jumped to;
>
> That's it.  Chances are high that the above ntdll code was always more
> or less the same and find_fast_cwd_pointer() failed all the time.  Only,
> it never found the "e8" and so nothing bad happened.
>
> So, as long as we don't know how to fix this correctly, my patch
> 4e77fa9b8bf4 ("Cygwin: find_fast_cwd: don't run assembler checking code
> on ARM64") seems the right thing to do.
>
> What annoys me is that I don't have access to ARM64 myself.  I tried
> to install Windows for ARM64 on a QEmu emulator, but the VM always
> failed to boot into Windows, it just sat there and used up CPU.
> I even contemplated installing an Azure ARM64 VM, but I always shy
> away from cloud services at the point they ask you for your size of
> shoe and your social security number.
>
> Anyway...
>
> > For reference, here's what I see on my Intel Windows 11 machine, where
> > all works as normal (showing up to the "call" instruction)
>
> I wonder if you would be willing to grant us a view into the
> ntdll!#RtlGetCurrentDirectory_U function jumped to from
> ntdll!EXP+#RtlGetCurrentDirectory_U.  Per your above assembler output,
> that would be at 7ffb860d7030.  Would you mind to post the WinDBG
> assembler output of that function as well, even if just for curiosity?
>
>
> Thanks,
> Corinna

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