On Nov 26 17:25, Jeremy Drake via Cygwin-patches wrote: > On Tue, 26 Nov 2024, Jeremy Drake via Cygwin-patches wrote: > > > On Tue, 26 Nov 2024, Corinna Vinschen wrote: > > > > > Btw... > > > > > > We're doing this because nobody being able to debug ARM64 assembler came > > > up with a piece of code checking the ntdll assembler code to find the > > > address of the fast_cwd_pointer on ARM64. > > > > > > You seem to have the knowledge and the means to do that, Jeremy. > > > > > > Any fun tracking this down? > > > > Ha, no, not really. I looked into something similar trying to get Ruby > > running on Windows on ARM64, and learned enough to know that how ARM64 > > encodes addresses is odd enough that I didn't want to dig further ;) > > > > Somebody else did end up implementing getting a private variable (out of > > UCRT) by looking at ARM64 assembler, maybe that could work as a starting > > point? > > > > https://github.com/ruby/ruby/commit/784fdecc4c9f6ba9a8fc872518872ed6bdbc6670#diff-883ccab70529ab9c4e51fa7b67e178a205940056b21cd123115ebadd8029f50f > > > I had a quick look in the debugger, and it's even worse than that... > > First, because we're running emulated x64 code, the address returned from > GetProcAddress is an x64 stub, presumably to exit emulation and call the > native function. Ok, not too bad, there's a jmp instruction in there to > the ARM64 function... In RtlGetCurrentDirectory_U, again pretty > straightforward, first call is to RtlpReferenceCurrentDirectory... In that > function, however, is where things get intesting. It's still much the > same theory as described for x86_64, however: > > 1) note that loading an absolute pointer on ARM64 involves 2 instructions. > The instructions getting the address of the fast peb lock and the fast cwd > pointer are actually *interleaved*, the upper bits of the fast cwd pointer > are loaded before the upper bits of the fast peb lock, but the lower bits > are not added until *after* the RtlEnterCriticalSection call. > > 2) the registers used differ between Windows 10 22H2 and Windows 11 23H2 > (these are what I had handy - who knows what other versions do). > > Also, because of the x64 stub thing, the address you'd get from > GetProcAddress for RtlEnterCriticalSection would differ from the native > RtlEnterCriticalSection actually called by the ARM64 code.
Yeah, that sounds... icky. Thanks, Corinna
