编译Objc可调试代码遇到的一些问题总结
如何开始一份新的objc代码编译通过呢
- 去GitHub寻找最新别人通过的（利用轮子）
- 下载objc源码 接着还需要下载关于系统有关的源码。
dyld Libc-1439 libclosure-79 libdispatch-1271 libplatform-254 libpthread-454 xnu-7195
版本可为 最新版本 结合自己的操作系统 编译过程 缺失的头文件 在这些文件中搜索出来
实在找不到的就是 一些私有 未公布的文件 估计问题不大 直接注释
为什么项目识别到我们的objc项目 并且支持断点调试
创建一个空的workspace 在同一个workspace下
目录结构为
▼ XXX.workspace
▼ objc
▼ macDemoBaseObjc
▼ xxxDemo
同时在把objc中生成的product拉进macDemoBaseObjc项目文件中即可
Xcode会自动寻找到他的隐含依赖（依据名字寻找 就会在build过程中也会build objc相关的target ）
- 理论基础：
** 一个Target和它的product可以和其他Target联系，如果一个target build需要另一个target的“输出”，可以说成第一个target依赖第二个。如果这俩个target在同一个workspace，Xcode会发现他们的依赖关系，从而build the products按照特定的顺序。这样的关系被称为“ implicit dependency.” 你也可以为俩个targets指定明确的target 依赖关系在build setting里面。例如，你可能build一个library和一个链接这个library的application（同一个workspace）。Xcode可以发现这种关系并且自动build这个library first。然而，你如果要去链接library的某个版本而不是one built in the workspace，你可以在build settings里创建一个确定的依赖关系，它将会覆盖implicit dependency。
** 引用：https://developer.apple.com/library/archive/featuredarticles/XcodeConcepts/Concept-Targets.html
_dyld_start 之前
内核挖掘 _dyld_start是怎么被调用到的
_dyld_start的方法地址的确是在 LC_UNIXTHREAD 段中解析出来的。后续通过thread_setentrypoint 直接将用户态的pc设置到这个地址来执行的。
_dyld_start 是如何一步步执行到的？
▼ execve // 用户点击了app, 用户态会发送一个系统调用 execve 到内核
▼ __mac_execve // 创建线程
▼ exec_activate_image // 在 encapsulated_binary 这一步会根据image的类型选择imgact的方法
▼ exec_mach_imgact //主要Mach-o检测 检测头部 解析架构 检查imgp 拒绝dylib bundle （由dyld加载）！！把Mach-o映射到内存中
▼ load_machfile //会加载Mach-O中的各种load monmand命令 内部会禁止数据段执行，防止溢出漏洞攻击，还会设置地址空间布局随机化（ASLR），还有一些映射的调整
▶︎ parse_machfile //解析主二进制macho 对于命令的加载会进行多次扫描，当扫描三次之后，并且存在dylinker_command命令时，会执行 load_dylinker()，启动动态链接器 (dyld)
▼ load_dylinker // 解析完 macho后，根据macho中的 LC_LOAD_DYLINKER 这个LoadCommand来启动这个二进制的加载器，即 /usr/bin/dyld
▼ parse_machfile // 解析 dyld 这个mach-o文件，这个过程中会解析出entry_point
▼ activate_exec_state
▶︎ thread_setentrypoint // 设置entry_point。
暂且简单 利用此总结的原因 继续从_dyld_start 内部 来学习其他内容
_dyld_start 之前部分引用：https://www.jianshu.com/p/8498cec10a41
