On Mon, 14 Jun 2021, Liu Hao wrote:
在 6/14/21 1:49 PM, Martin Storsjö 写道:
FWIW we have __declspec(selectany) in a number of places in our headers
already (which expands to the same), but not in the crt/* headers yet. I
don't mind either this or plain __declspec(selectany).
The GCC manual says 'you can use __declspec (selectany) as a synonym for
__attribute__ ((selectany)) for compatibility with other compilers'.
Another approach would be
__attribute__((__used__)) static int* __mingw_reference_charmax =
&mingw_initcharmax;
which results in an unused variable in every .o file - probably nobody wants
that.
Yes that's probably not better, the selectany variant is clearly better
out of those.
I think I'd rather add two double leading underscores to the
mingw_initcharmax symbol too, if we're going to be referencing it from
public headers.
I thought this would require an additional patch, and not just for
`mingw_initcharmax`, as there are a few more in 'crtexe.c'.
Yes that's true, but the other ones in crtexe.c aren't exposed in public
headers yet at least.
Other than that, this looks ok to me.
Should the pointer be made const?
Did you mean `const int*` or `int* const`?
In C++ the latter would make it internal linkage (as if it was declared
`static`), and the compiler would optimize it out if it wasn't otherwise
odr-used, e.g. its address was not taken.
I meant the latter, but that's a good point regarding C++, so nevermind
that comment.
FWIW this way of referencing the variable causes one extra base relocation
in executables that include it, as the absolute address needs to be written
in the data/rdata section. The MSVC equivalent uses an inline function to
reference it, which should generate position independent code - but I'm
less sure that we can be sure that such code actually gets emitted, so this
form probably is more robust against compilers optimizing it out.
MS header uses an `extern inline` function with C++ semantics, which means an
out-of-line copy is always emitted but does not cause multiple definition
errors, should multiple such copies are found. The closest thing to this in
GCC world is weak symbols... but weren't there known issues with some broken
linkers?
This kind of `extern inline` does not exist in GNU C. Actually I haven't
tested whether `selectany` works on functions. The GCC manual page I
referenced in the commit message merely says `selectany` applies to
variables.
Right yes... Normal C++ e.g. declared in a class header are emitted that
way (but that comes with all the extra hairiness regarding inline
functions that might not be emitted and/or optimized out). So unless we
know we can do manual selectany on a plain non-inline C function, I guess
the thing you're proposing is the most robust choice.
// Martin
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
