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

Jan Beulich jbeulich@suse.com
Tue Jun 10 05:59:50 GMT 2025


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?

Jan


More information about the Binutils mailing list