[uCsimm] about 32-bit PIC

From: 권석근 (kwonsk@mutech.co.kr)
Date: Mon Jan 10 2000 - 03:45:33 EST


hi,
32bit-pic patch was proposed a few days ago by Erwin.
I've tested 32bit-pic patch last night, and got following result.

i compiled libc, crt0, libgcc with 32bit-pic patched compiler.
and test following code (i patched crt0.S with 32bit pic call)

----------------------------------------
/* test.c */
char a[65536] = {
    'h','e','l','l','o',',','w','o','r','l','d',
    [11 ... 65535] = 0; };

main()
{
    printf("%s\n",a);
}
----------------------------------------

Erwin was right of cource, 16bit-pic compiler complained with code size,
and 32bit-pic compiler generated working (excutable) code.
But after compiling another useful app ('rc', another shell from elkscmd),
i found that i still have code limit 128K. it's because kmalloc() at loading
time.
Compiling 'rc' with 32bit-pic was successful, but actually it didn't run on
uCsimm. With some experiences before, I tried add more stack area (it was my
guess) using
coff2flt command, and tried to rerun. At that time, kernel said
"kmalloc of too large a block (...)".
It meant that kernel do not accept app which have "text+bss+data" above
128K.
I retested above (test.c) code with stack size 65536, and got the same
message
from kernel.

And that's all.
My conclusion?
Generally speaking, large code size could be a problem for uCsimm.
Thanks.

BTW, how could i debug my program with gdb on uCsimm?
kwonsk@mutech.co.kr

This message resent by the ucsimm@uclinux.com list server http://www.uClinux.com/



This archive was generated by hypermail 2b30 : Sun Apr 07 2002 - 00:01:33 EST