On 3.03.2025 14:22, Alvin Wong wrote:
I think both the current approach of lacking load config and the
proposed solution are fragile. Instead of relying on unrelated linker
warnings, if such a warning is necessary, it should be implemented
properly, with a clear message that users can understand without
needing to dive into mingw-w64 specifics.
I’ve attached a possible solution on the LLD side. In its current
form, it would warn on recent CFGuard-enabled mingw-w64 due to the
missing @feat.00 flag, but it's just an example of a potential approach.
Thanks for the suggestion. I think it is a nice idea to add. But in
practice, since the current loadcfg has been missing the `@feat.00`
flag we cannot rely on it in the short term. Besides, at least for
MSVC target, users can provide their own `_load_config_used` data
structure (which is rare, but does seem to happen occasionally) and in
that case we cannot use check its object file to determine something
about the runtime.
I guess you can say perform the check only in mingw mode, but in that
case maybe it would be better to check something directly from
mingw-w64 that already has the flag today, like gccmain.o in
libmingwex.a (for example)?
But it'll also need to consider the case of linking with `-nostdlib`.
MinGW targets may provide their own load config or even an entire CRT
(with -nostdlib). In such cases, it makes more sense to check the actual
file being used rather than tying it specifically to libmingwex.a.
Maybe we could use the entry point symbol instead of load config. This
wouldn't work with -noentry, but I don't think it needs to be fully
bulletproof, as long as it avoids false positives. The current solution
isn't entirely robust either; for example, one could use a non-CF Guard
mingwex build along with a custom _load_config_used.
Thanks,
Jacek
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
