In the current ongoing effort for sourcemod to fully support 64 bits, we are introducing "virtual address".
# Explanation
Because SourcePawn does not yet support a 64 bits-wide type it's been impossible for any plugins to hold addresses in regular 32-bits wide variable.
A first attempt at solving this issue was made in commit ce1a4dcac0 therein dubbed "PseudoAddress", however this turned out to be an unsatisfactory solution, as any 'high' address if offsetted could turn invalid (or outright be impossible to map).
This leaves us with three alternatives :
- New type
- Convert Address into a handle
- Virtual Address
A new type is the most destructive solution, as it entails breaking every single Address related method. While that solution is still not off the table, we're reserving it as the last attempt should this commit fail.
Converting into a handle type is a good compromise between a brand new type whilst also preserving the Address methods. However, this comes with two issues: the first being that you can no longer offset Address, the second is that we would require authors to free the handle type which will be very confusing. This will likely not be implemented.
# Virtual address
Under a reasonable assumption, we've noted that the average plugin is unlikely to play with more than 4 GB of memory; this shouldn't be too surprising as all valve games were once 32bits and therefore limited to 4GB. Assuming this stays mostly true and a plugin isn't interested with the mapped memory of lesser known modules (like soundlib or matlib), it is fair to assume plugins are unlikely to access more than 4GB of mapped memory. Working with this in mind, we map the memory the plugins are likely to access to our custom virtual address ranges (from 0 to 4Gb, the values of which can fit on 32bits variable). If any memory was missed and plugins were to try an access it later those ranges will be late-mapped to our virtual address ranges until we run out of them.
In order to use virtual addressing, whether on 32 bits or 64 bits. Plugins must now "#include <virtual_address>", as well as use the new SDKCall_VirtualAddress, SDKType_VirtualAddress, LoadAddressFromAddress & StoreAddressToAddress where it's appropriate to.
* Fix pointer to string marshaling in ClientPrefs for x64
* Fix other cases where pointers were formatted with %x
* Fix warnings in ClientPrefs IsAuthIdConnected
* Initial attempt at compiling against tf2_sdk2013
* compilation fix for css
* Switch to AMTL platform arch defines
* Add CBasePlayer forward decl for dods and hl2dm as well
* Update hl2sdk-manifests
* Add dods to CI
* Actually include am-platform.h
---------
Co-authored-by: Kenzzer <kenzzer@users.noreply.github.com>
Co-authored-by: Nicholas Hastings <nshastings@gmail.com>
* Add a PluginIterator methodmap
* Follow convention
* Update sourcemod.inc
* Turn method ReadPlugin into property Plugin
* Requested change
* Update sourcemod.inc
* Curse you VSC
* Follow behavior of other iterators instead of the natives
* Fix a stray space
* Implement a hacked CPluginIterator
* Oops
Copy paste go brr
* Revert a change made before the custom impl
* Create FrameIterator type
This commit adds the FrameIterator type to core sm along with a few
methods around getting the information for each frame.
* Fix incorrect documentation
[skip ci]
* Implement KyleS's Changes
* A nit
This has three major changes to SourcePawn. First, the API now supports the concept of "exceptions". The exception state is a global property of an instance of the SourcePawn VM. Exceptions can be caught or suppressed. Many places in SourceMod have been updated to check exceptions instead of errors.
The new API obsoletes major parts of the embedder API - all but one method of invoking functions is obsoleted, and the debug interface has been scrapped. Extensions using the native API will not be affected, however, ThrowNativeError has been deprecated in favor of ReportError.
Second, the SourcePawn concept of a "stack" has been unified at the API level. A stack frame iterator now iterates over all SourcePawn invocations, rather than the topmost plugin. This makes error handling more consistent and removes another dependency on context-per-plugin.
Finally, the implementation of stack frames has been changed dramatically. Rather than maintain a complicated and expensive return pointer stack, we now rely on the implicit one provided by the CPU. The stack frame iterator now walks the JIT stack directly. This removes many unnecessary bookkeeping instructions from the generated code, in particular making the CALL instruction 40% faster.
These changes required some fair surgery to the JIT. Its error paths are now slightly more complicated, as they have to throw an exception rather than return an error code. In addition, any path that can throw an exception is now responsible for creating an "exit frame", which exists to tell the stack frame iterator about transitions from the JIT to the VM.
When a plugin calls SetFailState it is paused and all natives it
registered are unavailable. Other plugins, which depend on those natives
keep running and error whenever they try to call those natives.
This correctly sets the dependent plugins to an error state as if the
plugin which called SetFailState was unloaded.
