harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexey Varlamov" <alexey.v.varla...@gmail.com>
Subject Re: [drlvm] Supporting more platforms
Date Fri, 18 May 2007 09:51:29 GMT
It's really nice to see you finally approaching drlvm! :)
More inlined...

2007/5/18, Mark Hindess <mark.hindess@googlemail.com>:
> I'm looking at what would need to be changed in drlvm to support more
> platforms.  (Specifically, I'm looking at macosx/ppc32 and I'll probably
> look at freebsd/x86 and maybe freebsd/x86_64.)  I thought I'd mention
> some of the issues I've found so far regarding changes I plan to make
> just to see if I'm taking a reasonable approach.
> There are at least three locations that set up os/arch variables:
>  build/make/build.xml setup.xml targets/ehwa.test.xml
> For now, I'm just going to update all three, but really we need to
> figure out how to reconcile these.  (Ideally, we should reconcile them
> along with the classlib logic just as we need to figure out how to
> reconcile the shared dependencies.)
Yes, ultimately all top-levevl projects should use a shared setup (aka
properties.xml) and dependencies.

> I plan to add an if.unix property (or three ;-). Similarly, I plan to
> add an osfamily variable for use in the <select /> tags.  Ultimately,
> some of the directories called 'linux' might want to be renamed 'unix'
> but I'll tackle that after I've seen what code is likely to be common.

> Is the ant variable vm.port.includes defined anywhere?  (I spotted
> ${vm.port.includes} in verbose logs and just wondered if this was
> intentional?)

This must be overlooked piece spread through copy-paste, just remove it.

> Can we remove the env.MACHINE_ARCH variable and just use os.arch (as
> classlib does)?  Or is this a workaround for people building x86_64 with
> an ia32 jvm?
I've never seen it used, but anyway those people can directly override
"os.arch" (AFAIS "build.arch" it's name in drlvm build system ;) ). So
+1 to remove.

> Quite a few files contain #include <malloc.h> but the linux/freebsd/osx
> man page for malloc(3) says it should be #include <stdlib.h>.  I seem
> to recall making this change in classlib code at some point, but will
> fixing this in drlvm break anything?  Windows?

Most invokations of malloc in DRLVM are wrapped via macros defined in
port_malloc.h. I see <malloc.h> directly included only in jitrino and
portlib sources. The first was not fully moved to using portlib for
historical reasons, feel free to fix.
And the last may be fixed to consistently use port_malloc.h as well.

> I'll probably start making changes over the weekend.  Once I've made the
> basic build system changes then I guess I'll start looking at porting
> the actual code.
Cool! And all good luck to you ;)


> Regards,
>  Mark.

View raw message