harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Hindess <mark.hind...@googlemail.com>
Subject Re: porting portlib
Date Sun, 28 Jun 2009 21:38:42 GMT

In message <3b3f27c60906280859m350545bdg899c85e77c96d9ec@mail.gmail.com>,
Nathan Beyer writes:
>
> I've been playing around trying to port the portlib cod to run on
> Mac OS X 10.5. I've been futzing around with the assembly file in
> 'thread', specifically 'thrhelp.s' and 'thrspinlock.s'. I've been
> trying to find the lowest common denominator to work on Linux an OS X,
> but I've finally come to the conclusion that it's just not going to
> happen. Although most of the actual code - the implementations of the
> method are directly portable, the small stuff around it just doesn't
> work.
>
> The main issue revolves around leading underscores being added
> to function names. Apparently, this isn't the default behaviour
> for Linux, but it is on OS X - even though I'm using gcc and gas
> in both case. As such, the function names in the assembly files
> need to be different based on the OS. I've tried fiddling with the
> '-fno-leading-underscores' flag, but this blows up other stuff and
> just seems to be a rat hole.

Nathan, you are running down the wrong rat hole.

DRLVM doesn't use the threading code in classlib so fixing it is futile.
DRLVM provides its own libhythr.so - using the src in vm/thread/src.

I've never understood why we have a hy.thr.nodeploy option for the
classlib thread code.  If we aren't going to deploy it, why are we
building it?

(Aside: the originally contributed assembler code in classlib for
linux/x86 works but the later, Intel-contributed assembler code for
linux/x86_64 links but does not actually work in practice.)

> At this point, I think it's time to give up on the os.family + os.arch
> separation and change to os.name + os.arch or something else? Any
> thoughts or suggestions on such a change? I'm curious how this stuff
> works on the other unix platforms, such as AIX and BSD.

Well, the IBM VME for Aix uses the -Dhy.no.thr=true option so the
classlib threading code is not used.  But when I last tested it the
assembler code for x86 worked on FreeBSD.  However, this wouldn't stop
us splitting the code by os.name, we'd just use #include's to share
implementation where possible - much like we do with the hymmap.c code.

Regards,
 Mark.



Mime
View raw message