On Mar 20 13:01, Jeremy Drake via Cygwin-patches wrote: > 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
find_fast_cwd_pointer_x86_64 > another source file for find_fast_cwd_pointer_arm64? Or I guess put both find_fast_cwd_pointer_aarch64 We should use the offical tags, not the Windows ones. It's ok for the uname output, but other than that... > into a fastcwd.cc and #ifdef __x86_64__ the x64 variant (that will of > course always be true at this point)? A new fastcwd.cc would make sense. Theoretically the aarch64 code should go into an aarch64 subdir, just as with the x86_64 subdir, but I guess this is handling the AMD64 on ARM64 emulation rather than the native ARM64 mode? Will there be any difference between the two later on if we start supporting native ARM64? If so, the name of the function should probably express this. Thanks, Corinna
