支持含有碎片的文件仿真

不点

mdyblog 发表于 2015-1-12 12:15
>>
和你的想法正好相反。保护模式的堆栈空间最容易控制，这由编程者直接控制，你只要优化程序，尽量不占 ...

上海复旦大学的投毒杀人案，一审、二审被判死刑，而杀人者的律师说，不是故意杀人，判死刑太重了，要到最高法院继续申诉。

同一件事，众说纷纭，一点也不奇怪。持什么观点，都正常，没有不正常的观点。

最终的判决，肯定让一部分人满意，而让另一部分人不满意。这是无法避免的。

chenall

根跟我的调试结果来看,应该是循环嵌套太多层导致的,看来有必要限制一下循环嵌套的层数.

另外发现F6IMG里面有许多不必要的循环.有必要优化一下.

就是不知一层需要多少的堆栈空间?这个有没有什么办法计算.比如调用某个函数需要多少堆栈空间,这个能计算出来吗?

好像和应该函数里面的变量和参数有关系?有没有什么保守的计算方法.这样就可以太概估计一下可以几层而不出问题.

mdyblog

chenall 发表于 2015-1-12 15:38
根跟我的调试结果来看,应该是循环嵌套太多层导致的,看来有必要限制一下循环嵌套的层数.

另外发现F6IMG里 ...

>>根跟我的调试结果来看,应该是循环嵌套太多层导致的,看来有必要限制一下循环嵌套的层数.

另外发现F6IMG里面有许多不必要的循环.有必要优化一下.

就是不知一层需要多少的堆栈空间?这个有没有什么办法计算.比如调用某个函数需要多少堆栈空间,这个能计算出来吗?

好像和应该函数里面的变量和参数有关系?有没有什么保守的计算方法.这样就可以太概估计一下可以几层而不出问题.
--------------------------------
你程序中有2个堆栈。
1）默认堆栈。
由于 你没有定义大的数组，
这个每次是很小的。
主要是定义的临时变量。

保守计算：
2层嵌套之间C函数调用次数N
最长路径临时变量总空间M，由于有优化，一个函数内部的所有 临时变量都算， 哪怕在调用函数的后面；并列代码块中的都算。

保守大小S1
指针字节数P=sizeof(char*)
S1=2NP +  M

并列路径函数取最大值。

不过实际比这个小得多。

最好的办法是，
判断sp寄存器。
设定最低限SPL  
SPL =栈底 + 保险长度
保险长度 可以取：  16+该函数中变量总内存。

在call: 函数 中
if(sp<=SPL)  ｛ printf("\nFAULT: <<<<<<<<<<SYSTETM STATCK RUNOUT>>>>>>>>>\n");  return ; }

还有，作为验证，  把系统栈扩大到1M。  100次嵌套， 应该不会溢出的。


2） 命令行堆栈
最长命令行的L
保守大小S2
S2=NL

测试了下find_oem函数， 这个目前才嵌套30多次， 没有溢出。
这里没计算：  复合语句，转为嵌套。没研究G4D程序是否有这种嵌套。


作为验证，  把命令行堆栈扩大到1M。  

mdyblog

chenall 发表于 2015-1-12 15:38
根跟我的调试结果来看,应该是循环嵌套太多层导致的,看来有必要限制一下循环嵌套的层数.

另外发现F6IMG里 ...

>>另外发现F6IMG里面有许多不必要的循环.有必要优化一下.

这件事 很麻烦的。
很多人写出来的代码算法没有优化。

有的是水平原因。
有的是对待此事的太多所致（没有认为是多么重要的事情，需要费力优化）
——优化本来就有风险。优化 一般用到条件边界。 很多错误就是优化引入的——编译器也是如此。

chenall

mdyblog 发表于 2015-1-12 16:06
>>根跟我的调试结果来看,应该是循环嵌套太多层导致的,看来有必要限制一下循环嵌套的层数.

另外发现F ...

还有，作为验证，  把系统栈扩大到1M。  100次嵌套， 应该不会溢出的。

是指cmd_buffer吗?这个我测试过了用了还不到一半只用了4KB左右.

chenall

mdyblog 发表于 2015-1-12 16:14
>>另外发现F6IMG里面有许多不必要的循环.有必要优化一下.

这件事 很麻烦的。

这个估计和个人习惯也有关系..

我自己写的代码,我会尽量优化(在时间能力允许的条件下),就当是学习.

刚开始写出来的可能就是勉强能用,以后经过一次一次改进优化.

现在如果限制一下嵌套层数那F6IMG估计就不能正常运行了.

mdyblog

chenall 发表于 2015-1-12 17:01
这个估计和个人习惯也有关系..

我自己写的代码,我会尽量优化(在时间能力允许的条件下),就当是学习.

是现在的版本， 比1206版， 堆栈（系统堆栈和命令行堆栈（cmd_buffer））更少了吗？

如果不是， 那更大的概率， 应该不是这个原因。

强烈建议， 还是从1206版开始。

找BUG，比解决问题更难的。
这其实是个很小的问题——不是什么关键问题。解决不难的。
并不涉及什么疑难杂症。

chenall

mdyblog 发表于 2015-1-12 18:24
是现在的版本， 比1206版， 堆栈（系统堆栈和命令行堆栈（cmd_buffer））更少了吗？

如果不是， 那 ...

对应的改动在这里没有修改cmd_buffer等相关代码.

https://github.com/chenall/grub4 ... f1f9385c42df5fd2f2a

看起来和上次的问题是一样,又是莫名其妙的.出现的问题和修改的代码是毫无关系的.

现在的F6IMG,只要再增加一个判断语句防止重复的空循环就可以跳过这个BUG.(我用debug测试到后面跳过部份代码行就提示成功,但能不能用没有测试)

mdyblog

chenall 发表于 2015-1-12 22:30
对应的改动在这里没有修改cmd_buffer等相关代码.

https://github.com/chenall/grub4dos/commit/f035 ...

测试结果：
1）
如果 加上死循环检测，并"exit"
那么， 之前的版本都能启动03PE-SATA。
测试了0111, 0110 1227

都会打印2行垃圾（前面帖子有图）。

只有 0111 不会显示 “Success”
-------------

2）
如果 死循环检测，并"exit 1"
即返回错误码，
都不显示 “Success”
记得 1227 显示失败。


3）
加上死循环检测，并"exit"

0111 生成的 TXTSETUP.OEM 和正常（1206）版不同。
奇怪的是，竟然也能启动！
文件见附加。
0111版： err0111.zip (1.39 KB, 下载次数: 2)

2015-1-13 11:42 上传

点击文件名下载附件

1206版： OK1206.zip (276.5 KB, 下载次数: 2)

2015-1-13 11:42 上传

点击文件名下载附件

看来还得从根本上解决啊！

chenall

mdyblog 发表于 2015-1-13 11:43
测试结果：
1）
如果 加上死循环检测，并"exit"

关键是根本的问题原因是什么???没有办法判断.前面的都只是猜测..经过调试我目前还是没有办法到找问题最终产生的原因..如果你能找得到最终的产生原因的代码那就好办了.

1.不是cmd_buffer的问题,
2,目前看起来也不像是系统堆栈的问题,因为只是循环嵌套了还不到40层,根据你前面给的测试代码可以到70层的.

另外你若是按你的建议大不了就恢复到1206版的源码,但是这样子又产生了前面的问题.

我觉得根本不是修改了代码的原因,而是有一些未知的原因,就像之前前面的问题一样.

mdyblog

chenall 发表于 2015-1-13 13:51
关键是根本的问题原因是什么???没有办法判断.前面的都只是猜测..经过调试我目前还是没有办法到找问题最终 ...

>>
另外你若是按你的建议大不了就恢复到1206版的源码,但是这样子又产生了前面的问题.
---
不是说恢复到1206了事。
而是 恢复到1206， 再以此为起点。把曾经做过的改动，再原样，一点一点地恢复过去。
1）每恢复一部分，再测试一下。
2）如果还是正常的，继续。
3）否则，代码修改，与最近正常的节点的差异减半。这样就能定位哪行代码为引起的问题。
4）“处理”该行代码。 （是"处理"，而不是"研究"。要么纠正（明显的）错误，要么用替代方法——不明晰的问题）
5）然后继续。指导重要的功能都恢复了。

对程序远来说，很多问题，在定位出来前，根本

>>我觉得根本不是修改了代码的原因,而是有一些未知的原因,就像之前前面的问题一样.
--------
《易经》西方“菲罗教”(Phylosophy)不同。
《易经》中没有所谓的“原因”。
用《易经》来指导这件事。
简单明晰。
最终还是“敲入代码”——“道”。 要么“敲入这样的代码”——“道1”，要么“敲入那样的代码”——“道2”。
最终正确，还是 “敲入某一正确的代码”这个“道3” 而已。

chenall

我前面#751已经贴上了出现问题的代码,这个代码也没有什么好修改的样子.

你有测试条件可以自己修改测试一下.反正在windows编译一下也是很简单的事情.

mdyblog

chenall 发表于 2015-1-13 14:50
我前面#751已经贴上了出现问题的代码,这个代码也没有什么好修改的样子.

你有测试条件可以自己修改测试一 ...

你那也可以测试的。
运行F6IMG 后
cmp  (0)/TXTSETUP.OEM   /ok1206/TXTSETUP.OEM   

就知道是否正确。


---
目前，先解决： 不出现 死循环（不是通过修改人家的代码）。
这个测试条件那儿都有的。


----
看代码，很难看出问题。  

mdyblog

chenall 发表于 2015-1-13 14:50
我前面#751已经贴上了出现问题的代码,这个代码也没有什么好修改的样子.

你有测试条件可以自己修改测试一 ...

GRUB4DOS编译器下载：http://code.google.com/p/grub4dos-chenall/downloads/detail?name=grub4dos_dev_2013-02-03.zip

这个打不开，
还有哪儿有？

不点

我觉得 mdyblog 也是程序员，当然也可以自己编译版本，按照自己的思路进行编程或定位错误。mdyblog 可以放出修改后的版本，让大家测试。一旦测试成功，再经 chenall 检查没问题的话，即可融入主版本当中。

这样大家都能完全发挥自己的特点，达到自己的 “极致” 和 “最好”。

自己的思维方法，只有自己能深切领会，要让别人领会，那不是一件容易的事。

譬如说，我经常谈哲学。可是谁赞成呢？假如我把我的这套东西强加给别人，不断指责别人这也不符合哲学，那也不符合哲学，那么别人高兴吗？

自己的东西自己运用，那是没问题的。但假如把自己的思想意识强加给别人，那往往是行不通的。

我认识到，我自己需要得到尊重，别人也需要得到尊重。要尊重别人的哲学信仰、宗教信仰、认识水平和思想方法，不能把自己的思想当作说教，去教训别人。如果凌驾于别人之上，就是对别人的一种伤害或不尊重。

mdyblog

git clone git://github.com/chenall/grub4dos.git grub4dos_src
-----------------
下载grubdos.a-20141206  grubdos.a-20141224，怎么下载？

chenall

先看这个页面.

https://github.com/chenall/grub4dos/commits/0.4.6a

找到1206的对应版本ID(这里是d3ce711)
则下载完源码之后就可以这样
git checkout d3ce711 -b 1206 就有一个1206的版本了.

1224对应的版本ID是F035079
git checkout F035079 -b 1224

不点

mdyblog 发表于 2015-1-13 17:21
git clone git://github.com/chenall/grub4dos.git grub4dos_src
-----------------
下载grubdos.a-20141 ...

我说一个方法，是我偏爱的。不用 git，而用 svn，这样可以一次性下载到 0.4.5 和 0.4.6 两个系列。

svn   co   https://github.com/chenall/grub4dos   grub4dos_src

如果是下载某次修订（比如第 577 次修订版），可以加上 -r 参数：

svn   co   -r   577   https://github.com/chenall/grub4dos   grub4dos_src

chenall

不点 发表于 2015-1-13 17:27
我说一个方法，是我偏爱的。不用 git，而用 svn，这样可以一次性下载到 0.4.5 和 0.4.6 两个系列。

sv ...

我git用习惯了,觉得比svn 强大多了,也是挺方便的.

git下载的是整个版本库的内容,下载之后可以随时切换到任意版本(不需要联网),本地临时测试分支等.

用SVN就是切换版本需要重新下载源码

不点

chenall 发表于 2015-1-13 17:29
我git用习惯了,觉得比svn 强大多了,也是挺方便的.

git下载的是整个版本库的内容,下载之后可以随时切 ...

git 还是没有学会，觉得很不顺利。所以，我还是偏爱 svn 的老一套。

mdyblog

不点 发表于 2015-1-13 17:27
我说一个方法，是我偏爱的。不用 git，而用 svn，这样可以一次性下载到 0.4.5 和 0.4.6 两个系列。

sv ...

1：
>>svn   co   -r   577   https://github.com/chenall/grub4dos   grub4dos_src

这个 577 怎么和版本对上关系， 哪儿有这个信息。


2：
svn 出错


git 能下，就是 不知道怎么 获得指定版本。
还是cvs简单明了。而且有个图形化的wincvs

不点

你还是用 chenall 在前面说的 git 方法吧。你的网络好像有问题，不支持 https 的 443 端口。

我的方法在我这里用很正常。

mdyblog

chenall 发表于 2015-1-13 17:29
我git用习惯了,觉得比svn 强大多了,也是挺方便的.

git下载的是整个版本库的内容,下载之后可以随时切 ...

问题找出来了。
disk_io.c 中的 block_read_func() 中那段代码引起的。
这儿换成 1206, 就号了，能启动03PE-SATA.
新源码，差异报告，生产文件见附件。

mdyblog

chenall 发表于 2015-1-13 17:29
我git用习惯了,觉得比svn 强大多了,也是挺方便的.

git下载的是整个版本库的内容,下载之后可以随时切 ...

2015-0109 修改后， 也能正常运行03PE-SATA。
F6IMG 彩色提示成功，没有垃圾显示(没加死循环检测)

chenall

下载看了下,你的源码比较乱,生成的diff文件不知是基于什么版本的.

我只好自己弄了个1206版的源码和你上传的1224修正版的disk_io文件比较了下.

看起来只是撤销了f0350793的所有改动,这个应该不能算是修复吧(我前面也有说过出现问题的改动就是在这里),只要恢复了那肯定就可以的.

这个改动主要是解决你的前一个问题(map (hd0)x+yy )很慢的问题.你可以用1206版的源码测试一下(不要改动源码),再用1224的源码测试下

用git可以随时使用某个版本的源码.

第一种 方法是git checkout f035079这个是1224版本

如果你有改动过源码还没有commit不能直接切换,这时如果这些改动要保留的话可以git commit -m "xxxx"保存一下改动再切换

如果改动不想保留,可以直接强制切换1224版
git reset --hard f035079

1206版的同上.

mdyblog

chenall 发表于 2015-1-13 19:23
下载看了下,你的源码比较乱,生成的diff文件不知是基于什么版本的.

我只好自己弄了个1206版的源码和你上 ...

目前，还不是“修复”，
而是定位出问题的代码行。

这样 不用 没有方向，疑神疑鬼。

接着才是 如何解决问题。---map慢的问题。

mdyblog

chenall 发表于 2015-1-13 19:23
下载看了下,你的源码比较乱,生成的diff文件不知是基于什么版本的.

我只好自己弄了个1206版的源码和你上 ...

搞定了。


源码： grub4dos-0.4.6a-2015-01-09-FIX-SRC.7z (740.91 KB, 下载次数: 5)

2015-1-14 10:44 上传

点击文件名下载附件

目标码： grub4dos-0.4.6a-2015-01-09-FIX-bin.7z (271.25 KB, 下载次数: 9)

2015-1-14 10:43 上传

点击文件名下载附件

源码 下载页面下载的ZIP包修改的， 请BC3比较。
grub4dos-54b867e229fd26e4f44a349095d7f3d0596247e1\  =原始下载的zip包的源码。
new-grub4dos-54b867e229fd26e4f44a349095d7f3d0596247e1\  =修改后的源码。

主要改的disk_io.c，的 block_read_func（）函数。
cmdline.c中的优化，不关键。

mdyblog

chenall 发表于 2015-1-13 19:23
下载看了下,你的源码比较乱,生成的diff文件不知是基于什么版本的.

我只好自己弄了个1206版的源码和你上 ...

发现一个可能的"定时炸弹".

显然，一般观念上认为设备是扇区对齐的，最少是512字节对齐的。

但是g4d中似乎有一种间接的手段，来创建反例的设备。

那就是内存盘。可以是任意字节对齐的。
这种 实际和观念上的 差异， 随时会 丢出 一个 定时炸弹。


F6IMG 之所以 突然 丢出 一个 定时炸弹。
就是她创建了一个这样的  字节 内存盘。

map --mem=0x20000 %~f0 (rd) cat --locate=\x1f\x8b --number=1 (rd)+1 > nul || exit 1 calc *0x82d8=*0x82d8-%?% > nul calc *0x82d0=*0x82d0+%?% > nul map --mem (rd)+1 (1) && map --rehook

0000:82D0  8字节（即四字） rd 设备物理基地址

这里直接修改  rd 设备物理基地址（字节单位）。
由于支持任意字节地址，这样 rd实际上就是 字节内存盘了。
F6IMG中
*0x82d0=0x20000 + 0x147E=0x2147E

就是这个“差异”，丢出的 定时炸弹， 造成 F6IMG没有正常运行。

chenall

mdyblog 发表于 2015-1-14 01:02
目前，还不是“修复”，
而是定位出问题的代码行。

额,思想不太一样..

定位出问题的"代码行",我所谓的定位是具体到哪一行,你只是到哪一段.

那你前面的定位是浪费时间,我前面已经的说过了,就是这里的问题,可能你没有注意看(我前面的一个链接)

chenall

mdyblog 发表于 2015-1-14 04:24
搞定了。

谢谢你的努力.

通过你改动的代码终于发现了问题的原因.就是下面这一句

else if (filepos > blk_buf.cur_filepos)

这是我犯错了,本来是if (filepos > blk_buf.cur_filepos)没有else的,我上次改的时候没有注意看前后代码.

认为前面是

if (filepos < blk_buf.cur_filepos)

再判断

if (filepos > blk_buf.cur_filepos)

有点多余.没仔细看if (filepos < blk_buf.cur_filepos)里面的代码.


你可以测试一下附件看看是否正常.