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? 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).
