MindStudio Ops Common 架构设计说明¶
目录设计¶
针对该软件仓,整体目录设计思路如下:
MindStudio-Ops-Common
|-- .gitmodules # 管理依赖的submodule文件
|-- build.py # 一键式构建脚本入口
|-- csrc # 提供针对CPU侧接口的劫持能力
|-- include # 劫持对象的原始头文件
|-- core # 核心功能:通信(控制,数据-数据流/文件,支持父子孙进程);接口注册;接口绑定;
|-- runtime # 提供runtime下的接口的劫持函数 和 原始接口的别名
|-- RuntimeOrigin.h # 提供原始接口的别名
|-- injectionOfxxx # 提供runtime下的xx接口的劫持函数
|-- ...
|-- bind # 将接口与具体的工具绑定,并支持进程间控制和数据传输能力
|-- BindCoverage.cpp # 将decorated function和具体的runtime接口绑定,每个工具一个
|-- kernel_injection # 提供针对kernel侧的劫持能力, 内容过少
|-- test # 测试用例看护
|-- thirdparty # 三方依赖存放目录
|-- docs # 项目文档介绍
└── README.md # 整体仓代码说明
说明:
-
csrc中提供了如下功能:
-
(对于劫持目标)提供原生接口的管理
- (统一共性插件)提供注入(修饰)函数的管理
- (对于特定工具)提供劫持接口的统一管理,并支持注入函数的通信控制
- 具体工具直接引用该仓库,完成二进制的编译,提供submodule功能支持特定工具injection的单独编译。
- 此处kernel_injection仅针对动态插桩能力(静态插桩能力由各组件自身承载)
- 现支持bisheng-tune,未来需要支持msbit的能力
- 本身需要配套csrc中的kernel替换能力使能,并由其作为出口
- 除了特定插件外,后续插件能力优先集成到mstracekit中,特定插件可以集成到特定工具。比如:监控插件到msprof,检测插件到mssanitizer。
工具限制与注意事项¶
框架说明¶
如果要实现代码桩,以coverage工具添加runtime模块为例,主要需要在如下内容中进行添加和删减工作:
- csrc/include 此处是劫持函数的头文件,最好一次性放全 (即使没用也可以放着)
- csrc/xxx/xxxOrigin 此处是劫持接口的别名,使用时如果没有则添加(只要有工具实现过,就会加一个)
- csrc/xxx/InjectionOfxxxx 此处是注入函数的实现,如果没有变化,则仅需修改CMakeLists.txt引入
- bind/Bindxxxx 每次加新接口时,必然需要添加该部分内容
- csrc/xxx/CMakeLists.txt 如果存在新增文件,需要添加到对应目录中
说明:
- 不能在CMakeLists.txt中全匹配,需要写精确匹配,从而支持增量编译。
- 如果存在同一个接口,不同的桩实现的话,差异较大,可以以工具分类进行文件夹隔离,如果差异较小,可以仅仅宏隔离。
- 对于同名接口在不同的工具上有不同的实现,这个InjectionOfxxx命名有差异,建议末尾添加上ForXXX,通过编译隔离;不建议宏隔离,因为我们只有1个UT进程。此外,建议代码实现在同一主干上。
定位&周边配合¶
针对host injection部分:
- 该仓库仅提供完整的二进制库,不同工具的劫持诉求由编译选项进行区分。
- 针对同个接口,不同工具的注入内容存在差异,该差异在bind文件夹中进行关联。
针对kernel injection部分:
- include文件夹提供对外的头文件接口, 目前msbit的生成控制信息能力只有msbit一个文件,暂不建立文件夹。而msbit解析so生成新的kernel能力目前放置于customDBI类里。后续对外的接口可以实现在core里。想增加使用示例,可以新增tools文件夹下放置不同的劫持案例。各个工具自己的劫持函数以及bind调用实现在自己工具里,工具构建提供.so,不放在基础组件内。
- 不同插件感知不同的指令进行操作。
- 集成模块需要负责host的结构体的解析处理。
- 本身需要与host injection协同,自身通过头文件方式引入到host injection的decorated function中。