Re: [uCsimm] about 32-bit PIC

From: Erwin Authried (eauth@softsys.co.at)
Date: Mon Jan 10 2000 - 12:03:14 EST


In your example, the .data section will be too large.
The 32-bit PIC patches don't change the .data+.bss limits.
If you are executing code on a NFS mounted directory,
the current kmalloc complains if the .text segment is larger
than 128k. Thus, the unlimited .text segment is only
available when the application is burned into flash.
I have now modified the gcc patches to use a0 instead
of a4, because a0 may be used in calls without saving anyway.
Thus, the "old" 16-bit PIC may be mixed with 32-bit PIC
without any restriction now, as long as the 16-bit offsets are
not out of range. For my tests, I have left the C library
with 16-bit PIC, the only file that has to be modified is
crt/crt0.s. I removed _cleanup from the crt0.s and added
it as a dummy function at the end of my application.
The "bsr exit" has to be changed to a 32-bit call.
I believe it would be best to make 32-bit PIC a compiler
option for m68k-pic-coff:

-fpic (or no option) for 16-bit PIC, this is used by default now.
-fPIC for 32-bit PIC

Other ideas or suggestions are welcome.

-Erwin

diff -U1 crt/crt0.S.orig crt/crt0.S
--- crt/crt0.S.orig Mon Jan 10 16:01:33 2000
+++ crt/crt0.S Mon Jan 10 16:03:05 2000
@@ -32,3 +32,4 @@
        move.l %d0,%sp@-
- bsr exit /* Invoke exit() routine */
+ lea exit-.-8,%a0
+ jsr 0(%pc,%a0) /* Invoke exit() routine */
 
@@ -45,5 +46,2 @@
 
- .global _cleanup
-_cleanup:
- rts /* nothing to clean up */

diff -U1 config/m68k/m68k.md.orig config/m68k/m68k.md
--- config/m68k/m68k.md.orig Wed Jan 5 13:25:34 2000
+++ config/m68k/m68k.md Mon Jan 10 17:50:57 2000
@@ -810,3 +810,4 @@
   "TARGET_PCREL"
- "lea %a1(%%pc),%0")
+;; 32-bit offset for text seg. load
+ "lea %a1-.-8,%0\;lea 0(%%pc,%0),%0")
 
@@ -5993,3 +5994,3 @@
     else
- return \"bsr.w %0\";
+ return \"lea %0-.-8,%%a0\;jsr 0(%%pc,%%a0)\";
   }
@@ -6066,3 +6067,3 @@
     else
- return \"bsr.w %1\";
+ return \"lea %1-.-8,%%a0\;jsr 0(%%pc,%%a0)\";
   }

권석근[SMTP:kwonsk@mutech.co.kr] wrote:
> 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 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