Re: [Lightning] Porting GNU Smalltalk to lightning 2

[Paulo César Pereira de Andrade]

2014-10-25 16:24 GMT-02:00 Holger Hans Peter Freyther <address@hidden>:

>>  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. :}

  To tell the truth, I did not test this condition much, all my usage
of lightning so far did not have C calling jit that calls C (that may
again call jit...), and then checking stack frames. The only test for
this is http://git.savannah.gnu.org/cgit/lightning.git/tree/check/ccall.c
so, there may be some issues, it is just known to pass that
test in all backends...

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

  This is in my TODO list. But it would require changing lightning
to understand types and variables. So far, for me, it is mostly a
TODO for https://github.com/pcpa/owl, but it could be made an
extra library, that interfaces lightning and the code generating
jit, so that gdb would know about the "language" variables,
"language" stack frame, etc.

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

  I was playing with a lot of options earlier today, this was one of them.

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

weird, what I have in the chroot is not even the latest...

# rpm -q gdb gcc
gdb-7.7-4.fc21.i686
gcc-4.9.1-11.fc22.i686

on the base system (I am adventurous and run rawhide) I have:
$ rpm -q gdb gcc
gdb-7.8-25.fc22.x86_64
gcc-4.9.1-11.fc22.x86_64

> 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);
>  }

  I will try these hints for x86_64.

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

  Try updating to latest lightning. I made it no longer fail in init_jit,
so no need to keep patching the argument to init_jit,
http://git.savannah.gnu.org/cgit/lightning.git/commit/?id=9cdcfcc38f8f3ee0e80335f14974287112c82548

and most important, update to latest scratch-lightning-branch
https://github.com/pcpa/smalltalk/commit/5e0e9f4aa148b03f619d8d8378fdcae0a658a250

  I got it to "almost" work on i586, still fails the same way on x86_64...
but it is quite weird, as far as I understand, I did the proper translation
from lightning 1.x to lightning 2.x in that code...

> holger

Thanks,
Paulo