Re[4]: [Gc] Advise for port to uClinux

Ivan Maidanski ivmai at mail.ru
Fri Nov 5 06:59:52 PST 2010


Hi, Morten!

Fri, 5 Nov 2010 11:25:06 +0100 Morten Kvistgaard <MK at pch-engineering.dk>:

> Ok, the cvs trunk is much easier to compile than the gc72a4. 

Hans -

gc72a4 was released 11 months ago and a lot of changes has been done since. It might worth build another alpha release. (Though, I think Darwin platform should be tested more thoroughly before the release.) Again, I could prepare the tarballs once you decide it's time to.


> 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__

Is __ELF__ defined for your target or not? If it permanently yes, why not to exclude 'ifdef' for simplicity.

> #	   include <features.h>
> #	   if defined(__GLIBC__) && __GLIBC__ >= 2
> #	      define SEARCH_FOR_DATA_START

Again, it is unclear whether SEARCH_FOR_DATA_START is on.

> #	   endif
> #   endif
> #endif
> -------------------------------------------------------------------
> I found the stack address through the small code example from gcconfig.h. 

You mean this one, right?
 *              # include "gc_private.h"
 *
 *              main(argc, argv, envp)
 *              int argc;
 *              char **argv, **envp;
 *              {
 *                  int dummy;
 *
 *                  GC_stackbottom = (ptr_t)(&dummy);
 *                  return(real_main(argc, argv, envp));
 *              }

Do you think the stack bottom is always the same? Otherwise, you shouldn't hard-code it (except, may be, temporarily).

> 
> Depending on the libgc version, gctest will either throw a "Null pointer
> write access" (gc6.8) or a "Data access CPLB miss" (trunk).

I think the problem might be because of SEARCH_FOR_DATA_START defined.
Check the platform specs - it might turn out that DATASTART/DATAEND could be defined to some symbols (like _etext, _end).

Regards.

> 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
> 
> 
> _______________________________________________
> Gc mailing list
> Gc at linux.hpl.hp.com
> http://www.hpl.hp.com/hosted/linux/mail-archives/gc/



More information about the Gc mailing list