1.system.getproperty('java.class.path')是源码在什么时候被设
2.lldb 小记和std::string的数据结构图源码阅读
3.编译技术入门与实践之LLVM概述及环境构建

system.getproperty('java.class.path')是在什么时候被设

       系统属性java.class.path的设置确实隐藏且复杂，我通过lldb调试工具找到其被加入SystemProperty的源码源头。我使用的源码是OpenJDK 9源代码进行调试，具体定位在了以下地址：github.com/dmlloyd/open...

       在该源代码中，源码java.class.path属性值被成功加入到系统属性链表。源码详情请参考上述链接，源码krpano源码深入理解其设置过程。源码

lldb 小记和std::string的源码数据结构图源码阅读

       在深入理解LLVM和GCC的std::string实现差异时，我们首先从lldb着手，源码探索其内部工作机制。源码昨天尝试编译llvm后，源码今天我们就来研究std::string在lldb中的源码表现，它与g++的源码std::string实现有何不同。

       从一个简单的源码测试程序开始，我们对比了用g++和clang++编译的源码代码。在g++版本中，字符串s使用了短字符串优化(SSO)的存储方式，"hi"存储在_M_local_buf中。SSO旨在节省内存，.svn源码泄漏通过为短字符串预留固定大小的结构，如长度、容量和指向字符串数组的指针，共字节。

       对于长字符串，例如scow，存储方式不同。尽管_M_local_buf中没有"this is a sunny day"，但通过M p找到的dreamware改源码实际字符串地址显示出长字符串的存储策略。这表明在长字符串时，std::string会采用常规的存储方式，即一个指针指向字符串数组。

       接下来，我们需要弄清楚如何判断何时使用SSO。在代码中，我们猜测可能通过某些标志位来区分，但实际观察到的operator[]函数表明，M p始终指向字符串数组，脚本和源码不论字符串长度。这就意味着，无论短长，读取指定位置的字符都遵循相同的逻辑。

       在libstdc++(g++)和libc++(llvm)的实现上，我们发现两者在数据结构上存在差异。例如，libstdc++的std::string使用字节的union，而libc++则为字节。ossim源码结构区分长短字符串的方式在libc++中通过检查容量字段的比特位实现，这依赖于机器的字节序。

       附录中，我分享了自己编译LLVM的体验和使用clang++编译程序的CMakeLists.txt设置，供有兴趣的读者参考。

编译技术入门与实践之LLVM概述及环境构建

       本系列旨在记录学习过程和知识总结，便于后续交流。我专注于智能芯片研究，编译器设计是实践中的常见挑战，最近实验中涉及LLVM pass，处理源代码到数据流的转换。

       LLVM是一个集成了模块化技术的编译器项目，非传统虚拟机概念，全称为LLVM项目。最初由伊利诺大学发起，目标是创建基于SSA策略的现代化编译策略，支持多种语言的静态和动态编译。它包含众多子项目，如LLVM core、Clang、LLDB等，广泛应用于学术和商业领域，以其通用性、灵活性和可重用性为特点。

       LLVM的核心子项目包括：LLVM core提供源码和目标代码隔离的优化器，支持多种CPU；Clang是C/C++编译器，包含自动code检查工具；LLDB是高效调试器，基于LLVM核心和Clang；libc++与libc++ ABI提供C++标准库；compiler-rt提供底层代码生成优化；MLIR构建可扩展的编译器架构；OpenMP支持OpenMP在Clang中的使用；Polly进行本地化优化和并行化；libclc开发OpenCL标准库；klee则提供符号化虚拟机以检测bug。

       实验准备部分，LLVM项目包含一系列工具和库，如汇编器、反汇编器等，用于处理LLVM中间表示和目标文件的转换。获取源代码时，需要明确硬件平台和软件环境。在Ubuntu系统中，可能需要升级cmake、安装openssl等。构建LLVM和Clang时，遵循官网指南，配置后执行make或ninja命令进行编译，并可能需要解决一些编译错误。