是否可以在 C++ 编译时计算函数长度？

Question

我有这段代码：

constexpr static VOID fStart()
{
    auto a = 3;
    a++;
}

__declspec(naked) 
constexpr static VOID fEnd() {};

static constexpr auto getFSize()
{
    return (SIZE_T)((PBYTE)fEnd - (PBYTE)fStart);
}

static constexpr auto fSize = getFSize();
static BYTE func[fSize];

是否可以在不使用任何标准库的情况下在编译期间将“func[fSize]”数组大小声明为“fStart()”的大小？以后需要将 fStart() 的完整代码复制到这个数组中。

Answer 1

标准 C++ 中没有获取函数长度的方法。

您需要使用特定于编译器的方法。

一种方法是让链接器创建一个段，并将您的函数放在该段中。然后使用段的长度。

您也许可以使用一些汇编语言结构来做到这一点；取决于汇编程序和汇编代码。

注意：在嵌入式系统中，移动功能代码是有原因的，例如到片上存储器或交换到外部存储器，或者对代码执行校验和。

Answer 2

下面计算fStart函数的“字节大小”。但是，通过这种方式无法将大小作为constexpr 获得，因为强制转换失去了编译时常量（参见例如Why is reinterpret_cast not constexpr?），并且如果没有某种强制转换，就无法评估两个不相关函数指针的差异.

#pragma runtime_checks("", off)
__declspec(code_seg("myFunc$a")) static void fStart()
{   auto a = 3; a++; }
__declspec(code_seg("myFunc$z")) static void fEnd(void)
{   }
#pragma runtime_checks("", restore)

constexpr auto pfnStart = fStart;                               // ok
constexpr auto pfnEnd = fEnd;                                   // ok
// constexpr auto nStart = (INT_PTR)pfnStart;                   // error C2131

const auto fnSize = (INT_PTR)pfnEnd - (INT_PTR)pfnStart;        // ok
// constexpr auto fnSize = (INT_PTR)pfnEnd - (INT_PTR)pfnStart; // error C2131

Answer 3

在某些处理器和一些已知的编译器和 ABI 约定上，您可以做相反的事情：

在运行时生成机器码。

对于 Linux 上的 x86/64，我知道 GNU lightning、asmjit、libgccjit 这样做。

elf(5) 格式知道函数的大小。

在 Linux 上，您可以生成 shared libraries（可能在运行时生成 C 或 C++ 代码（如 RefPerSys 和 GCC MELT 那样），然后使用 gcc -fPIC -shared -O 编译它）和稍后的 dlopen(3) / @987654329 @ 它。 dladdr(3) 非常很有用。您将使用函数指针。

还可以阅读关于linkers and loaders 的书。

但是你通常不能移动机器代码而不做一些relocation，除非机器代码是position-independent code（通常PIC比普通代码运行慢）。

一个相关的主题是代码的garbage collection（甚至是agents）。您需要阅读garbage collection handbook 并从SBCL 等实现中获得灵感。

还请记住，一个好的优化 C++ 编译器允许展开循环、内联扩展函数调用、删除死代码、进行函数克隆等......所以机器代码函数甚至可能不连续：两个 C 函数foo() 和bar() 可以共享几十个常用机器指令。

阅读Dragon book，并研究GCC 的源代码（并考虑使用您的GCC plugin 对其进行扩展）。还要查看gcc -O2 -Wall -fverbose-asm -S 生成的汇编代码。 GCC 的一些实验变体可能能够生成在您的 GPGPU 上运行的 OpenCL 代码（然后，函数结束的概念本身就没有意义）

使用通过 C 和 C++ 生成的插件，如果您使用 Ian Taylor 的 libbacktrace 和 dladdr 来探索您的调用堆栈，您可以使用 dlclose(3) 小心地删除它们。在 99% 的情况下，这是不值得的麻烦，因为实际上一个 Linux 进程（在 2021 年当前的 x86-64 笔记本电脑上）可能可以处理一百万个 dlopen(3)，正如我的 manydl.c 程序所展示的（它生成“随机”C 代码，将其编译成唯一的/tmp/generated123.so 和dlopen，并重复多次）。

覆盖机器代码的唯一原因（在台式机和服务器计算机上）是持久的服务器进程每秒生成机器代码。如果这是你的场景，你应该提到它（使用 Java 类加载器生成 JVM 字节码可能更有意义）。

当然，在 16 位微控制器上，情况非常不同。

是否可以在 C++ 编译时计算函数长度？

不，因为在运行时某些函数不再存在。

编译器以某种方式删除了它们。或者克隆它们。或者内联它们。

对于 C++，standard containers 实际上很重要：会发生大量模板扩展，包括在某些时候必须由优化编译器删除的无用代码。

（想想在 2021 年使用最近的 GCC 10.2 或 11 进行编译。在任何地方使用并链接到 gcc -O3 -flto -fwhole-program：函数 foo23 可能已定义但从未调用过，然后它不在ELF 可执行文件）