TTCN3新执行器系列-说说基于TTCN3代码行的调试器实现

关于调试器，基于内存对象的TTCN3执行器是支持的。
但对于新执行器，也就是基于语言转换的版本，我们需要重头实现，工作量和难度不小。

首先，TTCN3转换成C++语言来跑，那调试是基于TTCN3还是C++？
从用户角度来说，当然是TTCN3了，用户根本就不会理会你转换成C/C++还是JAVA，他不care。

实现这样的调试器比较麻烦，因为是跑的是C++代码，而要调试的是TTCN3。

开始的时候，我们是寄望于VC的pdb文件的，也就是仿VC调试器的做法。
但慢慢的觉得这行不动，因为VC调试器只涉及C++语言，而我们多了一分抽象，从TTCN3到C++的映射。

 

最终实现的版本，是印度人开发的，原理很简单，就是在转换的C++代码中大量嵌入作用域语句。
利用这些作用域语句，将TTCN3的作用域合理的映射成C++的作用域。
在每一行TTCN3代码中插入一行trace语句，用于刷新相关信息(譬如行号，作用域变量状态等)。

该方案继续无法避免的加大了转换后的C++代码量（按道理一行TTCN3最少对应新增一行C++代码），
于是编译速度继续下降，比较杯具。

 

后来针对印度人的版本，我简单优化了一下。
印度人使用了大量的宏在转换后的C++代码区分release和debug版本，让release版本无调试代码编译负担。
这个想法很好，但不实际。

因为用户开发过程中需要在release和debug版本中随意切换（其实用户不关心是release还是debug版本，他们要跑就跑，要调试就调试），
鉴于新执行器编译速度本来就慢，如果切换后还得编译一次，估计是杯具中的餐具了，而且编译后的中间文件还两份，非常占用空间。
于是我采用了统一方案，在转换后的C++代码中将release和debug版本归一化处理，
虽然新增的调试代码全带上，但通过引入flag变量，在运行时库中由上层传递区分，这样虽然代码加大了，但代码处理统一而简单，对用户体验更好。

 

我们希望尽量将处理细节隐藏到运行时库中实现，
上层逻辑代码做的越简单越好，很多时候，简单就是可靠和可维护。