On 8.05.2024 14:22, Martin Storsjö wrote:
Prior to 1652e9241b5d8a5a779c6582b1c3c4f4a7cc66e5, the inline
functions always were static. Due to reexporting such symbols
in C++20 modules (for the C++23 std module), the reexported symbols
must not be static, so the inline functions were changed
from static inline to __mingw_ovr, which practically is static
inline in C mode, but regular inline in C++ mode.

By using regular inline in C++ mode, each use of the functions
can (but doesn't need to) emit an external symbol for the
inline function, and the callers may either call that function
or inline the body of the function.

This can have two potential issues; if different translation units
are configured differently (with the _USE_32BIT_TIME_T define),
but both use the same external symbol for it, the linker will only
keep one of them (as they're both inline, and supposed to be the
same). In practice, this is rare for _USE_32BIT_TIME_T though.

Secondly, such an external symbol may conflict with the actual
import library. Such a case was reported at
https://github.com/mstorsjo/llvm-mingw/issues/427.

(Practically, the issue there was that some built object files
defined an external "_time" symbol, i.e. regular "time" with i386
cdecl underscore prefix, from the non-static inline functions. The
object also files reference _time32 with dllimport, which via the
weak aliases produced by llvm-dlltool end up pulling in the
__imp__time symbol, which also brings in a conflicting "_time" symbol.)

In short - inline functions can be problematic. Where possible,
it's less problematic to use asm(), via __MINGW_ASM_CALL(), to
redirect calls directly towards the right function.

This has a slight drawback, that this ends up calling the thunks
(as the declarations lack dllimport), while we previously could
inline the call directly to a dllimported function (avoiding the
thunk, fetching the target address via the __imp_ prefixed symbol).

We could, easily, add the dllimport attributes on these declarations,
but that triggers a GCC bug for how those symbol names are mangled
on i386, see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114984. (The
bug seems to be noted and mentioned as early as 2007, in
https://sourceware.org/pipermail/cygwin/2007-February/154845.html,
but it doesn't seem to have been fixed since.)

Signed-off-by: Martin Storsjö <mar...@martin.st>
---
  mingw-w64-headers/crt/time.h | 62 ++++++++++++++++--------------------
  1 file changed, 28 insertions(+), 34 deletions(-)


Looks good to me.


Thanks,

Jacek



_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Reply via email to