/usr/bin/ld: cannot find -l* 错误的解决方法……

Clean up two old blogs, which was edited in opera (the edit box was so small). In firefox, I can review these blogs easily, and some clean up done.

NASM 0.99.01 was buggy for the 32bit/16bit codegen. When an instruction which access register and mem, it would be generated with 0x67 prefix for a 16bit segment. This blocks the elf2 bootsect, which has size limitation, extra 0x67 makes the code bloated, so the compilation breaks.

I did a quick hack, and posted the new compiled binary to the ReactOS Build Environment maintainer. Also I filed it as a bug, though the nasm64developer told me that this couldn't be reproduced in 0.99.02 CVS snapshot. O_O , after a try , yes, it's already fixed. ;) so my hacking over nasm is useless.

Though another thing interesting is spotted about GDB. GDB itself is a nice debugger. But...

c 代码

 

#include "stdio.h"  

void __stdcall call()  

{  

    printf("hello!");  

}  

void main()  

{  

    call();  

}  

when you try to

gdb下调试

b call  

gdb fails.

This is the reason why gdb couldn't get all symbols work in Kernel Debugging.

Remarks:

__stdcall __fastcall are calling convention in Windows, they both add @ to the mangled name, seems like gdb fail to deal with mangle name with '@'

mangle name(link time symbol):

c mangle convention: underscore prefix, so every C symbols in asm would be prefixed with an underscore.

so a typical link with ASM files would be

test.c

c 代码

 

extern int myasmSymbol;    

int main()    

{    

      return myasmSymbol;    

}    

myasm.S

asm 代码

 

.text  

.global _myasmSymbol  

_myasmSymbol: .int 0   

gcc -c myasm.S

gcc -c test.c

gcc test.o myasm.o -o test.exe