Re: [Lightning] Porting GNU Smalltalk to lightning 2

[Holger Hans Peter Freyther]

On Sat, Oct 25, 2014 at 01:48:57PM -0200, Paulo César Pereira de Andrade wrote:

> > Yes. either when kernel/ is new or gst.im does not exist the bootstrap
> > is started. The "bootstrapException" means something went wrong during
> > the bootstrap, the question is more what went wrong. It looks like
> > something while CFuncs.st is being parsed (but even then things like
> > "Object subclass: MyClass [ | myMemberVariable | ]" will execute code
> > or "ExistingClass extend [ newOrReplaceMethod []]" will lead to some
> > state being removed.
> 
>   I am sorry the few I know about GNU Smalltalk code I learned in the
> past few days, and do not know smalltalk either, so, it is very likely
> something not so difficult but I just do not have enough knowledge to
> easily debug it...

I am sorry if the above sounded like a complain. I am amazed how far
you got and wanted to provide some help. E.g. explaining after which
file it goes bonk, that even subclassing executes smalltalk code and
that something might go wrong because of something subtle a lot earlier.




> 
> > You might have found it but "p _gst_show_backtrace(stderr)" will print a
> > smalltalk backtrace but in the case when the bootstrap exception takes
> > place it is not meaningful. The other thing I noticed is that gdb is
> > not able to unwind the jit framestack. So we don't know which method
> > was called? Is there an issue with the prologue that was generated?
> 
>  I think you mean that gdb never resumes if you tell it to execute a
> function. The same happens in my working build, on i586 with
> lightning 1.x, so it is not unique to lightning 2.x. Example:

I meant something like

gdb> bt
C function.
jit-code (sure not dwarf2 information so no names..)
end-of-rewind..

I thought that was lightning1 gdb was able to rewind beyond the
jit-code back to _gst_interpret. At least gdb7.7 can't do it. :}


>   The best way to debug is to actually add printfs, and do a
> binary search to what is leading to that condition. It should
> also be required to add breakpoints in actual jit, and likely
> conditionals, for example, to test when it is returning to
> C, one can write:

Have you considered using the GDB jit interface? At least we
could marry a function to a CompiledMethod that way? The other
thing that can be handy is setting a breakpoint in _gst_debug
and then calling "Smalltalk debug" from within smalltalk. This
will go through the primitive interface and then one can use
_gst_show_backtrace(stderr) to see the callers and such.


> #11 0xf7f7be55 in snv_printf (
>     format=0xf7f8b7e8 "%O did not understand selector %O\n\n") at 
> printf.c:1086
> #12 0xf7f58705 in VMpr_Object_bootstrapException (id=-1, numArgs=1)
>     at prims.def:3516

You can configure with "--disable-generational-gc" to have more easy GC.
The crash in snv_printf might be that things are wrong not fully initialized
so the question is to figure out what failed before it.

> #13 is the jit frame, and #14 for some reason did not get proper debug
> information, maybe because it is code not in a file ending with .c; it is
> _gst_interpret, in libgst/interp-jit.inl

with my GDB (7.7 debian testing) I can't go beyond frame #14. Downgrading
to GDB7.4 doesn't improve the situation. Maybe a gcc4.9 quirk?


To simplify things I did:

* Disable inlining of integer operations modified DONT_INLINE_NONINTEGER
to always use gen_send(tree). This requires a small chang to the bootstrap
order

diff --git a/libgst/files.c b/libgst/files.c
index a38fb1a..f6a7973 100644
--- a/libgst/files.c
+++ b/libgst/files.c
@@ -177,13 +177,13 @@ static const char standard_files[] = {
   "Date.st\0"
   "Time.st\0"
   "Number.st\0"
+  "SmallInt.st\0"
   "Float.st\0"
   "FloatD.st\0"
   "FloatE.st\0"
   "FloatQ.st\0"
   "Fraction.st\0"
   "LargeInt.st\0"
-  "SmallInt.st\0"
   "Character.st\0"
   "UniChar.st\0"
   "Link.st\0"


* Disable DONT_INLINE_SUPER

* Disable generating "optimized"/inlined primitives by 

@@ -2694,6 +2694,7 @@ emit_basic_size_in_r0 (OOP classOOP, mst_Boolean tagged, 
int objectReg)
 mst_Boolean
 emit_inlined_primitive (int primitive, int numArgs, int attr)
 {
+#if 0
   switch (primitive)
     {
     case 60:
@@ -3098,6 +3099,7 @@ emit_inlined_primitive (int primitive, int numArgs, int 
attr)
       }
     }
 
+#endif
   return (attr & ~PRIM_INLINED);
 }
 

* In CFuncs.st I remove all calls to cCall. The "cCall" pragma
will lead to the function bytecode being re-written. This will fail
somehow. I think CompiledMethod>>rewriteAsCCall will call and is
failing somehow. So removing "cCall" will get us a bit further but
still ends up as a crash. Besides that not being called. :}

I will keep digging.

holger