On Mar 18 10:45, Jeremy Drake via Cygwin-patches wrote: > On Tue, 18 Mar 2025, Corinna Vinschen wrote: > > > On Mar 17 17:39, Jeremy Drake via Cygwin-patches wrote: > > > Since you kind of asked, here's a proof-of-concept that uses udis86 (I > > > left a whole bunch of pointer<->integer warnings since this is a PoC). > > > Tested on windows 11 and 8: > > > > Cool. I like the idea. But obviously, this can't make it into 3.6 > > anymore. > > Right. So the next thing to figure out is how to include udis86. It is > BSD 2-clause license, so that should be fine. The way I see it, we could > either static link it from a Cygwin/MSYS2 package, or vendor it. I keep > coming back to vendoring, there has not been any activity on the > repository in years, there are only a few source files in the library part > of the code, and of them several can be left out because we aren't > intending to generate disassembly text output. There is also a > "standalone mode" macro that gets defined if built as part of the Linux > kernel, which suggests we can define that if inside Cygwin also. We can > also reduce the size impact by removing/disabling the mappping of > instruction mnemonic enum to string since we won't need that either. > > If I want to try that, would it make more sense to drop these files in a > subdirectory of winsup/cygwin, or winsup, or somewhere else?
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. > Should I be moving this discussion to cygwin-developers? (that list > doesn't seem to get much action, and the last time I used it I got > redirected to the cygwin list). We can discuss this on cygwin-developers. It's pretty underused these days. That reminds me, I think we could use it for collecting ideas for 3.7 as well. There's a bit of stuff in the latest POSIX-1.2024 which might be nice in Cygwin, too. Corinna
