Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

64-bit support for CSGO on Linux and macOS #705

Merged
merged 27 commits into from Dec 20, 2017

Conversation

@TheDS
Copy link
Member

TheDS commented Oct 14, 2017

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.

@TheDS TheDS requested review from psychonic and dvander Oct 14, 2017
@TheDS TheDS merged commit ce1a4dc into master Dec 20, 2017
2 checks passed
2 checks passed
continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
@asherkin asherkin deleted the x64-support branch Feb 2, 2018
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 added 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 added 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
Projects
None yet
2 participants
You can’t perform that action at this time.