harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Egor Pasko <egor.pa...@gmail.com>
Subject Re: [general] harmony launch failed on AMD Geode LX
Date Sat, 02 Feb 2008 09:36:59 GMT
On the 0x3DD day of Apache Harmony Gregory Shimansky wrote:
> On 1 февраля 2008 Egor Pasko wrote:
> > On the 0x3DD day of Apache Harmony Mark Hindess wrote:
> > > > > in place of sfence in vm/vmcore/src/thread/linux/atomics.cpp.
> > > >
> > > > Yes I think this should help on processors with no SSE (not to mention
> > > > SSE2) support.
> > >
> > > It does.  HelloWorld runs okay with -Xint.  (Now I just need to find a
> > > way to run the tests on a machine which boots to a small ramdisk from
> > > compact flash and doesn't currently support network file systems.)
> > >
> > > Without -Xint, predictably, it fails with not-immediately-helpful core
> > > which reports:
> > >
> > > (gdb) bt
> > > #0  0xa649d24d in ?? ()
> > > (gdb) x/1i $eip
> > > 0xa649d24d:     (bad)
> > >
> > > It might be worth adding an option to the federation build compile for
> > > a more limited processor so that people can do some testing w/-Xint - on
> > > OLPC, Geode and VIA based machines?
> >
> > I tried to say that a build option would be nearly as hard to
> > implement as a runtime option, which is more preferrable.
> 
> In class library I saw an interesting approach with code patching in assembly. 
> It has a special segment with the same name (on windows all segments of the 
> same name are merged across assembly sources) with labels for each LOCKed 
> instruction. In case the system is determined to be uniprocessor, it patches 
> all of the LOCK prefixes with NOP (see thrhelp.asm, thrspinlock.asm and 
> lock386.c files).

cool! but who needs uniprocessors? :)

They say some windows drivers on uniprocessor systems just stop thread
preemption by flipping a special flag with no lock prefix [1]. That is
because windows does not support CPU hotplug :)

> In theory it could be possible to gather all of the locations of mfence, 
> sfence, etc instructions in the code and patch them according to architecture 
> at the initialization point. But in practice creating such a table is easy 
> only for assembly.

I see the biggest problem in making a complete list of all potential
fence places. After that deciding case by case is much easier.

[1] http://msdn2.microsoft.com/en-us/library/ms810047.aspx

-- 
Egor Pasko


Mime
View raw message