On Thu, 20 Mar 2025, Corinna Vinschen wrote: > On Mar 20 15:03, Corinna Vinschen wrote: > > On Mar 18 22:11, Jeremy Drake via Cygwin-patches wrote: > > > On Tue, 18 Mar 2025, Corinna Vinschen wrote: > > > > > > > Subdir of winsup/cygwin, probably. What I'm most curious about is the > > > > size it adds to the DLL. I wonder if, say, an extra 32K is really > > > > usefully spent, given it only checks a small part of ntdll.dll, and only > > > > once per process tree, too. > > > > > > I did this with msys-2.0.dll, but it shouldn't matter as a delta. > > > all are stripped msys-2.0.dll size > > > start: > > > 3,246,118 bytes > > > with udis86 vendored, but not called: > > > 3,247,142 bytes > > > with find_fast_cwd_pointer rewritten to use udis86: > > > 3,328,550 bytes > > > > > > (I know the second one isn't realistic, the linker could exclude unused > > > code, I was just kind of curious) > > > > > > This is with all the "translate to assembly text, intel or at&t syntax" > > > and "table of strings for opcodes" stuff removed to try to save space, > > > still a net increase of 82,432 bytes. > > > > The DLL has currently a size of 3 Megs, optimzed, stripped. 82K are > > two more allocation granularity slots, 51 instead of 49, about 2%. > > 4! 4%. I said 4%, right? > > *facepalm*
I'll take that as "patches welcome" :) I'd also like to take the opportunity to add ARM64 support based on my PoC, but I feel bad about dropping another blob of code into path.cc. Would it make sense to rename to find_fast_cwd_pointer_x64, move it into a separate source file, and add another source file for find_fast_cwd_pointer_arm64? Or I guess put both into a fastcwd.cc and #ifdef __x86_64__ the x64 variant (that will of course always be true at this point)?
