On Jul 22 10:20, Jeremy Drake via Cygwin-patches wrote: > On Tue, 22 Jul 2025, Corinna Vinschen wrote: > > > On Jul 22 09:12, Radek Barton via Cygwin-patches wrote: > > > Hello. > > > > > > Thank you for this insight. So, if I build tcsh using AArch64 Cygwin > > > GNU toolchain, I should see if this behaves correctly with debugger? > > > > Yes, that would probably be helpful. tcsh overwrites the malloc/free > > entries of __cygwin_user_data in _cygwin_crt0_common(), which is linked > > into the executable. This occurs after dll_crt0_0, but before dll_crt0_1. > > > > So what you should see is somthing like this: > > > > (gdb) br dll_crt0_0 > > (gdb) br dll_crt0_1 > > (gdb) r > > Starting program: /bin/tcsh > > [New Thread 1832.0x4ac] > > [New Thread 1832.0x22d0] > > > > Thread 1 hit Breakpoint 1, dll_crt0_0 () > > [...] > > (gdb) p __cygwin_user_data.malloc > > $6 = (void *(*)(size_t)) 0x7ffc8504cee9 <malloc> <== pointing into > > cygwin1.dll > > (gdb) c > > Thread 1 hit Breakpoint 2, dll_crt0_1 () > > [...] > > (gdb) p __cygwin_user_data.malloc > > $6 = (void *(*)(size_t)) 0x100448940 <malloc> <== pointing into tcsh > > This wouldn't be an import though. I guess malloc would need to be > imported from a different dll for that case...
Yeah, you're right. But even dmalloc is just a static lib, not a DLL, so the executable would be linked against the actual function, not against a jump stub. > > Theoretically import_address() is only required to be able to resolve > > pointers into the Cygwin DLL itself correctly. If it can resolve all > > variations of import table entries created by gcc for the Cygwin DLL, > > it's sufficient. If other variations exist, but are never emitted by > > gcc(*), it would be entirely sufficent if import_address() returns NULL. > > > > tl;dr: As long as it always recognizes > > > > import_address ((void *) user_data->malloc) == &_sigfe_malloc > > > > we're good. > > ... But apparently it doesn't matter if it gets the jump stub or the > imported function for that case. > > Just for the record, these import jump stubs are generated by the linker > (or dlltool as part of the import library). Apparently for the Cygwin > dll, the import library (or at least these parts of it) are generated by > mkimport rather that via the normal dlltool process. So it's probably OK > if this code only recognizes the form of import stub generated by mkimport > which with this patch now matches what MS and LLD generate). It's strange > to me that binutils' dlltool uses an additional instruction that doesn't > seem to be necessary. It may not be a bad idea to either support that or > at least add a comment documenting that that's the case, in case > something later wants to use this function for some other import case. > As long as we recognize the jump stub as created by mkimport, we're good. But yeah, adding a comment to import_address *and* the mkimport script, that the jump expressions need to be kept in sync, might not be the worst idea. Even if we never change that again, it would help the reader. Anybody volunteering? Corinna
