On Wednesday 11 December 2024 15:17:55 Martin Storsjö wrote: > On Mon, 9 Dec 2024, Pali Rohár wrote: > > > I see that in mingw-w64-crt/lib32/ are lot of def files which are > > basically same as def files in mingw-w64-crt/lib-common/, just lib32 > > variants have @STDCALL suffixes. They have same set of functions (just > > sometimes there are arch-specific available only for I386 or similar). > > > > I was thinking if it would be possible to merge them and have just one > > def file for both I386 and non-I386 variants. > > > > For example there is mingw-w64-crt/lib32/kernel32.def and > > mingw-w64-crt/lib-common/kernel32.def.in and if it would be possible to > > merge them into one file. > > > > What about having one def file kernel32.def.in where would be also > > @STDCALL suffixes and when building non-I386 variant, the build process > > will filter that file over sed 's/@[0-9]*$//' and then process by cpp > > preprocessor? (Or first process by cpp and then by sed) > > > > This could decrease the need to have more def files for the same library > > (e.g. kernel32) and also maintenance of different variants of def files. > > Yes, I've thought about this already back when we started merging def files > into lib-common. But then I initially thought about using the preprocessor, > something like API(func, 8) which either appends @8 or not. But as you > noticed, pasting @ with other symbols with cpp is problematic...
I tried to write such "API" and I failed too due to pasting with @ char. > Your suggestion of using some form of sed expression could achieve the same, > and would also avoid needing to rewrite things from what gendef or other > tools output - so that makes it much easier to accept. > > For the vast majority of APIs outside of the core of complicated ones (CRTs, > kernel32 and similar), the set of symbols exported is indeed identical > across all architectures - i386 is usually not different from the other > ones, apart for the stdcall suffix. (Although some DLLs have symbols that > only are available e.g. in the 64 bit versions, but this is not common and > the distinction usually doesn't matter much either.) Even kernel32 is very similar, there are only few differences currently. And it is questionable if those differences are real, or just issues in mingw-w64 definitions. > For the currently merged ones (arm32, arm64 and x86_64), the fact that they > are merged is usually zero cost, as the files would be identical anyway. But > if start using stdcall based ones as main input, we'd have the extra > overhead, that if we want to add a def file for a new library, we'd first > need to find an i386 version of the DLL and dump that. > > (Consider if i386 support in Windows gets phased out at some point? I guess > that never will happen, but perhaps there'll be no more new APIs in i386 > form?) > > Today, if contributors who update def files are thorough and consistent, > they update both the lib32 and lib-common versions at the same time, so the > burden of finding an i386 version of the DLLs already is present, this > doesn't make any difference. But if they don't have such a version, they can > also just update the lib-common version and let lib32 lag behind. We already preprocess .def.in files via cpp, so we can add "#ifndef DEF_I386" block and put there all symbols without @SUFFIX. I see the advantage of one def(.in) file for library, as this will ensure that we have consistent set of symbols for all architectures and that we do not forget to add some symbol for I386 variant by mistake. It is possible that by mistake somebody forgot to add some symbol to both lib-common/name.def and lib32/name.def files. And also for reviewers it is harder to figure out if there is missing adjacent change for second def file or not. > So my opinion on your suggestion is "maybe" - it's of course not ideal that > there is this level of duplication, but as most of those files don't have a > lot of manual fixups/tweaks like the core def files, I'm not sure if the > burden of having lib32 + lib-common is very big, compared with the extra > build process complication, and for updating everything via the @stdcall > suffix form. If the definitions are constant and not changing at all (which is the case for versioned msvcr*.def files) then duplication is not a big problem, we just need to review it once. But if the definitions are changing in time (which is the case for kernel32.def as MS is adding new and new symbols into system libs), all those duplications needs to be reviewed at every change. Also it is questionable how many def files have unintentionally different set of symbols for I386 and x64, and should be fixed. Avoiding duplication can be more friendly also for newcomers who want to change def file as they do not have to know that it is required to change two adjacent def files for one change. That is my opinion. > If you'd have a working PoC patch for it, it would be easier to judge the > tradeoff. I'm also interested in hearing Biswapriyo's opinion, as they > probably are the ones who do most the work in updating them these days - > would this ease the burden noticably, or would the amount of work mostly be > the same? > > // Martin If you are open for this idea, that it is not totally stupid thing (I was not sure that is why I opened this discussion before trying to implement anything) I can try to prepare some PoC patch. _______________________________________________ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
