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
> >
> >
>