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 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. Corinna (*) Or clang, but I don't think we can build Cygwin with clang yet anyway
