x86 jitter? (One more try!)
Raab, Andreas
Andreas.Raab at disney.com
Sun Apr 8 20:17:01 UTC 2001
PhiHo,
I'd recommend getting the full Cygwin tool chain. It includes a graphical
GDB version which is *almost* usable (they've done some serious work on it).
Also, the default built does include all debug information so you should be
able to just gdb it.
Cheers,
- Andreas
> -----Original Message-----
> From: phiho.hoang [mailto:phiho.hoang at home.com]
> Sent: Sunday, April 08, 2001 12:27 PM
> To: squeak at cs.uiuc.edu
> Cc: recipient list not shown
> Subject: Re: x86 jitter? (One more try!)
>
>
> Hi Ian,
>
> I just installed Cygwin Insight Debugger . What flags
> should I use to
> build J3 for debugging ? Where should I place the breakpoints
> and lastly,
> what will I look for :-)
>
> I like to help to make J3 running on 90% (?) of the desktops :-)
>
> Thanks for making J3 available.
>
> PhiHo
>
> ----- Original Message -----
> From: "Ian Piumarta" <Ian.Piumarta at inria.fr>
> To: <Andreas.Raab at disney.com>
> Cc: <squeak at cs.uiuc.edu>; <phiho.hoang at home.com>; <marcus at ira.uka.de>
> Sent: Saturday, April 07, 2001 11:12 PM
> Subject: RE: x86 jitter? (One more try!)
>
>
> > On Sat, 7 Apr 2001, Raab, Andreas wrote:
> > >
> > > compile.cc: in `void gen_compile()'
> > > compile.cc:1111: phase error at sPC 26: 0084F18D r.d.. 1<
> 41 0084F1A8
> > > LdTemp 1
> > >
> > > (whatever that means ;-)
> >
> > That means (I'm assuming you can figure out everything up
> to and including
> > the third `:' for yourself ;-) :
> >
> > phase error
> > the address of the translated code for this instruction recorded
> > during the first pass of code generation was
> different to the
> > address observed during the second pass
> >
> > at sPC 26:
> > this is the sam (Squeak Abstract Machine) PC for the offending
> > instruction (the insn at which the problem was noticed, not
> > necessarily the insn that caused the problem)
> >
> > 0084F18D
> > this is the address of the 26th insn seen during the second
> > codegen pass (it's therefore the 25th that caused the problem, by
> > having differently-sized code on the second pass -- possibly a
> > short/long branch range thing on the 386???)
> >
> > r this insn is a join of two or more control flows
> > . this insn is not preceded by an unconditional control transfer
> > d this insn is the destination of a control transfer
> > . this insn does not have an ambiguous stack depth
> > . this insn is not squashed after being subsumed by a
> > "macro" insn preceding it
> >
> > 1< one non-linear flow of control arrives at this insn
> >
> > 41 this is the virtual PC (offset of the corresponding bytecode in
> > the original CompiledMethod) of this insn
> >
> > 0084F1A8
> > this is the native PC (translated code address) the insn recorded
> > during the codegen first pass
> >
> > LdTemp 1
> > the sam opcode at which the problem was noticed (not the one
> > that caused the problem, but the one after it)
> >
> > FWIW, 0084F1A8 - 0084F18D = 27 additional bytes compiled
> for the 25th
> > insn during the second pass, which seems *huge*. If you have a copy
> > of GNU libopcodes then you can define DSM_LISTING in
> compile.cc, link
> > against libopcodes.a, and j3 will dump a disassembly listing of the
> > translated code as it is generated, one sam insn at a time
> -- which is
> > often invaluable for tracking down the cause of this kind
> of problem.
> >
> > I hope some of that turns out to be of use.
> >
> > Ian
> >
> >
>
More information about the Squeak-dev
mailing list
|