Re: [fpc-devel] Internal symbols
On Sun, 03 Feb 2019 04:08:46 + "J. Gareth Moreton" wrote: >[...] > Lazarus doesn't even display the error (see bug #34996) Fixed. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Internal symbols
On 03/02/19 17:12, J. Gareth Moreton wrote: Fair enough. What about calling functions like Int via assembly language, since it's currently impossible to do it either via the internal function or using the public symbol that maps to it, since "CALL int" just raises a linker error - I presume it's not as easy as copying some code from procedure-calling node generation: "Error: Undefined symbol: SYSTEM_::=::\_INT$DOUBLE::=::\DOUBLE" It's not possible because Int is not a function, but an intrinsic. This intrinsic can map to a one of several functions in the system unit or may be translated to machine instructions depending on the type of its argument and the target platform (no function for it may even exist in the system unit for certain platforms). The compiler should give a better error when trying to call intrinsics from assembler code though. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Internal symbols
Fair enough. What about calling functions like Int via assembly language, since it's currently impossible to do it either via the internal function or using the public symbol that maps to it, since "CALL int" just raises a linker error - I presume it's not as easy as copying some code from procedure-calling node generation: "Error: Undefined symbol: SYSTEM_::=::_INT$DOUBLE::=::DOUBLE" Gareth aka. Kit On Sun 03/02/19 11:17 , Jonas Maebe jo...@freepascal.org sent: On 03/02/19 05:08, J. Gareth Moreton wrote: > Basically, if you declare a public symbol (either using the "public" > directive or putting it in the interface section of a unit) with a name > that's identical to an internal symbol (I used "FPC_ABSMASK_DOUBLE"), > you get a 'duplicate symbol' linker error... in fact, Lazarus doesn't > even display the error (see bug #34996) - it only appears if you run the > compiler from the command line. The FPC (and _FPC) namespace is reserved for internal use. Detecting such clashes is not possible without adding all declared external symbols to hash tables, which would reduce both compilation speed and increase memory usage. I think it's better to simply document that such symbols are reserved for compiler and RTL usage. > You can get around the above issue if you simply rename the constant or > keep it private. However, there is one other issue that is not so easy > to circumvent, and that's when you try to call an internal function > through assembly language (in this instance, I'm assuming the code is > not cross-platform and I'll be calling the x86_64 version of > fpc_int_real, which is "nostackframe" and only modifies XMM0 and RAX): Calling internal functions directly is unsupported, which is the reason why they are made inaccessible from regular code. Their signature or behaviour can change across compiler versions (or they may even disappear altogether). You can hack around it by declaring external functions mapping to the symbol name of the internal function, but again, that is completely unsupported. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org [1] http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel [2]">http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel Links: -- [1] mailto:fpc-devel@lists.freepascal.org [2] http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Internal symbols
On 03/02/19 05:08, J. Gareth Moreton wrote: Basically, if you declare a public symbol (either using the "public" directive or putting it in the interface section of a unit) with a name that's identical to an internal symbol (I used "FPC_ABSMASK_DOUBLE"), you get a 'duplicate symbol' linker error... in fact, Lazarus doesn't even display the error (see bug #34996) - it only appears if you run the compiler from the command line. The FPC (and _FPC) namespace is reserved for internal use. Detecting such clashes is not possible without adding all declared external symbols to hash tables, which would reduce both compilation speed and increase memory usage. I think it's better to simply document that such symbols are reserved for compiler and RTL usage. You can get around the above issue if you simply rename the constant or keep it private. However, there is one other issue that is not so easy to circumvent, and that's when you try to call an internal function through assembly language (in this instance, I'm assuming the code is not cross-platform and I'll be calling the x86_64 version of fpc_int_real, which is "nostackframe" and only modifies XMM0 and RAX): Calling internal functions directly is unsupported, which is the reason why they are made inaccessible from regular code. Their signature or behaviour can change across compiler versions (or they may even disappear altogether). You can hack around it by declaring external functions mapping to the symbol name of the internal function, but again, that is completely unsupported. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Internal symbols
Hi everyone,
So I've come across a couple of issues recently regarding
internally-defined symbols. One of them involves assembly language, which
is always asking for trouble, but one can be triggered through regular
Pascal code.
Basically, if you declare a public symbol (either using the "public"
directive or putting it in the interface section of a unit) with a name
that's identical to an internal symbol (I used "FPC_ABSMASK_DOUBLE"), you
get a 'duplicate symbol' linker error... in fact, Lazarus doesn't even
display the error (see bug #34996) - it only appears if you run the
compiler from the command line.
You can get around the above issue if you simply rename the constant or
keep it private. However, there is one other issue that is not so easy to
circumvent, and that's when you try to call an internal function through
assembly language (in this instance, I'm assuming the code is not
cross-platform and I'll be calling the x86_64 version of fpc_int_real,
which is "nostackframe" and only modifies XMM0 and RAX):
{ Asm is Intel-style }
MOVSD XMM4, [RIP+TwoPi]
MOVSD XMM5, XMM0
DIVSD XMM0, XMM4
CALL fpc_int_real
MULSD XMM0, XMM4
SUBSD XMM5, XMM0
MOVSD XMM0, XMM5
This snippet of code is equivalent to "D := D - (Int(D / TwoPi) *
TwoPi);", effectively a floating-point version of "D mod TwoPi".
The problem here is that fpc_int_real is not found by the compiler...
however, if you attempt to use "CALL int" instead, you get the following
linker error:
"Error: Undefined symbol: SYSTEM_::=::_INT$DOUBLE::=::DOUBLE"
This is because int() is internally changed to fpc_int_real() by the
compiler when it appears in Pascal code. I could just write my own copy
of fpc_int_real, but that defeats the purpose of it somewhat, not least in
that it causes code duplication and hence increases code size and
maintenance issues. An idea is to improve assembler parsing by correctly
changing such symbols to point to their internal counterparts, but this
runs into the issue that some functions, like abs(), are not actually
functions at all when compiled, but become distinct nodes in the PPU files
and translate into direct lines of assembly language (e.g. abs(DValue)
becomes "ANDPD DValue, [RIP+FPC_ABSMASK_DOUBLE]"), and you can't hope to
smartly change "CALL abs" into such a line of code.
I suppose I'm asking for a discussion on this, because there doesn't seem
to be a clean solution to this. Allowing the compiler access to internal
symbols is possible, but probably asking for trouble, while properly
translating assembler calls to internal routines leads to some troublesome
situations. What do you guys think?
Gareth aka. Kit
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
