[Gc] Advise for port to uClinux

Morten Kvistgaard MK at pch-engineering.dk
Fri Nov 5 02:25:06 PST 2010


Ok, the cvs trunk is much easier to compile than the gc72a4. 
But after a lot of testing back and forth with both the gc6.8 and the trunk, I think I'll have to conclude that, it isn't as trivial to port as I hoped. 

I'll post my findings in case someone else takes up the challenge. (I imagine that it would have to be someone with a bit more insight in the Blackfin GNU FLAT compiler, than I.)

The gcconfig.h settings I ended up with, is as follows:
-------------------------------------------------------------------
# ifdef BLACKFIN
#   define CPP_WORDSZ 32
#   define MACH_TYPE "BLACKFIN"
#   define ALIGNMENT 4
#   define OS_TYPE "LINUX"
#   define STACKBOTTOM ((ptr_t) (0x2b4dee4))
#   define USE_GENERIC_PUSH_REGS
#   ifdef __ELF__
#	   include <features.h>
#	   if defined(__GLIBC__) && __GLIBC__ >= 2
#	      define SEARCH_FOR_DATA_START
#	   endif
#   endif
#endif
-------------------------------------------------------------------
I found the stack address through the small code example from gcconfig.h. 

Depending on the libgc version, gctest will either throw a "Null pointer write access" (gc6.8) or a "Data access CPLB miss" (trunk).
I've tried different combinations with stack checking, stack enlarging, mudflap and debugging in the gctest, with no real results. Both exceptions hints that it might be the linking or the compiling that's gone wrong. The gctest is not completely dead though. It can be debugged, run printf etc.

I'll try to present it for the Analog Devices people, I think.


This is the exception output from the trunk version:
-------------------------------------------------------------------
root:~> ./gctest
Data access CPLB miss
<5> - Used by the MMU to signal a CPLB miss on a data access.
Deferred Exception context
CURRENT PROCESS:
COMM=gctest PID=351  CPU=0
TEXT = 0x02a80040-0x02a905c0        DATA = 0x02a905e0-0x02a92f54
 BSS = 0x02a92f54-0x02ab6880  USER-STACK = 0x02ab7f74

return address: [0x02a89b5a]; contents of:
0x02a89b30:  29e4  9111  6408  5208  0a02  102a  e120  0457
0x02a89b40:  4150  e14a  02aa  e10a  7154  3208  5a8a  9150
0x02a89b50:  e14a  02aa  e10a  7298  5e82 [9151] 0c41  1409
0x02a89b60:  3002  6009  e3ff  ff6c  e3ff  d900  3208  2017

ADSP-BF526-0.0(Detected 0.2) 400(MHz CCLK) 80(MHz SCLK) (mpu off)
Linux version 2.6.36-ADI-2011R1-pren (mk at PCHe-Ubuntu) (gcc version 4.3.4 (ADI-trunk/git-7bbb2ed) ) #8 Wed Nov 3 15:08:52 CET 2010

SEQUENCER STATUS:               Not tainted
 SEQSTAT: 00060026  IPEND: 0008  IMASK: ffff  SYSCFG: 0006
  EXCAUSE   : 0x26
  physical IVG3 asserted : <0xffa00760> { _trap + 0x0 }
 RETE: <0x00000000> /* Maybe null pointer? */
 RETN: <0x02b56000> /* kernel dynamic memory */
 RETX: <0x00000480> /* Maybe fixed code section */
 RETS: <0x02a809a6> [ gctest + 0x966 ]
 PC  : <0x02a89b5a> [ gctest + 0x9b1a ]
DCPLB_FAULT_ADDR: <0x0d547e58> /* unconnected memory */
ICPLB_FAULT_ADDR: <0x02a89b5a> [ gctest + 0x9b1a ]
PROCESSOR STATE:
 R0 : 0000117c    R1 : 00000000    R2 : 00000008    R3 : 02aa980c
 R4 : 02b71f30    R5 : 00001194    R6 : 00000000    R7 : 000007d4
 P0 : 02aa82f0    P1 : 0000117c    P2 : 0d547e58    P3 : 02b71f00
 P4 : 02aa6b64    P5 : 02aa7028    FP : 02aa82a0    SP : 02b55f24
 LB0: 02a8d4e5    LT0: 02a8d4e4    LC0: 00000000
 LB1: 02a89523    LT1: 02a89518    LC1: 00000000
 B0 : 00000000    L0 : 00000000    M0 : 00003564    I0 : 02b85000
 B1 : 00000000    L1 : 00000000    M1 : 00000000    I1 : 02aa687c
 B2 : 00000000    L2 : 00000000    M2 : 00000000    I2 : 00000000
 B3 : 00000000    L3 : 00000000    M3 : 00000000    I3 : 00000000
A0.w: 00000000   A0.x: 00000000   A1.w: 00000000   A1.x: 00000000
USP : 02aa8294  ASTAT: 02000020

Hardware Trace:
   0 Target : <0x00003f14> { _trap_c + 0x0 }
     Source : <0xffa006f4> { _exception_to_level5 + 0xa4 } JUMP.L
   1 Target : <0xffa00650> { _exception_to_level5 + 0x0 }
     Source : <0xffa00504> { _bfin_return_from_exception + 0x18 } RTX
   2 Target : <0xffa004ec> { _bfin_return_from_exception + 0x0 }
     Source : <0xffa005a8> { _ex_trap_c + 0x74 } JUMP.S
   3 Target : <0xffa00418> { _ex_dcplb_miss + 0x0 }
     Source : <0xffa007ba> { _trap + 0x5a } JUMP (P4)
   4 Target : <0xffa00760> { _trap + 0x0 }
      FAULT : <0x02a89b5a> [ gctest + 0x9b1a ] P1 = [P2]
     Source : <0x02a89b58> [ gctest + 0x9b18 ] 0x5e82
   5 Target : <0x02a89b3c> [ gctest + 0x9afc ]
     Source : <0x02a89b28> [ gctest + 0x9ae8 ] IF CC JUMP pcrel (BP)
   6 Target : <0x02a89b1c> [ gctest + 0x9adc ]
     Source : <0x02a809a2> [ gctest + 0x962 ] JUMP.L
   7 Target : <0x02a80988> [ gctest + 0x948 ]
     Source : <0x02a80a14> [ gctest + 0x9d4 ] CALL pcrel
   8 Target : <0x02a80a12> [ gctest + 0x9d2 ]
     Source : <0x02a80a0c> [ gctest + 0x9cc ] IF CC JUMP pcrel
   9 Target : <0x02a80a00> [ gctest + 0x9c0 ]
     Source : <0x02a80a20> [ gctest + 0x9e0 ] CALL pcrel
  10 Target : <0x02a80a18> [ gctest + 0x9d8 ]
     Source : <0x02a809c8> [ gctest + 0x988 ] RTS
  11 Target : <0x02a809be> [ gctest + 0x97e ]
     Source : <0x02a809aa> [ gctest + 0x96a ] IF !CC JUMP pcrel (BP)
  12 Target : <0x02a809a6> [ gctest + 0x966 ]
     Source : <0x02a89ba2> [ gctest + 0x9b62 ] RTS
  13 Target : <0x02a89b9c> [ gctest + 0x9b5c ]
     Source : <0x02a89b8c> [ gctest + 0x9b4c ] JUMP.S
  14 Target : <0x02a89b70> [ gctest + 0x9b30 ]
     Source : <0x02a89b5e> [ gctest + 0x9b1e ] IF !CC JUMP pcrel (BP)
  15 Target : <0x02a89b3c> [ gctest + 0x9afc ]
     Source : <0x02a89b28> [ gctest + 0x9ae8 ] IF CC JUMP pcrel (BP)
Userspace Stack
Stack info:
 SP: [0x02aa8294] <0x02aa8294> [ gctest + 0x28294 ]
 Memory from 0x02aa8290 to 02aa9000
02aa8290: 00000000 [00000000] 00000000  00000000  02aa82b4  02a809a6  00000438  00010fa0
...
Return addresses in stack:
    address : <0x00001194> { _init_post + 0x8 }
    ...
BUS
-------------------------------------------------------------------
(Only slightly shorted)

Regards
Morten Kvistgaard

-----Original Message-----
From: Ivan Maidanski [mailto:ivmai at mail.ru] 
Sent: 4. november 2010 16:21
To: Morten Kvistgaard
Cc: gc at linux.hpl.hp.com
Subject: Re[2]: [Gc] Advise for port to uClinux

Hi, Morten!

Two advices:
1. instead of gc72a4, start with the current CVS snapshot (just not to run into a bug already solved).
2. first try to create the port for the single-threaded mode, then try to compile libatomic_ops, and then start porting GC for the multi-threaded mode.

Thu, 4 Nov 2010 16:02:36 +0100 Morten Kvistgaard <MK at pch-engineering.dk>:

> I forgot to tell that I was using the gc6.8. (stable version) That one
> hasn't got any __UCLIBC__. But it's in the gc7.2alpha4 I see, so
> I'll give that one a try.
> 
> The gc7.2alpha4 is more difficult to compile though. The build_atomic_ops.sh
> is causing me trouble. (I'm using the Makefile.Direct) It nags about not
> being meant for cross compiling... I'll give it another shot tomorrow
> though.
> 
> 
> Regards
> Morten Kvistgaard
> 
> -----Original Message-----
> From: Ivan Maidanski [mailto:ivmai at mail.ru] 
> Sent: 4. november 2010 14:55
> To: Morten Kvistgaard
> Cc: gc at linux.hpl.hp.com
> Subject: Re: [Gc] Advise for port to uClinux
> 
> Hi!
> 
> GC_HAVE_BUILTIN_BACKTRACE is not defined if __UCLIBC__.
> It looks like __UCLIBC__ is not defined in your system. Could you check this?
> 
> Fri, 5 Nov 2010 00:39:36 +1300 Bruce Hoult <bruce at hoult.org>:
> 
> > Hi!
> > 
> > I don't quite understand why you have an #ifdef LINUX inside the
> > #ifdef BLACKFIN, which is only defined if LINUX is defined. Still, it
> > won't hurt.
> > 
> > STACK_GRAN 0x10000000 (256 MB) seems absurdly big if this is an
> > embedded system. It also is I think only used if HEURISTIC1 is
> > defined, which you're not doing there.
> > 
> > Does this system have a fixed address for the bottom of the stack? If
> > so then just define STACKBOTTOM directly.
> > 
> > Read the comments relating to these definitions at the start of
> gcconfig.h
> > 
> > 
> > You may want to write a little C program that prints out the address
> > (in HEX) of a local variable in main(). That may well be enough to
> > figure out that the bottom of the stack can be found by rounding that
> > address up to the next 1k or 4k or 16k or something like that.
> > 
> > Alternatively, use a dummy and real main program as in the example
> > code just below there in gcconfig.h.
> > 
> > Getting this right -- or at least plausible -- is one of *the* main
> > things in porting to a new OS. (finding, starting and stopping
> > threads, if any and finding their stacks is the other one)
> > _______________________________________________
> > Gc mailing list
> > Gc at linux.hpl.hp.com
> > http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
> 
> 
> Thu, 4 Nov 2010 12:20:05 +0100 Morten Kvistgaard
> <MK at pch-engineering.dk>:
> 
> > Hello there,
> > 
> > I seek some advise. I'm trying to port the libgc to uClinux, which is
> > running on my Blackfin. And I almost have it running!
> > 
> > A little background:
> > - The GNU compiler for uClinux are using uclibc, which is a subset of
> glibc. 
> > - Blackfins have no MMU, so it doesn't like dynamic linking and it
> > doesn't like fork
> > - It do like POSIX threads though. (And just about everything else that
> has a
> > POSIX smell)
> > - Generally it looks a feels very much like a regular Linux. (The newest
> > version at least.) So it shouldn't be that difficult to port to I
> think.
> > 
> > Here's what I've done:
> > 
> > I've inserted the following in gcconfig.h:
> > --------------------------------------------------------------
> > # if defined(LINUX) && defined(__bfin__)
> > #    define BLACKFIN
> > #    define mach_type_known
> > # endif
> > 
> > ...
> > 
> > # ifdef BLACKFIN
> > #   define CPP_WORDSZ 32
> > #   define MACH_TYPE "BLACKFIN"
> > #   define ALIGNMENT 4
> > #   ifdef LINUX
> > #       define OS_TYPE "LINUX"
> > #       define LINUX_STACKBOTTOM
> > #       undef STACK_GRAN
> > #       define STACK_GRAN 0x10000000
> > #       define USE_GENERIC_PUSH_REGS
> > #       ifdef __ELF__
> > #	         include <features.h>
> > #	         if defined(__GLIBC__) && __GLIBC__ >= 2
> > #		        define SEARCH_FOR_DATA_START
> > #	         endif
> > #       endif
> > #   endif
> > #endif
> > --------------------------------------------------------------
> > (__GLIBC__ is still defined in uclibc)
> > 
> > 
> > 
> > I've also *undefined* GC_HAVE_BUILTIN_BACKTRACE in gc.h, due to the
> > following statement in op_deb.c:
> > --------------------------------------------------------------
> > #if defined(GC_HAVE_BUILTIN_BACKTRACE)
> > # include <execinfo.h>
> > #endif
> > --------------------------------------------------------------
> > uclibc doesn't have that one. (Unlike glibc)
> > 
> > 
> > 
> > I've also inserted the right compiler and host compiler in the
> makefile
> > and it compiles just fine! 
> > But when I run the gctest on target it says:
> > --------------------------------------------------------------
> > root:~> ./gctest
> > Absurd stack bottom value
> > ABRT
> > --------------------------------------------------------------
> > (This seems to be output from the op_deb.c)
> > 
> > 
> > 
> > Basically I have no idea what I'm doing, my alterations are just
> guessing,
> > based on the libgc documentation. I've copied the "ifdef
> > BLACKFIN" section from the "ARM" actually. But it seems so
> > close! Can anyone give some advice on how to fix it? Is it wrong to
> remove the
> > GC_HAVE_BUILTIN_BACKTRACE? Do the "ifdef BLACKFIN" section
> looks ok?
> > 
> > Regards
> > Morten Kvistgaard




More information about the Gc mailing list