Use udis86 to walk x64 machine code in find_fast_cwd_pointer

[Mark Geisert]

On 3/18/2025 10:11 PM, 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.
[..fascinating (!) code elided here..]

Are discardable code segments still a thing on Windows?  Could some 
pages in the virtual address space be allocated executable to run the 
thing and then free the space afterwards?  If just once per process 
tree, that wouldn't be so bad, would it?

I don't remember offhand if Closing/Freeing a DLL reclaims the address 
space or not.  If it does, putting the code in a tiny DLL for dynamic 
loading could work.

Just spitballing here.. ignore if unworkable or too gross.

..mark