支持含有碎片的文件仿真

mdyblog

不点 发表于 2014-12-21 08:46
抱歉，我眼睛花了，以为是 --mem 呢。

莫非是 0.4.6 的 bug？请确认一下，0.4.5 有这样的问题吗？

再测其他版本，找到最近的版本。

0.46a20121231： 12秒和 0.45C一样。看来 2012.1231此时已经有问题了。

mdyblog

不点 发表于 2014-12-21 08:46
抱歉，我眼睛花了，以为是 --mem 呢。

莫非是 0.4.6 的 bug？请确认一下，0.4.5 有这样的问题吗？

0.46a20120101:  3秒

mdyblog

不点 发表于 2014-12-21 08:46
抱歉，我眼睛花了，以为是 --mem 呢。

莫非是 0.4.6 的 bug？请确认一下，0.4.5 有这样的问题吗？

找到0.46a变慢的相邻2个版本了。
0227: 测3次，依次： 2秒  2秒  3秒

0324: 14秒



0.45C也是这个日期对应的2版本。

不点

相关的改动都看了，没有发现问题。看来问题很隐蔽。也许 chenall 能弄清楚。

你可用 debug on 打开调试输出，然后看究竟哪个地方最耗时。

你也可以自己编译带调试输出的版本，确定哪个地方执行最慢。从 map_func 函数开始，找最耗时的语句。

mdyblog

不点 发表于 2014-12-21 16:54
相关的改动都看了，没有发现问题。看来问题很隐蔽。也许 chenall 能弄清楚。

你可用 debug on 打开调试 ...

debug on 如图： 好像没有什么东西。

不点

那你自己在 map_func 里面插入输出语句，判定哪个地方最耗时。

mdyblog

不点 发表于 2014-12-21 18:02
那你自己在 map_func 里面插入输出语句，判定哪个地方最耗时。

前面不是找出来了吗？还用找吗？
当然各人的思想方法不同。
我是用的"中华思想文化"，而不是西方“菲罗教”(philosophy),是 “实干家”。
已经定位到0.45C120227（0.46a）正确，
                   0.45C120322（0.46a-0324）不正确，
问题和那几行改变的代码有关。
对 “实干家”， 代码写对了，就好了，至于背后的一堆“真理/原理”，毫不在意。“为什么会慢，也毫不在意——只要消除了即可。”
从那几行“改变的代码”出发，就可以了。

如果没有上面我提供的精确信息，可以依据原理，尝试从 map_func 出发，大海捞针。
现在有了上面我提供的精确信息，完全可以直接从 那几行“改变的代码”出发， “精确制导”。

对我中华“实干家”，来说，现在问题已经定位，就剩C大付诸实行了。


说话不周，请海涵！

不点

mdyblog 发表于 2014-12-22 08:02
前面不是找出来了吗？还用找吗？
当然各人的思想方法不同。
我是用的"中华思想文化"，而不是西方“菲 ...

你大概没注意，我说过，我看不出那几天的改动哪里有错。因此，才需要你来找。

那你再等待 chenall 等人的消息吧，看看他们能否找到毛病。

万一他们也找不到毛病，那大概只能你自己找了。

mdyblog

不点 发表于 2014-12-22 08:32
你大概没注意，我说过，我看不出那几天的改动哪里有错。因此，才需要你来找。

那你再等待 chenall 等 ...

》》你大概没注意，我说过，我看不出那几天的改动哪里有错。因此，才需要你来找。
没找出来也无所谓。
只要代码对了就可以。 程序中很多问题都是，不知道为什么，就已经消除了，尤其是这种和硬件打交道的情况——不纠缠了。

大不了， 将 20120322的更改撤销掉。

不点

该怎么办，由 chenall、yaya 来处理吧。这期间有至少两次改动，比较麻烦。其一，我看不出改动有任何毛病。其二，其实我也看不太懂改动的内容。所以，我不再参与这个事情。

以下我向 chenall 、yaya 谈谈我的想法。

莫非又是编译器问题？或者是主板 BIOS 适应性问题？这两个问题都很头痛，我们也都碰上过。编译器问题由 Roy 做了很多的工作才给以解决，如今不知道是否彻底解决了。而有些 BIOS 就可能发生莫名其妙的问题，我们也碰到过大量的实例。先从代码上找问题，如果确认代码没错，那就可能是编译器问题和 BIOS 适应性问题了。

chenall

我也是试了没有找到原因,而且我这里测试速度没有多大变化呀.

你可以测试一下这三个重新编译的(对应那一时间段的版本).

2011yaya2007777

0.46a  2012-02-27 至 2012-03-24 有 3 个补丁。似乎与读磁盘无关。
请 mdyblog 在其他电脑测试一下，状况是否一样，以便排除主板 BIOS 适应性问题。

编译器问题确实头痛。最近排除 issues 199 的问题，反编译了 grldr，明显发现有编译错的时候。
比如 C 代码是：

1. if (name_len == 1)  //如果名称长度=1
   
2. {
   
3. if ((name[0] == 0) ||       /* self 自己*/
   
4. (name[0] == 1))            /* parent 父级*/
   
5. goto ssss;
   
6. }
   
7. if (iso_type == 2)
   
8. {

复制代码

编译后是：

1. ;if (name_len == 1)
   
2. ;{
   
3. :0002E488 83FE01                  cmp esi, 00000001                 ;name_len=1?
   
4. :0002E48B 7514                    jne 0002E4A1                                       
   
5. ;if ((name[0] == 0) || (name[0] == 1))
   
6. ;{
   
7. :0002E48D 8B8DF0FDFFFF            mov ecx, dword ptr [ebp+FFFFFDF0] ;name
   
8. :0002E493 803901                  cmp byte ptr [ecx], 01              ;name[0] > 1?
   
9. :0002E496 0F87AD040000            ja 0002E949                       ;是                错误!!!!!!!!
   
10. :0002E49C E9FA030000              jmp 0002E89B                      ;name[0]=0 或 name[0]=1  转到 ssss
    
11. ;}
    
12. 
    
13. :0002E949 83F802                  cmp eax, 00000002                 ;iso_type=2?
    
14. :0002E94C 0F85B7FBFFFF            jne 0002E509                     ;不是                错误!!!!!!!!!!!!!!!!!!!!!!!
    
15. :0002E952 E94FFBFFFF              jmp 0002E4A6                     ;是
    
16. 
    
17. ;if (iso_type == 2)
    
18. ;{
    
19. :0002E4A1 83F802                  cmp eax, 00000002                ;iso_type=2?
    
20. :0002E4A4 7535                    jne 0002E4DB                                ;不是
    
21. ;big_to_little (name, name_len);
    
22. :0002E4A6 8B9DF0FDFFFF            mov ebx, dword ptr [ebp+FFFFFDF0]        ;name

复制代码

chenall

2011yaya2007777 发表于 2014-12-22 11:56
0.46a  2012-02-27 至 2012-03-24 有 3 个补丁。似乎与读磁盘无关。
请 mdyblog 在其他电脑测试一下，状况 ...

嗯,编译器自动优化确实是个问题,我也碰到过多次,代码没有问题,编译出来的有问题.

只好在代码里面换一种写法,才得以解决.

mdyblog

chenall 发表于 2014-12-22 12:33
嗯,编译器自动优化确实是个问题,我也碰到过多次,代码没有问题,编译出来的有问题.

只好在代码里面换一 ...

不要用O2
-O就可以了。
有些gcc的O2有问题。

mdyblog

chenall 发表于 2014-12-22 11:51
我也是试了没有找到原因,而且我这里测试速度没有多大变化呀.

你可以测试一下这三个重新编译的(对应那一 ...

grldr0.4.5c-cd5e107： 3秒
能不能在0.46a上改啊？

mdyblog

chenall 发表于 2014-12-22 11:51
我也是试了没有找到原因,而且我这里测试速度没有多大变化呀.

你可以测试一下这三个重新编译的(对应那一 ...

grldr0.4.5c-a6bfd1a： 11秒----慢

mdyblog

chenall 发表于 2014-12-22 11:51
我也是试了没有找到原因,而且我这里测试速度没有多大变化呀.

你可以测试一下这三个重新编译的(对应那一 ...

grldr0.4.5c-a1cbe95： 11秒--慢

mdyblog

chenall 发表于 2014-12-22 11:51
我也是试了没有找到原因,而且我这里测试速度没有多大变化呀.

你可以测试一下这三个重新编译的(对应那一 ...

》》而且我这里测试速度没有多大变化呀.
需要测试的分区足够大，才能体现这种速度差异。
找个>=10G的系统分区（win7,win8更好）试试。

mdyblog

不点 发表于 2014-12-22 10:44
该怎么办，由 chenall、yaya 来处理吧。这期间有至少两次改动，比较麻烦。其一，我看不出改动有任何毛病。 ...

下面是换台稍新店的笔记本电脑（大概11年的）
性能高点的SATA本地硬盘。
测试的是80G的win7X64分区。

因为分区是原来的8倍，但盘子性能好点，时间普遍是原来的5倍！


随大小而增长。这个不应该。看来主要是的算法问题。
是不是哪儿多了个和大小相关的循环。

grub0.45b2011714无法运行在该电脑上，无法测试。

chenall

那就是a6bfd1a这个版本开始出现的问题了..可是这个里面没有改动任何磁盘读写的代码,,不到找原因.

估计也是和编译有关,只能尽量查找原因了.

不点

恶心人的 gcc，给我们造成了很多的问题。

看来最可靠的是汇编了，这不太容易出错。

gcc 除了开发者失误的可能性以外，还可能遭到间谍的攻击了。

mdyblog

chenall 发表于 2014-12-22 16:07
那就是a6bfd1a这个版本开始出现的问题了..可是这个里面没有改动任何磁盘读写的代码,,不到找原因.

估计也 ...

找原因，比解决问题更复杂， 尤其是这种嵌入式开发（或者说和硬件打交道，什么稀奇，什么地方都会出现）。

（根据我的经验）我建议，（绕开原因）直接从前面那个正确的版本出发，编译环境什么都不改。
再一点一点地， 将后面版本的代码移过去，每次尽量少移，移一次，测试一下；直到重要的代码都移过去了，还是正确的。就行了。
（至于找原因，那是权当个人兴趣，有空才特地去找。 说不定上面“顺便”就找的差不多了）

mdyblog

不点 发表于 2014-12-22 16:26
恶心人的 gcc，给我们造成了很多的问题。

看来最可靠的是汇编了，这不太容易出错。

》》gcc 除了开发者失误的可能性以外，还可能遭到间谍的攻击了。
免费的东西，也不要要求太高。

质量、稳定性和可靠性，是银子堆出来的。
况且gcc这么复杂的系统。
在这个急剧变化的时代，尤其如此。
人家免费，没有收入。
很多工作没有保证。



-----------
容易出问题，主要是使用环境引起的——嵌入式。
这种环境，大部分编译器都会出问题。

最容易出的问题是堆栈溢出。这个时候非常奇怪，换个（逻辑完全等效的）写法问题就没了。

我用摩托诺拉的编译器，也是这样，奇奇怪怪。 一个简单的整数除法，竟然会出问题，看代码根本看不出问题——代码逻辑根本没错。
最后反汇编才找出编译原因。

chenall

mdyblog 发表于 2014-12-22 17:11
找原因，比解决问题更复杂， 尤其是这种嵌入式开发（或者说和硬件打交道，什么稀奇，什么地方都会出现 ...

我一直都是这样做的,^_^.

目前初步定到到了cmdline.c文件的问题,具体什么代码的问题明天再继续.

chenall

这个问题看起来很难解决了.

-        char cmdline_buf[1500];
+        char *cmdline_buf = cmd_buffer;

使用 cmdline_buf[1500];时就是旧版的,不过当时记得就是由于这样子有问题(好像char cmdline_buf[N],这个N不能大于512否则会出错).

如果每一行命令都比较短则改成cmdline_buf[512];就行了(这个还是要变量扩展后的长度).不过目前加上变量扩展等,还有命令重定向等,超过512是很常见的.

不知还有没有其它的解决方法?我也尝试过用malloc来分配内存也是一样的效果,真的是很奇怪.

不点

找到地方，就是很大的成绩。

以后我们可以慢慢解决这一问题。

我觉得这些代码需要严格锤炼。

等我有时间的话，我会专门寻找代码的逻辑漏洞。

目前你可以暂时使用 char cmdline_buf[1500]; 看看会暴露出什么问题。

如果暴露出问题，再去解决。

mdyblog

chenall 发表于 2014-12-23 11:16
这个问题看起来很难解决了.

-        char cmdline_buf[1500];

char cmdline_buf[1500];
这样可能会引起堆栈溢出。
嵌入式开发，最容易出现 堆栈溢出——内存太少，初始化的堆栈一般都很小，很容易溢出。

堆栈溢出，大部分马上死翘翘。
但是， 也有的 没有 马上死， 而是”改变了不改改变的内存“，造成 ”奇奇怪怪“ 的问题。

嵌入式开发 中， 经历避免使用大的临时数组——他们使用的是堆栈。


---
》》很难解决了.
可以定义成非临时变量。
法1） 放在函数外。 就是全局的了。
char cmdline_buf[1500];
void ABC()
{
}
这样， 函数返回后，别的函数还可临时用一下这个数据。
法2） 前面加上static 放在函数内。 就是静态持久的了。
void ABC()
{
        static char cmdline_buf[1500];
}


不是临时变量，这样用的就不是堆栈，就没问题。
不是临时变量， 这段内存始终不会释放。是专用内存。

//反正，看样子， 这个数组不是偶尔才用，变成了事实上的专用内存


》》》》
不知还有没有其它的解决方法?我也尝试过用malloc来分配内存也是一样的效果,真的是很奇怪.
试试这样：

1. static char cmdline_buf0[512+16+1500+512];
   
2. char *cmdline_buf=&cmdline_buf0[512];
   
3. cmdline_buf  +=  (~(int)cmdline_buf)&0x0F;
   
4. cmdline_buf[0]  = 0;
   

复制代码

chenall

mdyblog 发表于 2014-12-23 13:31
char cmdline_buf[1500];
这样可能会引起堆栈溢出。
嵌入式开发，最容易出现 堆栈溢出——内存太少， ...

使用char cmdline_buf[1500]是旧版本的(也就是速度比较快的)

新的版本是使用专用内存块的.

另外这一个内存必须是这个函数专用的,并且每次运行该函数使用内存都不应该一样..
因为这个函数里面的命令会再次调用这个函数,如果内存块一样的话就会出问题的.

所以上面的方法是没用的.

mdyblog

chenall 发表于 2014-12-23 14:52
使用char cmdline_buf[1500]是旧版本的(也就是速度比较快的)

新的版本是使用专用内存块的.

>>因为这个函数里面的命令会再次调用这个函数,
你是说，会嵌套调用自己？

不点

chenall 发表于 2014-12-23 14:52
使用char cmdline_buf[1500]是旧版本的(也就是速度比较快的)

新的版本是使用专用内存块的.

这样就有溢出的可能了。反复调用这个函数，会导致内存消耗变大，这样就容易间接造成内存冲突。