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:
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?
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;
3. In computing 'rcall', the call to memchr ends up finding that bit,
and everything goes haywire from there.
For reference, here's what I see on my Intel Windows 11 machine, where
all works as normal (showing up to the "call" instruction)
ntdll!RtlGetCurrentDirectory_U:
00007ffe`4cacb640 488bc4 mov rax, rsp
00007ffe`4cacb643 48895808 mov qword ptr [rax+8], rbx
00007ffe`4cacb647 48896810 mov qword ptr [rax+10h], rbp
00007ffe`4cacb64b 48897018 mov qword ptr [rax+18h], rsi
00007ffe`4cacb64f 48897820 mov qword ptr [rax+20h], rdi
00007ffe`4cacb653 4154 push r12
00007ffe`4cacb655 4156 push r14
00007ffe`4cacb657 4157 push r15
00007ffe`4cacb659 4883ec20 sub rsp, 20h
00007ffe`4cacb65d 448bf9 mov r15d, ecx
00007ffe`4cacb660 4c8bf2 mov r14, rdx
00007ffe`4cacb663 b101 mov cl, 1
00007ffe`4cacb665 e8be000000 call
ntdll!RtlpReferenceCurrentDirectory (7ffe4cacb728)
Best,
Kevin
On Wed, Feb 14, 2024 at 5:30 AM Corinna Vinschen
<corinna-cyg...@cygwin.com> wrote:
>
> On Feb 14 10:52, Corinna Vinschen via Cygwin wrote:
> > On Feb 13 15:48, Kevin Ushey via Cygwin wrote:
> > > Here's a bit more information from a debug build of cygwin; here I'm
> > > just trying to launch cygpath.exe:
> > >
> > > (gdb) f 1
> > > #1 0x00007ffa0123ba1f in find_fast_cwd_pointer () at
> > > ../../../../winsup/cygwin/path.cc:4526
> > > 4526 const uint8_t *lock = (const uint8_t *)
> > >
> > > (gdb) bt
> > > #0 memmem (haystack=<optimized out>, hs_len=<optimized out>,
> > > needle=0x7ffa0142e531 <_C_collate_locale+59857>, ne_len=4) at
> > > ../../../newlib/libc/string/memmem.c:161
> > > #1 0x00007ffa0123ba1f in find_fast_cwd_pointer () at
> > > ../../../../winsup/cygwin/path.cc:4526
> > > [...]
> >
> > Ok, so we know now which memmem call fails, so the next question is,
> > why? The haystack address is unfortunately still optimized out in
> > memmem, so it looks like the newlib subdir is still optimized.
> > But it's pretty certainly a wrong haystack address. This address has
> > been fetched from
> >
> > const uint8_t *rcall = (const uint8_t *) memchr (get_dir, 0xe8, 80);
> > ...
> > const uint8_t *use_cwd = rcall + 5 + peek32 (rcall + 1);
> >
> > Chances are high, that the call instruction found by rcall is bogus.
>
> Can you run this in GDB? I'd love to see the assembler code starting at
> address `get_dir'...
>
>
> 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
