On Wednesday 28 August 2024 14:23:40 Martin Storsjö wrote:
> On Wed, 28 Aug 2024, LIU Hao wrote:
>
> > 在 2024-08-28 03:15, Pali Rohár 写道:
> > > Use gcc's function attribute naked which omits any prologue or epilogue
> > > sequences and for x86 is supported by gcc since version 8.0.0. It is also
> > > supported by clang. For older gcc versions use existing code.
> > >
> > > This change fixes compile warning:
> > >
> > > stdio/_scprintf.c:32:20: warning: ‘init_scprintf’ used but never defined
> > > static int __cdecl init_scprintf(const char * __restrict__ format, ...);
> > > ^~~~~~~~~~~~~
> >
> > I think that introducing such complexity for just silencing a warning is
> > an overkill.
>
> I somewhat agree, but I don't have a very strong opinion on it. In one
> sense, we're lying to the compiler, when we claim something is a static
> function, but it doesn't exist in the C source of the translation unit, so
> it wouldn't surprise me if a future compiler could break this case.
Personally I do not think that this change is overkill.
Currently the init_scprintf implementation is in assembly.
And we have two options how to put this assembly code into C.
1) Via C naked function as:
__attribute__((naked))
static int __cdecl init_scprintf(...)
{
asm ( ... ASM CODE HERE ... );
__builtin_unreachable();
}
2) Via assembly wrapper:
asm (
".def\t" ASM_SYM(init_scprintf) ";\t.scl\t3;\t.type\t32;\t.endef\n"
ASM_SYM(init_scprintf) ":\n\t"
... ASM CODE HERE ...
);
For me the more overkill is second option with manually defining
function header in assembly with store type, etc...
Another argument for attribute naked is that it works better with LTO
than declaring function and its storage type in ASM.
> > If this file is only ever compiled for i686 then I would prefer the
> > resolver function to be implemented in assembly. The `ASM_SYM` macro is
> > no longer necessary.
>
> I guess that's possible, but the more assembly code we have, the less
> maintainable it is. (I'm personally not very fluent in x86 assembly,
> contrary to arm/aarch64.)
>
> A different way of getting rid of the warning, and making it safe for the
> compiler, would to just make the symbol extern instead of static, and adding
> e.g. a __mingw prefix to it. It's less elegant than having a static symbol,
> but feels like a reasonable tradeoff between safe and maintainable code,
> exposing symbols, and using fancy compiler features optionally.
>
> (A way to make it less overkill could be to just require a compiler that
> supports the attribute. But I guess there can be users who want to use the
> latest mingw-w64 with old compilers too?)
>
> // Martin
Personally I would rather have as much code in C than in ASM. Rewriting
exiting code from C to ASM, including the resolver should be possible
but I think that this is huge work and this is something which I say is
overkill.
I'm looking at it from perspective, if something can be written in C
(with possible gcc/clang extension) then I would prefer to use C than ASM.
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
