为什么UPX break会编译SBCL应用程序？

Question

这主要是一个愚蠢的问题，因为UPX (一种从你的可执行文件中提取额外字节的工具)比buildapp工具中的内置压缩节省了很少的空间。

一个非常小的演示应用程序创建了一个42MB的文件。这是可以理解的，因为SBCL环境并不小。

将--compress-core选项传递给buildapp会将其缩减到9.2MB。

我想我应该尝试在生成的二进制文件中抛出UPX，节省的空间只相当于多几个字节：9994288 -> 9871360

然而，结果文件不再运行-它只是跳到SBCL REPL中(没有错误，就像我刚刚手动运行sbcl一样)，在那里查看一下就会发现组成我的测试程序的函数不再存在。

UPX对导致这种破坏的二进制文件做了什么？

Answer 1

这可能不是答案，但它可以作为线索:我发现，如果在使用sb-ext:save-lisp-and-die创建的SBCL可执行文件的末尾添加任何内容，即使是一个字节，所有的定义都会消失，就像您所描述的那样。

也许SBCL通过将核心(包含您的定义)附加到SBCL ELF (或Windows上的PE )二进制文件的副本中，并在末尾添加一些元数据来创建可执行文件，以便SBCL仍然可以找到核心的开头，即使它被附加到可执行文件中。

如果您对使用save-lisp-and-die创建的可执行文件进行十六进制编辑，您会发现它以字符串"LCBS“(SBCL向后)结尾，这似乎支持我的理论。"LCBS“可能是一个神奇的数字，让SBCL知道，是的，这个可执行文件包含它自己的核心。

UPX会压缩可执行文件，可能会在最后包含这个神奇的数字。当SBCL在磁盘上打开UPX压缩的self时，它不会在最后找到"LCBS“，因此它假设没有附加到可执行文件的内核。

如果是这样的话，我无法解释为什么标准库似乎还在那里。在这种情况下，SBCL可能会加载/usr/lib/sbcl/sbcl.core (或其在Windows上的等价物)。这可以通过将可执行文件移到没有安装SBCL的机器上并查看它是否正常工作来测试，如果可以，那么您是否仍然拥有car、cdr、list等。