m68k-ecos (Was: Re: [kaffe] WHICH LIBRARIES ARE NECESSARY TO RUN KAFFE?)

[Kiyo Inaba]

Hi Dalibor,

The original post is interesting (in some sence) for me, but first
I try to answer very trivial point, since I was called.

>In particular since you are compiling kaffe for m68k-ecos, I'd suggest
>turning gcc's optimisation off (CFLAGS=-O0), as people have reported
>various problems with m68k and older gcc version being overeager on
>optimisation. I've CC:ed Kiyo, who I recall having worked around some
>m68k gcc problems in the past, he may have additional sugegstions as well.

It is always very good custom to disable optimization for testing.
Currently, I put optimization to be -O1 for both m68k-linux or m68k-netbsd
in config.frag, and the tester can modify this line to be set to -O0 for
his sake.

As far as optimization (of m68k) is concerned, of course you can select
-O0, -O1 or even -O2 and current snap MAY work for all of these settings
(for linux or netbsd), and the reason why I put -O1 in spite of -O2 is
-O1 makes firster executables than -O2 (if I remember correctly). As
Dalibor mentioned, I found some bugs of optimization but it only happens
for jit (or jit3) and if you use intrp engine, this should be OK. I
fixed the bug by putting proper register prologue in sysdepCallMethod
and now it works.

Going back to the original problem (Coldfire/eCos port), I can suggest
using intrp (that has been already set in Daniel's configure) and
without -O0, possibly specifying to use jthread rather than native
thread. But as I mentioned earlier, I am not sure whether it works
or not. The reason is Coldfire is not fully compatible with MC68030
(or 68020) and as far as I know this CPU has never been tested with kaffe.

If the tester has gdb available on the target, set breakpoing before
callMethodV (and callMethodA) and verifying sysdepCallMethod properly
works or not is very helpful. But keep in mind that whenever checking
sysdepCallMethod, simple step command may sometimes make gdb feels
unconfortable, and clash (depend on CPU/OS). This is very dark side
of debuging kaffe...

Kiyo
P.S. When I debug sysdepCallMethod for sh3, I found a bug in 'gdb' :-)