[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