porting portlib

[Nathan Beyer <nd...@apache.org>]

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.

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.

-Nathan

Re: porting portlib

[Ian Rogers <ia...@manchester.ac.uk>]

2009/6/28 Mark Hindess <ma...@googlemail.com>:
>
> In message <3b...@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.

Regards,
Ian

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

Re: porting portlib

[Sean Qiu <se...@gmail.com>]

Do we have an IBM VME for OS X? :-)

Best Regards
Sean, Xiao Xia Qiu




2009/6/29 Mark Hindess <ma...@googlemail.com>:
>
> In message <3b...@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.
>
>
>

Re: porting portlib

[Mark Hindess <ma...@googlemail.com>]

In message <3b...@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.