On Fri, 7 Mar 2025, Jeremy Drake via Mingw-w64-public wrote: > On Fri, 7 Mar 2025, Jeremy Drake via Mingw-w64-public wrote: > > > That bug was avoided, due to the fact that the code that tries to > > garbage-collect unused stubs only looks at .idata sections, and delayloads > > are now in .didat sections. > > > > However, this patch is probably overkill. This puts the whole of the > > delay load stuff into .didat, while only the IAT needs to be there > > (writable). I will try just moving .idata$5 into .didat$5 and see what > > happens. > > I tried the attached patch, and it works, but brings back the bug I > referenced for 32-bit. > > > Also, I noticed in objdump that the Delay import directory entry in the > > optional header is 0. This may have been the case before, I'm not seeing > > any code to fill it in. > > This needs some symbols or sections for the delay import directory table. > Right now, it is put into .text$2, which seems like a hack for the fact > that putting it into .idata$2 would have messed up the normal import > directory. > > I am confused by what LLD is doing though. It is putting the functions and > modules into .data, and the read-only stuff into .didat. The way I read > the docs suggested to use .didat to hold the function pointers so that the > guard flags could allow the OS to change protection as needed without > affecting other data.
OK, apparently I forgot to attach the patch last time. Oh well, here's a new one! This patch unfortunately does a few different things at this point: * moves delay load directory table into .didat$2 section, and puts this into .idata(!) * fills in the delay import descriptor table data directory entry * fills in the load config table data directory entry if _load_config_used is present (it isn't unless it's actually referenced by an object) * moves delay load IAT into .dadat$5 section, which goes into new .didat section * fixes https://sourceware.org/bugzilla/show_bug.cgi?id=14339 by excluding delay import stubs from being excluded I've only tested this in MINGW32, but it works even when hex editing the load config guard flags to make Windows protect the delay load IAT (this still wants the default flags for the section to be read/write, and Windows will take away write access at load time). This is more than can be said for LLD at this point, because it puts the IAT itself in the .data section it blows up early if Windows takes away write access from pages in it. Martin, do you know anything about this? I'm not at all convinced that your initial idea to put all of the delay load stuff into the new .didat section isn't the way to go. It seemed to me like only the IAT needed to go in the section where its protection changed. The module handle is still in .data, do you think it was intended to put that in .didat also so it also gets write protected? The docs do say: Delayload import table in its own .didat section (with nothing else in it) that can be freely reprotected. #define IMAGE_GUARD_DELAYLOAD_IAT_IN_ITS_OWN_SECTION 0x00002000 Which is what this patch currently does. Feel free to pick this up and continue working on it. _______________________________________________ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
