On 2025-07-22 11: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...
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.
Perhaps an implementation glitch, erratum, exception level or execution state
issue in some early ARMv8 AArch64 SoC target loader?
--
Take care. Thanks, Brian Inglis Calgary, Alberta, Canada
La perfection est atteinte Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add
mais lorsqu'il n'y a plus rien à retrancher but when there is no more to cut
-- Antoine de Saint-Exupéry
