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

[Jeremy Drake]

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?

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