On Feb 14 15:01, Jon Turney wrote: > On 13/02/2026 19:35, Corinna Vinschen wrote: > > From: Corinna Vinschen <[email protected]> > > > > This makes sure that we only ever handle images which can be executed > > on the current architecture. > > > > Signed-off-by: Corinna Vinschen <[email protected]> > > --- > > winsup/cygwin/hookapi.cc | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/winsup/cygwin/hookapi.cc b/winsup/cygwin/hookapi.cc > > index b0126ac04e3e..5b25443c8365 100644 > > --- a/winsup/cygwin/hookapi.cc > > +++ b/winsup/cygwin/hookapi.cc > > @@ -43,10 +43,13 @@ PEHeaderFromHModule (HMODULE hModule) > > /* Return valid PIMAGE_NT_HEADERS only for supported architectures. */ > > switch (pNTHeader->FileHeader.Machine) > > { > > +#if defined(__x86_64__) > > case IMAGE_FILE_MACHINE_AMD64: > > break; > > +#elif defined (__aarch64__) > > case IMAGE_FILE_MACHINE_ARM64: > > break; > > This needs to be followed by > > #else > #error "u wot?" > > > +#endif > > default: > > return NULL; > > From Igor's analysis, ever returning NULL here seems like a bad idea, as it > causes apparently unrelated things to stop working.
It's just the iscygwin() test going wrong, but yeah, that has unwelcome side-effects. > Maybe we should just abort there instead? > > I've forgotten all the details of exactly what hookapi is doing, so I'm not > sure if that kind of mixing can ever happen (It seems like not - does the OS > even let us load DLLs of a different machine type to that of the process?) I actually had to look this up and it turns out that we really can't load a DLL from another architecture. Unless you build the Cygwin executable as ARM64EC binary, which also allows to load AMD64 DLLs. The DLLs are then running in a x86_64 emulation. I just don't think we should support this, or, should we? Corinna
