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-cyg...@cygwin.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
