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