[Dev] Xcode的记载 (dev下面的错误提示框不见了)

本文目录导航：

• [Dev] Xcode的记载
• GCC预解决器探求：应用-E选项和CMake优化代码构建
• 计算机如何将若干代码转化成01？

[Dev] Xcode的记载

构建环节可以分为预解决(preprocess) -- 编译(build) -- 汇编(assemble) -- 衔接(link)这几个大的环节。

LLVM(Low Level Virtual Machine)是弱小的编译器开发工具套件，其外围现实是经过生成两边代码IR，分别前后端（前端编译器，后端指标机器码）。

这样做的好处是，前端新增编译器，不用再独自去适配指标机器码，只有要生成两边代码，LLVM就可以生成对应的指标机器码。

上方就是LLVM的架构。

预解决：头文件引入、宏交流、注释解决、条件编译等操作；词法剖析：读入源文件字符流，组成无心义的词素（lexeme）序列，生成词法单元（token）输入；语法剖析：Token流解析成一颗形象语法树(AST)；CodeGen：遍历语法树，生成LLVM IR代码，这是前端的输入文件；汇编：LLVM对IR启动优化，针对不同架构生成不同指标代码，以汇编代码格局输入；汇编器生成.o文件：将汇编代码转换为机器代码，输入指标文件（object file）；衔接器：将指标文件和(、.a、、)启动衔接，生成可口头mach-o文件。

dwarf：debugging with attribute record formats，一种源码调试消息的记载格局，用于源码级调试；dSym：debug Symboles，调试符号，即符号表文件。

符号对应着类、函数、变量等，是内存与符号如函数名、文件名、行号等的映射，解体日志解析十分关键。

可以用dwarfdump 命令来检查dwarf调试消息。

DW_AT_low_pc示意函数的起始地址 DW_AT_high_pc示意函数的完结地址 DW_AT_frame_base示意函数的栈帧基址 DW_AT_object_pointer示意对象指针地址 DW_AT_name示意函数的名字 DW_AT_decl_file示意函数所在的文件 DW_AT_decl_line示意函数所在的文件中的行数 DW_AT_prototyped为一个 Bool 值, 为 true 时代表这是一个子程序/函数(subroutine) DW_AT_type示意函数的前往值类型 DW_AT_artificial为一个Bool值，为true时代表这是一个由编译器生成而不是源程序显式申明经常使用symbolicatecrash命令行经常使用dwarfdump和atos工具xcode-project-file-format这里对xcodeproj文件格局启动了说明。

xcodeproj文件蕴含以下元素总体说明联合上方的说明，对文件结构启动说明名目中setting有2处，project和target中都有，那么他们之间的相关是怎么的？在Xcode中增加代码块步骤1、选用代码，右键选用 create code snippet，或许在顶部导航，选用Editor-create code snippet；2、编辑消息和代码即可，其中completion示意输入的快捷方式；3、须要修正的参数用方式增加 ；4、所在目录~/Library/Developer/Xcode/UserData/CodeSnippets 。

还须要留意xcshareddata目录下参考Xcode build环节中都做了什么 Xcode编译疾如风-3.浅谈 dwarf 和 dSYM iOS解体日志解析&原理 - 掘金 LLVM编译流程 & Clang插件开发 8. Xcode 工程文件解析 - 掘金 XCode工程文件结构及Xcodeproj框架的经常使用( 二 ) XCode: Target Settings和Project Settings的区别 Xcode-名目重命名

GCC预解决器探求：应用-E选项和CMake优化代码构建

在编写C言语代码时，预解决器表演着至关关键的角色。

预解决阶段出当初实践编译环节之前，关键职责包括宏定义的倒退、文件蕴含解决、条件编译等。

预解决器的上班是对源代码文件启动初步的文本解决，它不触及语法剖析或代码生成，其输入是纯正的文本方式，供编译器后续阶段经常使用。

宏定义与倒退是预解决器的一项基本色能。

宏是预解决器指令，用于在代码编译前定义一些交流规定。

宏可以便捷地定义为文本交流项，例如，经过#define创立的宏，在预解决阶段会将一切宏名交流为宏定义的内容。

这种机制可以用于定义常量、编写便捷的函数（宏函数）等。

例如，MAX宏被定义为一个接受两个参数的宏，它将被倒退为一个条件表白式，用于计算两个值中的最大值。

GCC（GNU Compiler Collection）提供了一特性能弱小的预解决器。

在GCC中，预解决可以独自经过命令gcc -E来调用。

这个命令让GCC口头预解决，但不继续启动编译、汇编或链接。

这关于调试预解决器相关的疑问十分有用，例如审核宏定义能否正确倒退，或许条件编译的代码块能否如预期那样被蕴含或扫除。

经常使用GCC倒退宏的示例：思考以下便捷的C代码。

经常使用GCC的预解决命令gcc -E对该文件口头预解决，将生成蕴含一切宏倒退后的输入，其中包括HELLO宏被交流成Hello, world!的结果，同时也会倒退一切的蕴含命令（如#include）。

了解预解决器的上班原理，开发者可以更有效地经常使用它来优化和调试代码。

下一章将讨论如何在CMake中性能和经常使用预解决命令，以及这对名目构建环节的影响。

CMake是一个弱小的构建系统生成工具，它可以生成规范的构建文件（如Unix的Makefiles或Windows的名目文件），使得程序员可以在不同的平台上经常使用相反的构建性能。

在CMake中，咱们不只可以定义编译构建的规定，还可以性能预解决命令，以生成预解决后的源文件，这关于调试和剖析源代码十分有用。

在CMake中，add_custom_command和add_custom_target是两个用于增加自定义构建命令和指标的命令。

这些性能准许开发者在构建环节中拔出非规范的构建步骤，例如生成预解决文件。

经过正当性能CMake，可以使这一环节智能化，提高开发效率并缩小因构建性能失误惹起的疑问。

在实践名目中，经过预解决源文件，开发者可以审核条件编译的决策、宏倒退的结果以及蕴含的头文件。

这关于了解复杂的宏逻辑、验证构建性能和启动代码审查十分有用。

预解决阶段只管关键解决文本交流和条件编译，但其在现代软件开发中的运行远不止于此。

经过初级预解决技术，开发者可以成功更复杂的代码生成、条件编译优化，以及更有效的代码治理。

联合CMake优化构建环节，可以进一步优化和精简构建环节，优化开发效率和产质量量。

总结来说，了解并正当应用预解决器的才干，可以极大地增强名目的灵敏性和可保养性。

经过这种方式，可以确保每个指标都有适当的构建环境，而不用依赖全局的预解决输入，这样可以更好地控制名目的各个局部。

计算机如何将若干代码转化成01？

当你将源代码编写好之后——>预解决器解决一切的预解决指令——>编译器会自己做源代码级别的优化——>编译成指标代码——>指标代码优化——>汇编器把指标代码转换成机器指令生成指标文件——>链接器将不同的指标文件链接成可口头文件；可口头文件就是01啦，外面除了你的代码数据外，还有在整个环节中增加的一些其余物品。