Advise for port to uClinux

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

Re: Advise for port to uClinux

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)

Re: 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@...>:

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

Re[2]: 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@...>:

> 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@...] 
> Sent: 4. november 2010 14:55
> To: Morten Kvistgaard
> Cc: gc@...
> Subject: Re: [Gc] Advise for port to uClinux
> 
> Hi!

Re[2]: [patch] fix darwin build

Hi, Andreas!

Not a problem. Thanks.

Regards.

PS. AICS on http://ecls.sourceforge.net/logs_gc.html, Debian/x64 is being built every night (unlike
Darwin, Solaris and others) - thanks to Juan Jose Garcia-Ripoll.

Thu, 28 Oct 2010 21:30:46 +0200 Andreas Tobler <andreast-list@...>:

> Hi Ivan,
> 
> On 25.10.10 22:07, Ivan Maidanski wrote:
> 
> > I've modified the darwin port significantly recently. As I have
> > little access to Mac OS X environment, I'd like you (as well as the
> > rest of the community volunteers) to participate in testing, if
> > possible.
> >
> > Besides the default build configuration, the following is of interest
> > to compile with: 1. -Wall (and feed any produced warning messages to
> > this list); 3. -D GC_NO_THREADS_DISCOVERY [--enable-gc-assertions]
> > -Wall 3. -D GC_NO_THREADS_DISCOVERY --enable-parallel-mark
> > [--enable-gc-assertions] -Wall 4. -D GC_NO_THREADS_DISCOVERY -D
> > DARWIN_DONT_PARSE_STACK -Wall 5. -D GC_DISCOVER_TASK_THREADS -Wall 6.
> > -D GC_DISCOVER_TASK_THREADS --enable-parallel-mark
> > [--enable-gc-assertions] -Wall 7. -D GC_DISCOVER_TASK_THREADS -D
> > DARWIN_DONT_PARSE_STACK -Wall
> 

RE: Re[2]: Advise for port to uClinux

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

Re[4]: Advise for port to uClinux

Hi, Morten!

Fri, 5 Nov 2010 11:25:06 +0100 Morten Kvistgaard <MK@...>:

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

Callbacks for GC events.

Hi,

I've written a patch against BoehmGC (attached) that introduces callbacks that
the GC calls for certain events.  I'm interested in the following events:

    + Collection begins
    + Collection ends
    + This thread is stopping (because the world is stopping).
    + This thread is resuming (because the world is resuming).

I use this for profiling the execution of multicore programs, these events
along with events from Mercury's[1] runtime can be used to generate a
visualisation of a program's execution.  The visualisation is rendered can be
be explored with the ThreadScope[2] tool.

I have two questions:

    1. Can somebody please commit this into BoehmGC's CVS repository so that it
       can be maintained by people who know the garbage collector better than I
       do?

    2. Have I correctly instrumented the collector?  I understand that my patch
       only supports the pthread method of stopping the world, I'm okay with
       that.  However, I'm not confident that I've instrumented all the places
       where the collector switches from allocation to collection mode and back
       again.  I've had to be careful not to make the collector send two 'start
       collection' events in a row for example.

1. Mercury: http://www.mercury.csse.unimelb.edu.au

Re: Callbacks for GC events.

Hi, Paul!

1. Of course, we could commit the patch (if no objections for the community) but we need time for the review.
2. For collection begin, there is already GC_set_start_callback. Is this the same as your or not? (I
haven't looked into code yet.)
3. As I recall, mono's port of GC has similar functionality. Could you investigate this and produce the
patch adding the functionality you need but having the same API for it as in mono?

Regards.

Mon, 8 Nov 2010 14:47:07 +1100 Paul Bonet <pbone@...>:

> 
> Hi,
> 
> I've written a patch against BoehmGC (attached) that introduces callbacks
> that
> the GC calls for certain events.  I'm interested in the following events:
> 
>     + Collection begins
>     + Collection ends
>     + This thread is stopping (because the world is stopping).
>     + This thread is resuming (because the world is resuming).
> 
> I use this for profiling the execution of multicore programs, these events
> along with events from Mercury's[1] runtime can be used to generate a
> visualisation of a program's execution.  The visualisation is rendered can
> be
> be explored with the ThreadScope[2] tool.
> 

Re: Callbacks for GC events.

On Mon, Nov 08, 2010 at 11:00:57PM +0300, Ivan Maidanski wrote:
> Hi, Paul!
> 
> 1. Of course, we could commit the patch (if no objections for the community)
> but we need time for the review.

Is there anything I should do to start this process?  Do I have to submit the
patch to a special place?

> 2. For collection begin, there is already GC_set_start_callback. Is this the
> same as your or not? (I haven't looked into code yet.

> 3. As I recall, mono's port of GC has similar functionality. Could you
> investigate this and produce the patch adding the functionality you need but
> having the same API for it as in mono?

I'll look at these points in the next week or so.

Thanks.

_______________________________________________
Gc mailing list
Gc@...
http://www.hpl.hp.com/hosted/linux/mail-archives/gc/