64-bit support for CSGO on Linux and macOS #705
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…memory addresses. This is a stop-gap solution until SourcePawn is able to handle 64-bit integers natively. Pseudo addresses are made up of a 6-bit table index and a 26-bit offset. The table consists of base addresses to memory allocations. Using a scheme like this allows a limited amount of pointer arithmetic to be performed.
…doAddrManager in 32-bit builds.
psychonic
approved these changes
Oct 22, 2017
peace-maker
added a commit
to peace-maker/sourcemod
that referenced
this pull request
Apr 9, 2019
In alliedmodders#705 SourceMod received support for x64 binaries. The `IBinTools` interface was updated to call functions in 64bit binaries. The `PassInfo` struct's size was increased and the `Create(V)Call()` functions signatures changed, thus making the interface incompatible for consumers which were compiled against an earlier version. `SMInterface::IsVersionCompatible` wasn't adjusted to that fact, so extensions compiled against pre SM 1.10 could request an `IBinTools` interface pointer, but crash when they try to use it. This change makes requests to older interface versions invalid, thus letting `RequestInterface` return `NULL` for older extensions. It doesn't fix the backwards incompatibility, but at least makes the problem more blatant, so extensions can handle it themselves.
KyleSanderson
pushed a commit
that referenced
this pull request
Apr 11, 2019
In #705 SourceMod received support for x64 binaries. The `IBinTools` interface was updated to call functions in 64bit binaries. The `PassInfo` struct's size was increased and the `Create(V)Call()` functions signatures changed, thus making the interface incompatible for consumers which were compiled against an earlier version. `SMInterface::IsVersionCompatible` wasn't adjusted to that fact, so extensions compiled against pre SM 1.10 could request an `IBinTools` interface pointer, but crash when they try to use it. This change makes requests to older interface versions invalid, thus letting `RequestInterface` return `NULL` for older extensions. It doesn't fix the backwards incompatibility, but at least makes the problem more blatant, so extensions can handle it themselves.
asherkin
added a commit
that referenced
this pull request
Oct 17, 2019
PR #705 made some changes for 64-bit support that required callers to provide a buffer for object storage, but only added the required code to the non-virtual call builder, not the virtual call builder. Copy it over to CreateValveVCall so that ValveParamToBinParam stops writing to a null pointer. Fixes #1059 (Hopefully.)
Headline
pushed a commit
that referenced
this pull request
Nov 1, 2019
PR #705 made some changes for 64-bit support that required callers to provide a buffer for object storage, but only added the required code to the non-virtual call builder, not the virtual call builder. Copy it over to CreateValveVCall so that ValveParamToBinParam stops writing to a null pointer. Fixes #1059 (Hopefully.)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This enables SourceMod to run on 64-bit Linux and macOS using the SourcePawn interpreter. There's a lot here, but I tried to split it up into reviewable chunks.
By far the most the time-consuming part of this was bintools. I'd appreciate an eye from @dvander on this part in particular. Although this PR is mainly for Linux and macOS, there's support for 64-bit Windows in here as well. Note that IBinTools2 has been removed as a public interface. It doesn't appear to actually be used by anyone and the additional flags that were added to support 64-bit calling conventions made combining these with the SourceHook version of parameter information kind of a nightmare.
The other notable change here is using what I call "pseudo addresses" on 64-bit platforms in any place that a native returns or is passed a memory address. A pseudo address consists of a 6-bit table index and a 26-bit offset. The table consists of base addresses to memory allocations. Using this kind of scheme allows some pointer arithmetic to be performed by a plugin. See core/logic/PseudoAddrManager.cpp for further details. I'll note that using dladdr was not an option here because GetEntityAddress for example returns addresses to things on the heap. The choice of 6 and 26 bits is kind of arbitrary, so we could adjust this as we see fit.
To allow plugins to continue working as-is on 64-bit platforms, pseudo addresses seemed like the best option. It is by no means a perfect solution though. I considered the fact that we could add a new native that uses an array for the low and high bits of the address, but that would require plugin authors to opt in to using it. @dvander has discussed the possibility adding support for int64 and/or intptr to SourcePawn which might give us a better solution, but in the mean time I figure we can use this.
Everything else beyond this was pretty straightforward I think.