这个问题在这里可能是离题的边缘，但出于学术目的，我仍然敢在这里问它。如果它是题外话，请给我发送电子邮件以basile@starynkevitch.net提及此问题的 URL，即使它已关闭
上下文：物联网固件的静态源代码全程序分析
作为Bismon的演示示例（一个仍未发布的 GPLv3+ 框架和研究项目，由CHARIOT资助，通过GCC插件进行静态源代码分析，其文档草稿在这里并不断改进）我正在寻找一个完整的系统物联网源代码，如下所示特征：
想要的小固件源代码是......
- 完全开源许可。实际的许可证并不重要（我只会多次编译代码；我没有硬件）
- 可以理解的静态源代码分析专家（那些开发邮资-C或已开发的GCC MELT和Unisim的模拟器，或合作伙伴Vessedia）谁是不是物联网的专家。所以请看英文（或法文）代码和评论！（仅以中文或保加利亚语为例，没有评论）
- 可以在 Debian/Linux/x86-64 上使用 GCC 9（或者可能是GCC 8）交叉编译，最好使用已经打包在 Debian 中的交叉编译器。然而，在为 GCC 做出贡献后，我能够从它的源代码编译它。
- 完整的源代码可以在单个存储库中轻松且完全可用
git，主要是 C 或 C++（以及一些汇编行） - 最好有一些可用于 Linux 的模拟器或模拟器。
- 主要是C或C++代码，尽可能少的汇编代码（例如300行汇编代码好，但30KLOC不好）。
- 固件二进制文件应为ELF格式
- 大约四千到二十万行源代码（4KLOC - 200KLOC），以sloccount 衡量。限制并不严格，但在功能强大的 Debian 笔记本电脑上，交叉构建时间应少于 10 或 20 秒。
- 提供无线设备固件更新
- 几乎单任务处理一些事件循环。我们可以处理一些固定数量的任务（例如中断驱动），但不能处理具有数十或数百个任务的通用调度程序和动态多任务处理。如果可能，只有一个运行时物联网调用堆栈（是的，我们知道内核调度程序、绿色线程、延续等......，我们希望尽可能避免它们；中断处理程序是可以接受的，但我们会忽略）或至少非常他们中的几个。直觉上，我们期望整个 IoT 设备软件使用一个“主要”主调用堆栈，以及一些较小的调用堆栈（例如用于中断）。
- 很少有间接函数指针调用，即进行间接函数调用的GIMPLE指令的静态代码出现次数少于 20 到 60 次。我过度估计了整个程序调用堆栈的大小，间接函数调用处理起来很痛苦（但会以某种特别的方式“手动”处理，也许 在它们之前）。
#pragma
我确实有一个 hello world 内核源代码（太小）和一个 GCC 插件来提取其中的调用帧大小，但我想要更大的东西并进行通信以进行静态分析。
我的 Linux 桌面运行一些 Debian/x86-64 系统，我有它的 root 访问权限，我正在构建然后运行Bismon（这是我正在开发的 GPLv3+ 软件）。有时，我还会在其上构建（来自 GNU 源代码树存储库）一个交叉binutils和一个交叉 GCC。
顺便说一句，我不想或不需要在我的 Linux 桌面上移植或运行 IoT 设备代码（即分析的固件源代码）。我可能想模拟它，只是为了更好地理解它（所以模拟并不是真正必需的，但可能对像我这样的人有用）。显然，我的 Linux 桌面上的所有 IoT 设备源代码都应该是可交叉编译和可交叉链接的。但是静态分析框架（在 GCC交叉编译技术之上）运行在强大的 Linux/x86-64/Debian 桌面上。
TRL问题和工作环境
这是在H2020 “研究与创新行动”项目的背景下，TRL 较低（因此 2020 年最多 TRL 3，2019年 TRL 2）。我可以也愿意花一些时间（例如手动注释每个间接函数调用站点，或者抽象掉大多数线程或延续），我只是想避免花费太多时间来制作演示和理解物联网代码。这只是一个一次性演示（在布鲁塞尔的官方研究项目审查中，欧盟委员会，恰好 100% 资助该项目），我知道演示效果。
NB：FWIW，我们都是拥有博士学位和十年以上工作经验的静态分析专家。我巴塞尔几年后就要退休了。
顺便说一句，coreboot对我们来说太大了。https://mongoose-os.com/ 可能不错。https://github.com/intel-iot-devkit/how-to-code-samples看起来不错，但代码有点太小了。