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

Reply via email to