[Vm-dev] __builtin_extract_return_addr

stes@PANDORA.BE stes at telenet.be
Thu Sep 17 16:58:28 UTC 2020


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256


Hi,

Originally when I compiled on Solaris, I had both the "Cog" and "Stack" VM
working.

Unfortunately there was a change in april which breaks the "Cog" build.

The "Stack" build continues to work fine for me.

Since early april there is in the following file the following definition :

platforms/Cross/vm/sq.h

#       define getReturnAddress() __builtin_extract_return_addr(__builtin_return_address(0))

Eliot Miranda wrote in the thread:

http://forum.world.st/Broken-5-3-downloads-need-fixing-td5115132.html

"Things are pretty stable. There was one major change to how the VM moves from machine code into the interpreter, replacing a setjmp/longjmp pair with a much lighter-weight "jump-call with substituted return address". But this "just works".  We're able to perform experments without disturbinf=g trunk.  SO for example, adding makefiles to allow building of the VM under clang-cl.exe on Windows was done without affecting the other builds at all."

Is there a compiler flag (#define) to re-enable the old code with
setjmp/longjmp ?

Or is there code in the 'platforms/Cross/vm/sqCog*' files
that could help to implement the required function for 'return address',
if that is not provided by the compiler ... ?

I am hoping to re-enable the old setjmp/longjmp code.

Also note that this may be useful for other users as well,
to be able to 'revert' to the legacy old code.

Regards,
David Stes

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJfY5VfAAoJEAwpOKXMq1Ma9y8H/15hLjTf3aMfdFaPH1aoXNRK
T61XZtbrOuykLH4IqLZpr85bQgtqdAdZqZ4tYtl8H00B4opoKZ+CVfruCDUoQEIJ
uUYpJ9R8bp60DqQ147VakZaBzl7P9z2yn9mq6BGnb4sh/tSS743AIinURt+jqoKM
MKxPf6cQn6r+fsvRNN+N5By9AIGco9t61SUqIcNzrdGRNwoaMOzc/4DfMYhPs6JT
qyP3sJ0/LlJA7nhLSWmRNbkC2aJuYT4WCBTdEyNbs9lkv4CO8OOska8Y5YINgvpl
FbwnyTABZzMdYuBIJevlB3RKPMTsn+ceFDfqcrDC7YzeVVWaZhhzV5wosjHenck=
=bl73
-----END PGP SIGNATURE-----


More information about the Vm-dev mailing list