Subject: Re: patch for kaffe1.0.7jit3 code runing on MIPS - msg#00113

Previous Message by Date: click to view message preview

Re: Building kaffe 1.1.4 under Fedora Linux

Hi Guilhem, I've just erased Fedora and installed Suse 9.1 instead. I then tried to rebuild kaffe 1.1.4 and it went smoothly like a breeze :-) So the bottom line is: Suse is better than Fedora! Minh --- Guilhem Lavaux <guilhem@xxxxxxxxx> wrote: > Minh Nguyen wrote: > > >Hi Guilhem, > > Here is the output from gdb. If you need more > >information, I can try again. > > > >(gdb) run at.dms.kjc.Main @essential.files > >Starting program: > >/home/mnguyen/kaffe1.1.4/kaffe/kaffe/.libs/lt-kaffe-bin > >at.dm s.kjc.Main @essential.files > > > >Program received signal SIGSEGV, Segmentation > fault. > >callMethodA (meth=0x9c8f758, func=0x9c90f0c, > obj=0x0, > >args=0x0, > > ret=0xbfe74b68, promoted=1) at > >sysdepCallMethod.h:41 > >41 ((void (*)(void))(call->function))(); > > > > > > > > > > > > Hi Minh, > > After having looked again at the code it seems it > should work though. > What do you have in your config.log ? Especially > look at HAVE_MPROTECT > and HAVE_COMPATIBLE_MPROTECT. They should be both 1 > on fedora as the > memory is really protected on it. > > Thanks. > > Cheers, > > Guilhem. > > >>Fedora Linux > >> > >>Minh Nguyen wrote: > >> > >> > >>>Hi , I used your snap shot but still have no luck > >>> > >>> > >>(see > >> > >> > >>>below). Any idea? > >>> > >>> > >>> > >>Hi Minh, > >> > >>I have not the slighliest idea of what's happening > >>there. :( On my fresh > >>FC2 install kaffe is running smoothly though. > Could > >>you try to check > >>with gdb where the problem is lying ? I can help > you > >>debug it. > >> > >>For example, if the build directory is represented > >>by $build: > >> > >>cd libraries/javalib; > >>source $build/BUILD_ENVIRONMENT; > >>export > >> > >> > >> > >BOOTCLASSPATH=$BOOTCLASSPATH:Klasses.jar.bootstrap:kjc.jar > > > > > >>gdb $build/kaffe/kaffe/.libs/lt-kaffe-bin > >> > >>then: run at.dms.kjc.Main @essential.files > >> > >>gdb should indicate at which point the SEGV > occurs. > >>Type where and send me what it is saying. > >> > >>Thanks for taking the time to try ! > >> > >>Best regards, > >> > >>Guilhem. > >> > >> > >> > >>>../../../libraries/javalib/rebuildLib: line 60: > >>> > >>> > >>30612 > >> > >> > >>>Segmentation fault $JAVAC $VERBOSE > >>> > >>> > >>$JAVAC_FLAGS > >> > >> > >>>-d $LIBDIR $CPATH ${1+"$@"} > >>>gmake[3]: *** [lib/stamp] Error 139 > >>>gmake[3]: Leaving directory > >>> > >>> > >>> > >>`/home/mnguyen/kaffe-1.1.x-cvs/tools/gjdoc/javalib' > >> > >> > >>>gmake[2]: *** [all-recursive] Error 1 > >>>gmake[2]: Leaving directory > >>>`/home/mnguyen/kaffe-1.1.x-cvs/tools/gjdoc' > >>>gmake[1]: *** [all-recursive] Error 1 > >>>gmake[1]: Leaving directory > >>>`/home/mnguyen/kaffe-1.1.x-cvs/tools' > >>>gmake: *** [all-recursive] Error 1 > >>> > >>> > >>>--- Guilhem Lavaux <guilhem@xxxxxxxxx> wrote: > >>> > >>> > >>> > >>>>Minh Nguyen wrote: > >>>> > >>>> > >>>> > >>>>>How is CVS related to this? I've downloaded the > >>>>>development release directly from kaffe.org, > not > >>>>> > >>>>> > >>>>using > >>>> > >>>> > >>>> > >>>>>CVS at all. > >>>>> > >>>>>Minh > >>>>> > >>>>> > >>>>I was talking about kaffe's cvs and not about > CVS > >>>>itself. Though you may > >>>>not be able to use it. So I am putting a > snapshot > >>>> > >>>> > >>of > >> > >> > >>>>it on > >>>> > >>>> > >>>http://www.kaffe.org/~guilhem/kaffe-1.1.x-cvs.tar.gz > >>> > >>> > >>>>and waiting for either kaffe-1.1.5 or > kaffe-1.1.6 > >>>> > >>>> > >>to > >> > >> > >>>>come ... :) > >>>> > >>>>Regards, > >>>> > >>>>Guilhem. > >>>> > >>>> > >>>> > >>>> > >>>>>--- Guilhem Lavaux <guilhem@xxxxxxxxx> wrote: > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>Minh Nguyen wrote: > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>>Hi, I am trying to build development release > >>>>>>> > >>>>>>> > >>>>1.1.4 > >>>> > >>>> > >>>> > >>>>>>of > >>>>>> > >>>>>> > >>>>>> > >>>>>> > === message truncated === __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail

Next Message by Date: click to view message preview

Re: Fixing mipsel-linux: differences between jit3 and jit1

> > Hi all, > > I've been trying to fix the build on mipsel-linux. It uses jit3. I've > got the LOUT build problem sorted out, the syntax of LOUT and friends > has changed between jit3 and jit1. The next stumbling stone is > prologue_xxC, which does not exist in jit3 funcs.h. So before I blindly > change prologue_xxC to prologue_xxx on mips (and possibly m68k, since it > suffers from same symptoms on netbsd), I'd like to know what the > difference in naming is supposed to mean ;) > > i.e. what is in the name suffix -xxx that xxC doesn;t have, etc. I > couldn't find that documented, unfortunately. I don't think it actually matters, but the name is supposed to signify the parameters for the "instruction". As far as I can tell: R - register L - label C - constant or a label that refers to a constant. I think its basically a poor man's function overloading mechanism. So, in the case of prologue, it doesn't really matter since there aren't multiple implementations of the prologue. > cheers, > dalibor topic tim

Previous Message by Thread: click to view message preview

Re: patch for kaffe1.0.7jit3 code runing on MIPS

>>>>> "Dalibor" == Dalibor Topic <robilad@xxxxxxxxx> writes: Dalibor> Casey Marshall wrote: >>>>>>> "Dalibor" == Dalibor Topic <robilad@xxxxxxxxx> writes: Dalibor> Yoshiharu Oba wrote: >> >>>> Hi Dalibor I appreciate your advice very much. Now I'm writing a >>>> changelog and remake a new patch, It's also included. Dalibor> Thanks a lot! I'll go through it, and see what needs to be Dalibor> applied to the CVS head. It's great that you got JIT & JIT3 Dalibor> to work. I'd like to get your changes in, and then look at Dalibor> Casey's patches for JIT & JIT3 from this spring. >> One thing I was not able to fix in JIT3 was the stack unwinder, >> which is a particularly bad piece of code. The real problem was >> that GCC would reorder instructions in the prologue, so the >> unwinder was not able to find where the function stored $ra. I >> haven't tried a more recent GCC (I was using 3.1), but I think >> using `-fno-reorder-insns2' fixes this particular problem. Also, I >> really don't much like that unwinder in general. It makes too many >> assumptions about the way the stack looks, which may not be true in >> general. GCC's unwinder makes a bit more sense, since it uses >> debugging info it will typically be consistent. Dalibor> Is there some general stack unwinder library/API we could use Dalibor> for that? I've seen that mprotect has some code for such Dalibor> things for mips, sparc, i386, etc. How does gcc/gcj deal with Dalibor> that problem? There is libunwind <http://www.hpl.hp.com/research/linux/libunwind/>, but it only supports x86 and IA-64. GCC has fairly sophisticated unwinding support, in gcc/unwind*. For MIPS, and probably most other architectures too, it uses the DWARF-2 debugging format for unwinding, because that format stores information such as what registers get saved on the stack, and where. It can also do file names and line numbers (something I'm investigating right now, because I would like to get debugging stack traces in GCJ without having to fork external processes). The problem with that approach in Kaffe would be that you would need to generate that debugging info for jitted frames, and I don't know how well that would fit into the unwinder (it looks, to me, very specific to ELF). -- Casey Marshall || csm@xxxxxxx

Next Message by Thread: click to view message preview

Re: patch for kaffe1.0.7jit3 code runing on MIPS

>>>>> "Timothy" == Timothy Stack <stack@xxxxxxxxxxx> writes: >> There is libunwind >> <http://www.hpl.hp.com/research/linux/libunwind/>, but it only >> supports x86 and IA-64. >> >> GCC has fairly sophisticated unwinding support, in gcc/unwind*. For >> MIPS, and probably most other architectures too, it uses the >> DWARF-2 debugging format for unwinding, because that format stores >> information such as what registers get saved on the stack, and >> where. It can also do file names and line numbers (something I'm >> investigating right now, because I would like to get debugging >> stack traces in GCJ without having to fork external processes). Timothy> So, are you trying to get GCJ to work on MIPS as well? Yes. I've been able to get the interpreter running in pretty short order, even. Most of the hacking I had to do was in libffi, which might even be useful in Kaffe. I sent patches to java-patches@xxxxxxxxxxx if anyone is interested. Right now I have almost no problems running on a patched version of GCJ 3.3.3, and the libjava test suite gets about 12 FAILs, half of which are because I stripped out half the class library. And I may investigate patching 3.4.0 instead, since it has a lot of improvements on MIPS. >> The problem with that approach in Kaffe would be that you would >> need to generate that debugging info for jitted frames, and I don't >> know how well that would fit into the unwinder (it looks, to me, >> very specific to ELF). Timothy> I ran into similar problems with the powerpc jitter. Timothy> Eventually, I came to the conclusion that the best thing to Timothy> do for the immediate future is to just forget about trying to Timothy> unwind any code not produced by the jitter and dump the Timothy> registers before calling any native code. It'd be a Timothy> performance hit, but generating the right DWARF junk and Timothy> whatever else was just getting too complicated. Anyways, you Timothy> still need to deal with code that doesn't have unwind info... Timothy> You might want to look at what mono or one of the other VMs Timothy> do here... You could, at least, guarantee that the native VM code has this info (-fexceptions). I think trying to unwind through random broken JNI code is outside the scope of a VM. This is an interesting problem! Definitely worthy of a hacker's time, and the mipsel JIT3 is so close to working it isn't even funny. -- Casey Marshall || csm@xxxxxxx