[fpc-devel] Internal symbols
J. Gareth Moreton
gareth at moreton-family.com
Sun Feb 3 17:12:41 CET 2019
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 jonas at 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 at 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 at lists.freepascal.org
[2] http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20190203/b90ac373/attachment.html>
More information about the fpc-devel
mailing list