- 积分
- 2462
- 最后登录
- 2020-7-2
- 精华
- 0
- 阅读权限
- 50
- 主题
- 51
- UID
- 3677882
- 帖子
- 4805
- PB币
- 5195
- 威望
- 90
- 贡献
- 0
- 技术
- 858
- 活跃
- 538
论坛出bug收不到PM,请别发。
- UID
- 3677882
- 帖子
- 4805
- PB币
- 5195
- 贡献
- 0
- 技术
- 858
- 活跃
- 538
|
发表于 2014-2-9 01:16:23
IP属地江苏
|显示全部楼层
对于反复编译出错的 dsdt,我们基本已经可以肯定是由于反编译过程的 bug 产生。理由如下:
一、dsl 在编写的过程一些特别明显的错误是不可能犯的,更不可能好多厂商的程序员同时犯相同的错误,所以 dsl 在编写过程中出现那么离奇的错误基本是不可能的。
二、编译后的二进制文件是没有错的,不然也无法通过机器执行,所以编译过程是不会产生这么严重的错误的。
三、在一和二成立的前提下,我们再次看到源码是在反编译过程后,那么错误是在反编译过程中产生的。
我没看过反编译器的源码,但我猜测(也有别的可能),在反编译时,反编译器会对于 dsdt(或者是 ssdt) 内的各类变量进行检测,对于函数所使用的参数的个数也会确定,这时对于 dsdt 里写了的,基本不会出现检测错误,但是对于 dsdt 前面声明的External 里的各类变量(如:External (PDC5),下面以此为例),因为反编译器不知道PDC5是什么变量(可能是整数变量,也可能是函数等等),反编译器就会猜测其类型,如果反编译器把原本是整数的 PDC5猜成了函数,那下面必然会给 PDC5使用调用程式(PDC5()),那下面就有可能会产生接二连三的符号错误……符号错误最明显的影响是导致一大堆的参数找不到。其它的各种错就不一一列举了……(实为本人能力有限)
四、楼主指明的方法正好可以帮助反编译器解决上面说的这个问题(好多 External 里声明的就是 ssdt 里的变量 ),所以按楼主的方法反编译出的 dsl 文件基本没有错误,这也可以反过来证明三中猜想的正确性。
贴上一段我使用楼主所给方法反编译微星 ge60的 dsdt 时 dsl 给出的提示- /*
- * iASL Warning: There were 8 external control methods found during
- * disassembly, but only 7 were resolved (1 unresolved). Additional
- * ACPI tables are required to properly disassemble the code. This
- * resulting disassembler output file may not compile because the
- * disassembler did not know how many arguments to assign to the
- * unresolved methods.
- */
- External (_SB_.TPM_.PTS_, MethodObj) // Warning: Unresolved Method, guessing 1 arguments (may be incorrect, see warning above)
复制代码 解决办法:
如果三中猜想正确,那么,问题的产生过程也就明确了,解决方法就有两个(欢迎提供更好的解决办法):
1.修复反编译器的 bug……;
2.把会识别错的变量写到 dsdt 里去。
显然2比较实际一点。我实际测试也是2可以基本解决这个问题。这个解决方法也可以用来证明三中猜想正确。
深夜写天书,逻辑比较混乱……但愿有人能看懂……
……声明……
本人日语专业,未学过编程,所以有些专业术语不会使用,也有可能有些地方说的不对,还请各位看客多多包涵,如果能帮助小弟改正,更是感激不尽。 |
-
1
查看全部评分
-
|