[PATCH v3 1/4] bfd,ld,dlltool: Emit delay-load import data into its own section

[Jan Beulich]

On 10.06.2025 23:14, Jeremy Drake wrote:
> On Tue, 10 Jun 2025, Jan Beulich wrote:
> 
>> On 08.06.2025 07:08, Jeremy Drake wrote:
>>> On Fri, 6 Jun 2025, Jeremy Drake wrote:
>>>
>>>> On Fri, 6 Jun 2025, Jan Beulich wrote:
>>>>
>>>>> On 06.05.2025 08:50, Jeremy Drake wrote:
>>>>>> From: LIU Hao <lh_mouse@126.com>
>>>>>>
>>>>> I was meaning to commit this today, but obviously(?) ran it through the testsuite
>>>>> first. This introduces regressions for 3 testcases for both Cygwin and MinGW. Did
>>>>> you not observe these, or did you simply not run the testsuite for either of
>>>>> these (pretty common when it comes to PE/COFF) targets?
>>>>>
>>>>> The failures also appear to point out a problem with the code changes themselves,
>>>>> i.e. it's not just the testcase expectations that need adjustment. For
>>>>> ld-pe/secrel_64.d and ld-pe/secidx_64.d I don't see why suddenly a .didat section
>>>>> would be present in the output. Neither test looks to be using delayload
>>>>> functionality. For ld-pe/tlssec64.d the issue is likely the same, even if it
>>>>> expresses itself differently in the expected vs actual output delta.
>>>>
>>>> Was this with just this patch, or the whole series?  The extraneous .didat
>>>> section was one of the reasons I worked on followup patches to this first
>>>> patch by LIU Hao.
>>>
>>> Specifically, my fix for this issue in the original patch (patch 1) is in
>>> patch 2:
>>>
>>>      /* These zeroes mark the end of the import list.  */
>>> -    LONG (0); LONG (0); LONG (0); LONG (0); LONG (0);
>>> +    . += (__DELAY_IMPORT_DIRECTORY_end__ - __DELAY_IMPORT_DIRECTORY_start__) ? 8*4 : 0;
>>>
>>> The reason there would previously always be a .didat section is because of
>>> these zeros.  By instead doing some arithmatic to only add padding if
>>> there is anything in the delay import directory, the .didat section should
>>> only be present if it's actually needed.  Another issue with that line was
>>> that it was only enough padding for an .idata import directory (5 DWORDs),
>>> not a delay import directory (8 DWORDs).
>>
>> So perhaps this needs pulling ahead then?
> 
> Please let me know if you would prefer just pulling the necessary parts
> into patch 1 for the tests to pass, or to squash all of patch 2 into patch
> 1?

Moving just the necessary parts would be preferred, but I wouldn't insist on
that approach (so long as the descriptions would then also properly reflect
the folded contents).

> In the meantime, I suppose I need to figure out how to run the tests on
> Windows ;)

Assuming you're using Cygwin or MinGW there, running "make check" ought to
be all you need. Provided of course you have the necessary packages installed.

Jan