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

Jeremy Drake sourceware-bugzilla@jdrake.com
Sun Jun 8 05:08:55 GMT 2025
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).


More information about the Binutils mailing list