[EXTERNAL] Re: [PATCH] Cygwin: mkimport: implement AArch64 +/-4GB relocations

[Brian Inglis]

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