2015-05-23 22:55:12 -06:00
|
|
|
// Copyright 2014 Dolphin Emulator Project
|
2021-07-04 19:22:19 -06:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-or-later
|
2014-04-09 00:22:52 -06:00
|
|
|
|
|
|
|
#pragma once
|
|
|
|
|
2017-01-07 16:10:39 -07:00
|
|
|
#include <cstddef>
|
2017-03-21 12:10:25 -06:00
|
|
|
#include <vector>
|
2017-01-07 16:10:39 -07:00
|
|
|
|
2015-09-26 14:39:47 -06:00
|
|
|
#include "Common/Assert.h"
|
2017-01-07 16:10:39 -07:00
|
|
|
#include "Common/CommonTypes.h"
|
2014-04-09 00:22:52 -06:00
|
|
|
#include "Common/MemoryUtil.h"
|
|
|
|
|
2018-05-17 13:56:15 -06:00
|
|
|
namespace Common
|
|
|
|
{
|
2014-04-09 00:22:52 -06:00
|
|
|
// Everything that needs to generate code should inherit from this.
|
|
|
|
// You get memory management for free, plus, you can use all emitter functions without
|
|
|
|
// having to prefix them with gen-> or something similar.
|
|
|
|
// Example implementation:
|
|
|
|
// class JIT : public CodeBlock<ARMXEmitter> {}
|
|
|
|
template <class T>
|
Remove NonCopyable
The class NonCopyable is, like the name says, supposed to disallow
copying. But should it allow moving?
For a long time, NonCopyable used to not allow moving. (It declared
a deleted copy constructor and assigment operator without declaring
a move constructor and assignment operator, making the compiler
implicitly delete the move constructor and assignment operator.)
That's fine if the classes that inherit from NonCopyable don't need
to be movable or if writing the move constructor and assignment
operator by hand is fine, but that's not the case for all classes,
as I discovered when I was working on the DirectoryBlob PR.
Because of that, I decided to make NonCopyable movable in c7602cc,
allowing me to use NonCopyable in DirectoryBlob.h. That was however
an unfortunate decision, because some of the classes that inherit
from NonCopyable have incorrect behavior when moved by default-
generated move constructors and assignment operators, and do not
explicitly delete the move constructors and assignment operators,
relying on NonCopyable being non-movable.
So what can we do about this? There are four solutions that I can
think of:
1. Make NonCopyable non-movable and tell DirectoryBlob to suck it.
2. Keep allowing moving NonCopyable, and expect that classes that
don't support moving will delete the move constructor and
assignment operator manually. Not only is this inconsistent
(having classes disallow copying one way and disallow moving
another way), but deleting the move constructor and assignment
operator manually is too easy to forget compared to how tricky
the resulting problems are.
3. Have one "MovableNonCopyable" and one "NonMovableNonCopyable".
It works, but it feels rather silly...
4. Don't have a NonCopyable class at all. Considering that deleting
the copy constructor and assignment operator only takes two lines
of code, I don't see much of a reason to keep NonCopyable. I
suppose that there was more of a point in having NonCopyable back
in the pre-C++11 days, when it wasn't possible to use "= delete".
I decided to go with the fourth one (like the commit title says).
The implementation of the commit is fairly straight-forward, though
I would like to point out that I skipped adding "= delete" lines
for classes whose only reason for being uncopyable is that they
contain uncopyable classes like File::IOFile and std::unique_ptr,
because the compiler makes such classes uncopyable automatically.
2017-08-04 15:57:12 -06:00
|
|
|
class CodeBlock : public T
|
2014-04-09 00:22:52 -06:00
|
|
|
{
|
|
|
|
private:
|
|
|
|
// A privately used function to set the executable RAM space to something invalid.
|
|
|
|
// For debugging usefulness it should be used to set the RAM to a host specific breakpoint
|
|
|
|
// instruction
|
|
|
|
virtual void PoisonMemory() = 0;
|
|
|
|
|
|
|
|
protected:
|
2016-08-06 11:09:21 -06:00
|
|
|
u8* region = nullptr;
|
2017-03-21 12:10:25 -06:00
|
|
|
// Size of region we can use.
|
2016-08-06 11:09:21 -06:00
|
|
|
size_t region_size = 0;
|
2017-03-21 12:10:25 -06:00
|
|
|
// Original size of the region we allocated.
|
|
|
|
size_t total_region_size = 0;
|
2015-08-07 21:08:57 -06:00
|
|
|
|
2016-08-06 11:09:21 -06:00
|
|
|
bool m_is_child = false;
|
2017-03-21 12:10:25 -06:00
|
|
|
std::vector<CodeBlock*> m_children;
|
2014-04-09 00:22:52 -06:00
|
|
|
|
|
|
|
public:
|
Remove NonCopyable
The class NonCopyable is, like the name says, supposed to disallow
copying. But should it allow moving?
For a long time, NonCopyable used to not allow moving. (It declared
a deleted copy constructor and assigment operator without declaring
a move constructor and assignment operator, making the compiler
implicitly delete the move constructor and assignment operator.)
That's fine if the classes that inherit from NonCopyable don't need
to be movable or if writing the move constructor and assignment
operator by hand is fine, but that's not the case for all classes,
as I discovered when I was working on the DirectoryBlob PR.
Because of that, I decided to make NonCopyable movable in c7602cc,
allowing me to use NonCopyable in DirectoryBlob.h. That was however
an unfortunate decision, because some of the classes that inherit
from NonCopyable have incorrect behavior when moved by default-
generated move constructors and assignment operators, and do not
explicitly delete the move constructors and assignment operators,
relying on NonCopyable being non-movable.
So what can we do about this? There are four solutions that I can
think of:
1. Make NonCopyable non-movable and tell DirectoryBlob to suck it.
2. Keep allowing moving NonCopyable, and expect that classes that
don't support moving will delete the move constructor and
assignment operator manually. Not only is this inconsistent
(having classes disallow copying one way and disallow moving
another way), but deleting the move constructor and assignment
operator manually is too easy to forget compared to how tricky
the resulting problems are.
3. Have one "MovableNonCopyable" and one "NonMovableNonCopyable".
It works, but it feels rather silly...
4. Don't have a NonCopyable class at all. Considering that deleting
the copy constructor and assignment operator only takes two lines
of code, I don't see much of a reason to keep NonCopyable. I
suppose that there was more of a point in having NonCopyable back
in the pre-C++11 days, when it wasn't possible to use "= delete".
I decided to go with the fourth one (like the commit title says).
The implementation of the commit is fairly straight-forward, though
I would like to point out that I skipped adding "= delete" lines
for classes whose only reason for being uncopyable is that they
contain uncopyable classes like File::IOFile and std::unique_ptr,
because the compiler makes such classes uncopyable automatically.
2017-08-04 15:57:12 -06:00
|
|
|
CodeBlock() = default;
|
2014-04-09 00:22:52 -06:00
|
|
|
virtual ~CodeBlock()
|
|
|
|
{
|
|
|
|
if (region)
|
|
|
|
FreeCodeSpace();
|
|
|
|
}
|
Remove NonCopyable
The class NonCopyable is, like the name says, supposed to disallow
copying. But should it allow moving?
For a long time, NonCopyable used to not allow moving. (It declared
a deleted copy constructor and assigment operator without declaring
a move constructor and assignment operator, making the compiler
implicitly delete the move constructor and assignment operator.)
That's fine if the classes that inherit from NonCopyable don't need
to be movable or if writing the move constructor and assignment
operator by hand is fine, but that's not the case for all classes,
as I discovered when I was working on the DirectoryBlob PR.
Because of that, I decided to make NonCopyable movable in c7602cc,
allowing me to use NonCopyable in DirectoryBlob.h. That was however
an unfortunate decision, because some of the classes that inherit
from NonCopyable have incorrect behavior when moved by default-
generated move constructors and assignment operators, and do not
explicitly delete the move constructors and assignment operators,
relying on NonCopyable being non-movable.
So what can we do about this? There are four solutions that I can
think of:
1. Make NonCopyable non-movable and tell DirectoryBlob to suck it.
2. Keep allowing moving NonCopyable, and expect that classes that
don't support moving will delete the move constructor and
assignment operator manually. Not only is this inconsistent
(having classes disallow copying one way and disallow moving
another way), but deleting the move constructor and assignment
operator manually is too easy to forget compared to how tricky
the resulting problems are.
3. Have one "MovableNonCopyable" and one "NonMovableNonCopyable".
It works, but it feels rather silly...
4. Don't have a NonCopyable class at all. Considering that deleting
the copy constructor and assignment operator only takes two lines
of code, I don't see much of a reason to keep NonCopyable. I
suppose that there was more of a point in having NonCopyable back
in the pre-C++11 days, when it wasn't possible to use "= delete".
I decided to go with the fourth one (like the commit title says).
The implementation of the commit is fairly straight-forward, though
I would like to point out that I skipped adding "= delete" lines
for classes whose only reason for being uncopyable is that they
contain uncopyable classes like File::IOFile and std::unique_ptr,
because the compiler makes such classes uncopyable automatically.
2017-08-04 15:57:12 -06:00
|
|
|
CodeBlock(const CodeBlock&) = delete;
|
|
|
|
CodeBlock& operator=(const CodeBlock&) = delete;
|
|
|
|
CodeBlock(CodeBlock&&) = delete;
|
|
|
|
CodeBlock& operator=(CodeBlock&&) = delete;
|
2014-04-09 00:22:52 -06:00
|
|
|
|
|
|
|
// Call this before you generate any code.
|
2017-04-14 04:53:32 -06:00
|
|
|
void AllocCodeSpace(size_t size)
|
2014-04-09 00:22:52 -06:00
|
|
|
{
|
|
|
|
region_size = size;
|
2017-03-21 12:10:25 -06:00
|
|
|
total_region_size = size;
|
2017-04-14 04:53:32 -06:00
|
|
|
region = static_cast<u8*>(Common::AllocateExecutableMemory(total_region_size));
|
2020-05-01 16:42:29 -06:00
|
|
|
T::SetCodePtr(region, region + size);
|
2014-04-09 00:22:52 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
// Always clear code space with breakpoints, so that if someone accidentally executes
|
|
|
|
// uninitialized, it just breaks into the debugger.
|
2017-03-21 12:37:48 -06:00
|
|
|
void ClearCodeSpace()
|
2014-04-09 00:22:52 -06:00
|
|
|
{
|
|
|
|
PoisonMemory();
|
|
|
|
ResetCodePtr();
|
|
|
|
}
|
|
|
|
|
|
|
|
// Call this when shutting down. Don't rely on the destructor, even though it'll do the job.
|
|
|
|
void FreeCodeSpace()
|
|
|
|
{
|
2018-03-14 18:34:35 -06:00
|
|
|
ASSERT(!m_is_child);
|
2017-03-21 12:10:25 -06:00
|
|
|
Common::FreeMemoryPages(region, total_region_size);
|
2014-04-09 00:22:52 -06:00
|
|
|
region = nullptr;
|
|
|
|
region_size = 0;
|
2017-03-21 12:10:25 -06:00
|
|
|
total_region_size = 0;
|
|
|
|
for (CodeBlock* child : m_children)
|
2015-08-07 21:08:57 -06:00
|
|
|
{
|
2017-03-21 12:10:25 -06:00
|
|
|
child->region = nullptr;
|
|
|
|
child->region_size = 0;
|
|
|
|
child->total_region_size = 0;
|
2015-08-07 21:08:57 -06:00
|
|
|
}
|
2014-04-09 00:22:52 -06:00
|
|
|
}
|
|
|
|
|
2017-01-08 16:05:28 -07:00
|
|
|
bool IsInSpace(const u8* ptr) const { return ptr >= region && ptr < (region + region_size); }
|
2024-03-24 04:49:47 -06:00
|
|
|
bool IsInSpaceOrChildSpace(const u8* ptr) const
|
|
|
|
{
|
|
|
|
return ptr >= region && ptr < (region + total_region_size);
|
|
|
|
}
|
2023-09-30 09:32:51 -06:00
|
|
|
void WriteProtect(bool allow_execute)
|
|
|
|
{
|
|
|
|
Common::WriteProtectMemory(region, region_size, allow_execute);
|
|
|
|
}
|
|
|
|
void UnWriteProtect(bool allow_execute)
|
|
|
|
{
|
|
|
|
Common::UnWriteProtectMemory(region, region_size, allow_execute);
|
|
|
|
}
|
2020-05-01 16:42:29 -06:00
|
|
|
void ResetCodePtr() { T::SetCodePtr(region, region + region_size); }
|
2014-04-09 00:22:52 -06:00
|
|
|
size_t GetSpaceLeft() const
|
2016-06-24 02:43:46 -06:00
|
|
|
{
|
2018-03-14 18:34:35 -06:00
|
|
|
ASSERT(static_cast<size_t>(T::GetCodePtr() - region) < region_size);
|
2017-03-21 12:10:25 -06:00
|
|
|
return region_size - (T::GetCodePtr() - region);
|
2014-04-09 00:22:52 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
bool IsAlmostFull() const
|
2016-06-24 02:43:46 -06:00
|
|
|
{
|
2014-04-09 00:22:52 -06:00
|
|
|
// This should be bigger than the biggest block ever.
|
|
|
|
return GetSpaceLeft() < 0x10000;
|
2016-06-24 02:43:46 -06:00
|
|
|
}
|
2017-03-21 12:10:25 -06:00
|
|
|
|
|
|
|
bool HasChildren() const { return region_size != total_region_size; }
|
|
|
|
u8* AllocChildCodeSpace(size_t child_size)
|
|
|
|
{
|
2024-03-24 04:49:47 -06:00
|
|
|
ASSERT_MSG(DYNA_REC, child_size <= GetSpaceLeft(), "Insufficient space for child allocation.");
|
2017-03-21 12:10:25 -06:00
|
|
|
u8* child_region = region + region_size - child_size;
|
|
|
|
region_size -= child_size;
|
Common/CodeBlock: Call ResetCodePtr when decreasing region_size
Fixes https://bugs.dolphin-emu.org/issues/12827.
A description of what was going wrong:
JitArm64::Init first calls CodeBlock::AllocCodeSpace, after which
CodeBlock and Arm64Emitter consider us to have 96 MB of code space
available. JitArm64::Init then calls AddChildCodeSpace, which is
supposed to take 64 MiB of that space and give it to m_far_code.
CodeBlock's view of how much space there is gets updated from 96 MiB
to 32 MiB, but due to the missing call, Arm64Emitter keeps thinking
that it has 96 MiB of space available.
The last thing JitArm64::Init does is to call ResetFreeMemoryRanges.
This function asks Arm64Emitter how much code space is available and
stores a range of that size in m_free_ranges_near, meaning that
m_free_ranges_near ends up being backed by both nearcode and farcode!
This is a ticking time bomb; as soon as we grab memory from
m_free_ranges_near which is backed by farcode, we're in trouble.
The crash I ran into in my testing was caused by fastmem code being
allocated in farcode (our backpatch handler only handles accesses made
from nearcode), but you may as well get errors caused by code intended
for nearcode overwriting code intended for farcode or vice versa.
So why did NBA Live 2005 crash when most games had no problems,
and why was the bug bisected to the commit that increased the size
of far code from 16 MiB to 64 MiB? Well, as long as we're only
using the first 32 MiB of the big 96 MiB range, everything works.
What happens with NBA Live 2005 (I have not investigated exactly
through what mechanism this happens) is that at some point the range
in m_free_ranges_near gets split into two ranges, one which is
backed by nearcode and one which is backed by farcode. Dolphin
prefers to select the biggest range available (we don't want to
pick a tiny 1 KiB range that may not be able to fit the whole block
we're about to emit, after all), and after increasing the size of
farcode to 64 MiB, farcode is bigger than nearcode.
2022-02-12 09:51:32 -07:00
|
|
|
ResetCodePtr();
|
2017-03-21 12:10:25 -06:00
|
|
|
return child_region;
|
|
|
|
}
|
|
|
|
void AddChildCodeSpace(CodeBlock* child, size_t child_size)
|
2015-07-15 00:53:05 -06:00
|
|
|
{
|
2017-03-21 12:10:25 -06:00
|
|
|
u8* child_region = AllocChildCodeSpace(child_size);
|
|
|
|
child->m_is_child = true;
|
|
|
|
child->region = child_region;
|
|
|
|
child->region_size = child_size;
|
|
|
|
child->total_region_size = child_size;
|
|
|
|
child->ResetCodePtr();
|
|
|
|
m_children.emplace_back(child);
|
2015-08-07 21:08:57 -06:00
|
|
|
}
|
2014-04-09 00:22:52 -06:00
|
|
|
};
|
2018-05-17 13:56:15 -06:00
|
|
|
} // namespace Common
|