harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Rogers <ian.rog...@manchester.ac.uk>
Subject Re: porting portlib
Date Sun, 28 Jun 2009 21:58:28 GMT
2009/6/28 Mark Hindess <mark.hindess@googlemail.com>:
> 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.

Just to note that MRP [1] uses the portlib threading code in Harmony,
it'd be nice if it worked on OS/X so thanks for your efforts Nathan.
As a consequence of using the portlib code although MRP runs on x86_64
with GNU Classpath it won't with Harmony (I've not test MRP with
Harmony x86_64 on Windows). It'd be nice if this was fixed. It'd also
be nice if there were a portable signal/stack/thread solution as a
package, I ran into various rat holes when doing this porting work for
MRP. I can provide the gory details if someone is interested in doing
the implementation work.


[1] http://mrp.codehaus.org/

View raw message