CN111722948A - 一种arm指令集软错误故障注入系统及其方法 - Google Patents
一种arm指令集软错误故障注入系统及其方法 Download PDFInfo
- Publication number
- CN111722948A CN111722948A CN202010505425.3A CN202010505425A CN111722948A CN 111722948 A CN111722948 A CN 111722948A CN 202010505425 A CN202010505425 A CN 202010505425A CN 111722948 A CN111722948 A CN 111722948A
- Authority
- CN
- China
- Prior art keywords
- error
- development board
- openocd
- injection
- python
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/008—Reliability or availability analysis
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/22—Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing
- G06F11/2273—Test methods
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/61—Installation
- G06F8/63—Image based installation; Cloning; Build to order
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Quality & Reliability (AREA)
- Software Systems (AREA)
- Computer Hardware Design (AREA)
- Stored Programmes (AREA)
Abstract
本发明提供一种ARM指令集软错误故障注入系统及其方法,包括工作电脑、目标开发板、JTAG接口和USB接口,工作电脑内安装有Python注错脚本和OpenOCD,工作电脑通过JTAG接口与目标开发板相连,OpenOCD通过JTAG接口控制目标开发板,目标开发板通过USB接口向工作电脑中的Python注错脚本回传日志信息。本发明使用OpenOCD作为核心内容,通过调用OpenOCD提供的接口,修改程序的指令和内存值,从而达到对程序注入软错误的目的,实现对ARM指令集的自动测试,使用方便,且成本低廉,实现简单,为开发者分析ARM指令集的可靠性提供了一种低成本又高效的自动测试途径。
Description
技术领域
本发明涉及一种ARM指令集软错误故障注入系统及其方法,属于可靠性领域。
背景技术
随着ARM技术的迅猛发展,嵌入式应用不仅在我们的生活中随处可见,同时,在航空、汽车和军工等安全相关行业中也是比比皆是,例如,在航天行业中,ARM芯片作为控制单元,负责控制内部各个电子部件的运行。然而,在这些安全相关的行业中,恶劣的辐照环境会造成芯片内部出现软错误。所谓软错误,是指高能粒子打击集成电路,从而改变程序指令或者内存数值,进而影响程序运行,严重地,甚至会导致程序工作异常。
为了提高嵌入式系统中ARM芯片对软错误的可靠性,传统的加固方式有硬件加固和软件加固。前者会造成开发上额外的经济和时间成本开销。后者会大量增加应用运行的时间开销。为了克服这些缺点,相关研究提出了一种基于指令的加固方式。然而,指令加固要求开发者能够知道对软错误敏感的指令组。而现有的嵌入式系统的可靠性评估方式分为两类,一类是针对外部电路的故障注入系统,一类是针对内存的故障注入系统。前者只能帮助开发者查找外部电路中对软错误敏感的元器件。后者只能辅助开发者分析内存中软错误对系统的影响。因此,目前现有的可靠性评估方式无法为开发者提供指令级的分析方式。如上所述,ARM指令集的软错误率评估技术仍然是一片空白,亟待解决。
发明内容
为了解决现有技术存在的技术问题,本发明提供一种ARM指令集软错误故障注入系统及其方法,使用OpenOCD作为核心内容,通过调用OpenOCD提供的接口,修改程序的指令和内存值,从而达到对程序注入软错误的目的,实现对ARM指令集的自动测试,使用方便,且成本低廉,实现简单,为开发者分析ARM指令集的可靠性提供了一种低成本又高效的自动测试途径。
本发明中主要采用的技术方案为:
一种ARM指令集软错误故障注入系统,包括工作电脑、目标开发板、JTAG接口和USB接口,所述工作电脑内安装有Python注错脚本和OpenOCD,所述Python注错脚本通过pexpect调用OpenOCD,从而与OpenOCD交互,所述工作电脑分别通过JTAG接口和USB接口与目标开发板相连,所述OpenOCD通过JTAG接口控制目标开发板,所述目标开发板通过USB接口向工作电脑中的Python注错脚本回传日志信息。
优选地,权利要求1所述的系统的具体工作步骤如下:
S1:对待注错的应用源码插入相关的注错辅助函数和标志变量;
S2:使用Keil通过JTAG接口将可注错的应用源码烧录至目标发开板;
S3:启动OpenOCD,调用Python注错脚本,对目标开发板进行指令注错;
S4:注错完成后,Python注错脚本解析注错结果,并以excel的形式导出指令集的软错误率评估报告。
优选地,所述步骤S3的具体注错步骤如下:
S3-1:启动OpenOCD,连接目标开发板;
S3-2:Python注错脚本读取注错任务的配置信息,配置信息包括注错次数、错误模型、睡眠等待最小时间、超时等待最大时间;
S3-3:初始化串口任务,使用USB接口接收目标开发板的回传信息;
S3-4:挂起目标开发板程序,设置相关的辅助断点,具体包括开始断点和结束断点;
S3-5:判断是否达到注错次数,若是,则转入步骤3-14,否则,转入步骤3-6;
S3-6:重启目标开发板程序,等待目标开发板的开始断点的通知;
S3-7:接收到开始断点的通知,使Python注错脚本随机等待一段时间,等待的最小时间值由睡眠等待最小时间决定;
S3-8:当达到睡眠时间,Python注错脚本被唤醒;
S3-9:挂起目标开发板程序,调用OpenOCD对当前指令的目的寄存器注错,并设置DEBUG_FLAG=1;
S3-10:恢复开发板程序运行,等待结束断点的通知;
S3-11:判断5s内是否接收到结束断点的通知,若是,说明业务代码已经执行完毕,转入步骤S3-13,否则,说明业务代码已经崩溃,转入步骤S3-12;
S3-12:跳出等待,转入步骤S3-13;
S3-13:将注错结果保存,转入步骤5;
S3-14:挂起目标开发板,并汇总注错结果,结束。
有益效果:本发明提供一种ARM指令集软错误故障注入系统及其方法,适用于主流的ARM核芯片,具有如下优点:
1)硬件需求低,包括工作电脑、目标开发板、JTAG接口和USB接口,成本低廉,实现简单;
2)通过Python脚本调用OpenOCD实现对ARM指令集软错误率的自动测试,开发者使用方便;
3)填补了现有技术无法评估ARM指令集可靠性的这片空白。
附图说明
图1是本发明的系统原理图;
图2是本发明的方法流程图;
图3是本发明的软错误故障注入方法中注错脚本的流程图;
图4是本发明的ARM指令集软错误率的示例图。
具体实施方式
为了使本技术领域的人员更好地理解本申请中的技术方案,下面对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都应当属于本申请保护的范围。
如图1所示,一种ARM指令集软错误故障注入系统,包括工作电脑、目标开发板、JTAG接口和USB接口,所述工作电脑内安装有Python注错脚本和OpenOCD,所述Python注错脚本通过pexpect调用OpenOCD,从而与OpenOCD交互,所述工作电脑分别通过JTAG接口和USB接口与目标开发板相连,所述OpenOCD通过JTAG接口控制目标开发板,所述目标开发板通过USB接口向工作电脑中的Python注错脚本回传日志信息。OpenOCD是一款C语言编写的应用程序,可以运行于Linux和Windows系统。通过Python的pexpect可以调用OpenOCD,从而与OpenOCD交互,例如,读取信息,控制OpenOCD。pexpect是Python的一款开源库,可以直接使用。
优选地,权利要求1所述的系统的具体工作步骤如下:
S1:对待注错的应用源码插入相关的注错辅助函数和标志变量;
S2:使用Keil通过JTAG接口将可注错的应用源码烧录至目标发开板;Keil是一款C语言编译工具,属于常规技术。
S3:启动OpenOCD,调用Python注错脚本,对目标开发板进行指令注错;
S4:注错完成后,Python注错脚本解析注错结果,并以excel的形式导出指令集的软错误率评估报告。(注错过程中,目标开发板通过USB接口将注错相关信息反馈给Python注错脚本,Python注错脚本会对它们集中保存。所有注错完成后,Python注错脚本会对它们集中处理,处理完成后,以excel的形式将结果导出,保存在电脑端。)
优选地,如图3所示,所述步骤S3的具体注错步骤如下:
S3-1:启动OpenOCD,连接目标开发板;
S3-2:Python注错脚本读取注错任务的配置信息,配置信息包括注错次数、错误模型、睡眠等待最小时间、超时等待最大时间;
S3-3:初始化串口任务,使用USB接口接收目标开发板的回传信息;
S3-4:挂起目标开发板程序,设置相关的辅助断点,具体包括开始断点和结束断点;
S3-5:判断是否达到注错次数,若是,则转入步骤3-14,否则,转入步骤3-6;
S3-6:重启目标开发板程序,等待目标开发板的开始断点的通知;
S3-7:接收到开始断点的通知,使Python注错脚本随机等待一段时间,等待的最小时间值由睡眠等待最小时间决定;
S3-8:当达到睡眠时间,Python注错脚本被唤醒;
S3-9:挂起目标开发板程序,调用OpenOCD对当前指令的目的寄存器(在目标开发板里的)注错,并设置DEBUG_FLAG=1(初始值为0);
S3-10:恢复开发板程序运行,等待结束断点的通知;
S3-11:判断5s内是否接收到结束断点的通知,若是,说明业务代码已经执行完毕,转入步骤S3-13,否则,说明业务代码已经崩溃,转入步骤S3-12;
S3-12:跳出等待,转入步骤S3-13;
S3-13:将注错结果保存,转入步骤5;
S3-14:挂起目标开发板,并汇总注错结果,结束。
本发明中,为了说明所述步骤S1的工作原理,给出以下示例:
示例中,int main(void)为应用程序的入口函数;init()表示应用程序的初始化;bp_start()和bp_end()为空函数,这两个函数是提前写进去的,地址固定,用于Python注错脚本插入开始断点和结束断点,开始断点通知Python注错脚本应用程序已经完成了初始化工作,避免注错工具对初始化代码注错,结束断点通知Python注错脚本准备下一轮注错,如果没有这个结束断点通知,Python注错脚本无法知道应用程序是否结束而一直在等待;app_run()表示等待注错的应用的核心业务代码入口;print_output()表示通过USB串口将本次应用的输出信息回传给注错工具,以便后续分析。while函数中,在没有注错的情况下,DEBUG_FLAG恒为0,循环执行app_run();当注错工具对业务代码注入软错误后,会检测到DEBUG_FLAG变为1(注错工具注入错误后,会将DEBUG_FLGA置为1),从而通过串口将本次运行的输出信息回传给注错工具,并跳出循环。对于DEBUG_FLAG,为了方便Python注错脚本修改它的值,提前赋予了一个固定地址。
其中,为了说明步骤S3-9中Python注错脚本的注错原理,给出以下具体示例:
OpenOCD input:halt
OpenOCD output:0x08002bd4
OpenOCD input:arm disassemble 0x08002bd4
OpenOCD output:0x08002bd4 0x3110 ADDS r1,#0x10
OpenOCD input:step
OpenOCD output:0x08002bd6
OpenOCD input:reg r1
OpenOCD output:r1(/32):0x08004f10
OpenOCD input:reg r1 0x48004f10
OpenOCD output:r1(/32):0x48004f10
OpenOCD input:mww 0x20000000 0x1
上面示例中,OpenOCD input:表示OpenOCD对目标开发板发送命令;OpenOCDoutput:表示目标开发板返回给OpenOCD的信息;halt、arm disassemble、step、reg和mww为OpenOCD提供的接口命令。
在OpenOCD工作端的步骤如下:
1)使用halt命令,挂起目标开发板程序,获取当前指令的地址值pc,示例中为0x08002bd4;
2)使用arm disassemble pc值命令,获取当前地址值的操作码,注错脚本解析操作码得到汇编指令和目的寄存器,示例中,pc值为0x08002bd4,操作码为0x3110,汇编指令为ADDs,目的寄存器为r1;
3)使用step命令,单步运行这条指令,目的是为了让目的寄存器值更新为指令计算值;
4)使用reg寄存器名命令,获取目的寄存器的当前值,示例中,目的寄存器为r1,返回值为0x08004f10;
5)使用reg寄存器名数值命令,对目的寄存器注入错误值,示例中,目的寄存器为r1,数值为0x48004f10,数值(0x48004f10)是由注错脚本根据错误模型和目的寄存器当前值决定;
6)使用mww数值命令,修改内存值。示例中,0x20000000为DEBUG_FLAG预先编译的内存地址,0x1将DEBUG_FLAG设置为1,用于通知开发板端程序注错已经完成。
如图4所示,为ARM指令集的软错误率报告示例。图中,纵坐标为指令脆弱因子(PVF),表示在软错误的干扰下,对应指令组的错误对输出结果影响的概率;横坐标为指令类型;Masked表示错误未对程序的输出造成影响;SDC表示错误导致程序输出与无错程序的输出不一致;DUE表示错误导致程序崩溃。
其中,PVF的计算公式如下:
在公式(1)中,inst表示指令组类型;type表示错误对输出的影响类型;n表示type对应的错误出现的次数;N表示总的注错次数,以图4为例,inst为vldr,type为Masked,注错次数为1000,Masked错误出现了318次,所以,PVFvldr_type为0.318。
在ARM指令集中,对于同一种操作的指令,由于状态位或者操作器寄存器的细节不同,会产生不同格式的指令表达形式。例如,对于加法指令add,它的原型格式为ADD,当附加状态位时,衍生出了ADC的格式。为了方便使用者阅读实验结果内容,对于不同的指令组,按它们的操作类型分类,忽略它们附加的标志位,并按它们的原型格式降为小写形式。例如,对于ADD和ADC,它们都是加法指令,表示格式为add;对于STR和STRB,它们都是存储指令,只是操作寄存器的宽度不同,因此它们归为一类,表示格式为str。
对于开发者而言,主要考虑指令组对应的SDC和DUE的PVF,它们越高,代表指令组产生SDC和DUE的概率越大。例如,图4中,PVFadd_SDC为0.016,因此,如果对add进行三模冗余,理论上,可以把系统整体的SDC PVF降低0.016。通过使用软错误率报告,开发者可以快速得到系统中对软错误敏感的指令组,为对ARM应用进行指令分析提供了可能。
以上所述仅是本发明的优选实施方式,应当指出,对于本技术领域的普通技术人员来说,在不脱离本发明原理的前提下,还可以做出若干改进和润饰,这些改进和润饰也应视为本发明的保护范围。
Claims (3)
1.一种ARM指令集软错误故障注入系统,其特征在于,包括工作电脑、目标开发板、JTAG接口和USB接口,所述工作电脑内安装有Python注错脚本和OpenOCD,所述Python注错脚本通过pexpect调用OpenOCD,从而与OpenOCD交互,所述工作电脑分别通过JTAG接口和USB接口与目标开发板相连,所述OpenOCD通过JTAG接口控制目标开发板,所述目标开发板通过USB接口向工作电脑中的Python注错脚本回传日志信息。
2.一种ARM指令集软错误故障注入方法,其特征在于,权利要求1所述的系统的具体工作步骤如下:
S1:对待注错的应用源码插入相关的注错辅助函数和标志变量;
S2:使用Keil通过JTAG接口将可注错的应用源码烧录至目标发开板;
S3:启动OpenOCD,调用Python注错脚本,对目标开发板进行指令注错;
S4:注错完成后,Python注错脚本解析注错结果,并以excel的形式导出指令集的软错误率评估报告。
3.根据权利要求1所述的一种ARM指令集软错误故障注入方法,其特征在于,所述步骤S3的具体注错步骤如下:
S3-1:启动OpenOCD,连接目标开发板;
S3-2:Python注错脚本读取注错任务的配置信息,配置信息包括注错次数、错误模型、睡眠等待最小时间、超时等待最大时间;
S3-3:初始化串口任务,使用USB接口接收目标开发板的回传信息;
S3-4:挂起目标开发板程序,设置相关的辅助断点,具体包括开始断点和结束断点;
S3-5:判断是否达到注错次数,若是,则转入步骤3-14,否则,转入步骤3-6;
S3-6:重启目标开发板程序,等待目标开发板的开始断点的通知;
S3-7:接收到开始断点的通知,使Python注错脚本随机等待一段时间,等待的最小时间值由睡眠等待最小时间决定;
S3-8:当达到睡眠时间,Python注错脚本被唤醒;
S3-9:挂起目标开发板程序,调用OpenOCD对当前指令的目的寄存器注错,并设置DEBUG_FLAG=1;
S3-10:恢复开发板程序运行,等待结束断点的通知;
S3-11:判断5s内是否接收到结束断点的通知,若是,说明业务代码已经执行完毕,转入步骤S3-13,否则,说明业务代码已经崩溃,转入步骤S3-12;
S3-12:跳出等待,转入步骤S3-13;
S3-13:将注错结果保存,转入步骤5;
S3-14:挂起目标开发板,并汇总注错结果,结束。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202010505425.3A CN111722948B (zh) | 2020-06-05 | 2020-06-05 | 一种arm指令集软错误故障注入系统及其方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202010505425.3A CN111722948B (zh) | 2020-06-05 | 2020-06-05 | 一种arm指令集软错误故障注入系统及其方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN111722948A true CN111722948A (zh) | 2020-09-29 |
CN111722948B CN111722948B (zh) | 2023-06-13 |
Family
ID=72566150
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202010505425.3A Active CN111722948B (zh) | 2020-06-05 | 2020-06-05 | 一种arm指令集软错误故障注入系统及其方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN111722948B (zh) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN113407394A (zh) * | 2021-05-31 | 2021-09-17 | 浪潮电子信息产业股份有限公司 | 一种服务器ras功能测试的方法、装置、设备和介质 |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1963785A (zh) * | 2006-12-12 | 2007-05-16 | 北京中星微电子有限公司 | 软件测试系统和软件测试方法 |
CN104657247A (zh) * | 2015-02-10 | 2015-05-27 | 上海创景计算机系统有限公司 | 基于jtag调试方式实现通用型故障注入系统和故障注入方法 |
CN110362440A (zh) * | 2019-06-19 | 2019-10-22 | 福州瑞芯微电子股份有限公司 | 一种带虚拟uart的jtag调试系统 |
-
2020
- 2020-06-05 CN CN202010505425.3A patent/CN111722948B/zh active Active
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1963785A (zh) * | 2006-12-12 | 2007-05-16 | 北京中星微电子有限公司 | 软件测试系统和软件测试方法 |
CN104657247A (zh) * | 2015-02-10 | 2015-05-27 | 上海创景计算机系统有限公司 | 基于jtag调试方式实现通用型故障注入系统和故障注入方法 |
CN110362440A (zh) * | 2019-06-19 | 2019-10-22 | 福州瑞芯微电子股份有限公司 | 一种带虚拟uart的jtag调试系统 |
Non-Patent Citations (2)
Title |
---|
IAMAPROGRAMMER: "Open JTAG Project", 《HTTPS://WWW.CNBLOGS.COM/SHANGDAWEI/P/4756393.HTML》 * |
钱军: "基于JTAG的故障注入研究", 《第五届中国测试学术会议论文集• 中国苏州》 * |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN113407394A (zh) * | 2021-05-31 | 2021-09-17 | 浪潮电子信息产业股份有限公司 | 一种服务器ras功能测试的方法、装置、设备和介质 |
CN113407394B (zh) * | 2021-05-31 | 2023-03-28 | 浪潮电子信息产业股份有限公司 | 一种服务器ras功能测试的方法、装置、设备和介质 |
Also Published As
Publication number | Publication date |
---|---|
CN111722948B (zh) | 2023-06-13 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7950001B2 (en) | Method and apparatus for instrumentation in a multiprocessing environment | |
WO2018072493A1 (zh) | 编译方法和编译系统 | |
CN1993679B (zh) | 执行计算机程序的方法、操作系统和计算设备 | |
WO2016004806A1 (zh) | 基于程序约束构建的多线程程序输出唯一性检测与证据生成方法 | |
WO2022227410A1 (zh) | 一种嵌入式终端远程软件调试方法 | |
US20120036501A1 (en) | Method and System for Capturing System and User Events Using Hardware Trace Devices | |
US9830196B2 (en) | Methods and apparatus to manage concurrent predicate expressions | |
Cotard et al. | A data flow monitoring service based on runtime verification for autosar | |
CN111722948A (zh) | 一种arm指令集软错误故障注入系统及其方法 | |
Visan et al. | URDB: a universal reversible debugger based on decomposing debugging histories | |
CN105630664B (zh) | 一种反向调试方法、装置及调试器 | |
CN110704315A (zh) | 一种嵌入式软件测试的故障注入装置 | |
CN102331961B (zh) | 并行模拟多个处理器的方法及系统、调度器 | |
US8707267B1 (en) | Debugging a computer program by interrupting program execution in response to access of unused I/O port | |
CN112285542B (zh) | 一种面向fpga外部接口逻辑的调试与测试方法 | |
CN113760290A (zh) | 一种程序控制方法、装置、计算机设备及存储介质 | |
US20060070039A1 (en) | Address watch breakpoints with basing pointers | |
CN114218067A (zh) | 一种异构众核软件调试装置及调试方法 | |
CN112783736B (zh) | 软件组件的运行体时间监测方法、装置及电子设备 | |
CN111008133B (zh) | 粗粒度数据流架构执行阵列的调试方法及装置 | |
CN112540908B (zh) | 面向异构众核处理器的轻量级软件调试方法 | |
CN114780409A (zh) | 基于程序运行进程的断点设置方法、电子设备和存储介质 | |
Wang et al. | Dependence-based multi-level tracing and replay for wireless sensor networks debugging | |
CN108121627B (zh) | 一种VxWorks操作系统调试方法 | |
CN113742252A (zh) | 一种检测内存乱序的方法及装置 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |