lightning
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Lightning] Porting GNU Smalltalk to lightning 2


From: Paulo César Pereira de Andrade
Subject: Re: [Lightning] Porting GNU Smalltalk to lightning 2
Date: Sat, 25 Oct 2014 13:48:57 -0200

2014-10-25 12:01 GMT-02:00 Holger Hans Peter Freyther <address@hidden>:
> On Sat, Oct 25, 2014 at 12:20:36AM -0200, Paulo César Pereira de Andrade 
> wrote:
>
>>   I figured what was it, was a previous test. If I copy gst.im from another
>> build (using lightning 1.x, on i586), then it works for simple commands.
>> For example:
>
> 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...

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

---%<---
Program received signal SIGINT, Interrupt.
<function called from gdb>
(gdb) p $eip
$1 = (void (*)()) 0xffffd1df
(gdb) x/i 0xffffd1df
=> 0xffffd1df:  int3
---%<---

(hung in the int3 call)

  I think this is a side effect of how jit is generated, so, one have only
one chance of calling a function from gdb, after that it will hang.
The side effect, I mean, is because it basically creates one
function prolog/epilog, and the "body" of the function is created
later, with non local gotos. But all jit should enter/leave from
this chunk in libgst/interp-jit.inl:

---%<---
        if (!native_ip)
      return (_gst_nil_oop);

        native_ip = _gst_run_native_code (native_ip);

        if (!native_ip)
---%<---

_gst_run_native_code is the "jit trampoline", it receives an argument
of where to jump to, and returns a pointer of where to jump to in the
next call.

  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:

(gdb) b *address-of-return-to-c-code
(gdb) cond 1 ($eax != address-of-return-to-c-code && $eax != 0)

where address-of-return-to-c-code is shown in the log, example:

---%<---
# :doSend:555
        0xf7ed613d      jmp    *%eax
# :returnZeroFromNative:632
        0xf7ed613f      nop
        0xf7ed6140      xor    %eax,%eax
# :returnFromNative:637
        0xf7ed6142      xchg   %ax,%ax
        0xf7ed6144      mov    %ebp,%esp
        0xf7ed6146      mov    0xc(%esp),%edi
        0xf7ed614a      mov    0x8(%esp),%esi
        0xf7ed614e      mov    0x4(%esp),%ebx
        0xf7ed6152      mov    (%esp),%ebp
        0xf7ed6155      add    $0x10,%esp
        0xf7ed6158      ret
---%<---

Well, you should use the address after the label, I did not care
of "fixing" it (the jit_note and the jit_label are not matching...), and
the code is printing the label before actually aligning the label, so,
there may be a noop in the debug dump... in this case the line:
        0xf7ed6142      xchg   %ax,%ax
so, address-of-return-to-c-code would actually be:
        0xf7ed6144      mov    %ebp,%esp
(I will try to fix this for any new commit in scratch-lightning-branch)


  For some extra information, right now I am working as root in the
i586 chroot, and have the smalltalk with lightning 2.x directory named
smalltak-2, so, when it crashes, the full backtrace is this:

---%<---
# :f39d5600:3155
        0xe1fe105c      jmp    *%edi
        0xe1fe105e      xchg   %ax,%ax
Message new "<-0xc5b7b20>" did not understand selector
Program received signal SIGABRT, Aborted.
0xf7fd6cf0 in __kernel_vsyscall ()
Missing separate debuginfos, use: debuginfo-install
glibc-2.19.90-10.fc21.i686 gmp-6.0.0-2.fc21.i686
libffi-3.1-6.fc22.i686 libsigsegv-2.10-8.fc22.i686
libtool-ltdl-2.4.2-30.fc22.i686 ncurses-libs-5.9-13.20140323.fc21.i686
readline-6.2-8.fc21.i686 zlib-1.2.8-4.fc21.i686
(gdb) bt
#0  0xf7fd6cf0 in __kernel_vsyscall ()
#1  0xf7a53657 in raise () from /lib/libc.so.6
#2  0xf7a54f59 in abort () from /lib/libc.so.6
#3  0xf7efc554 in oldspace_sigsegv_handler (fault_address=0x0, serious=0)
    at oop.c:961
#4  0xf7ec9b31 in sigsegv_handler () from /lib/libsigsegv.so.2
#5  <signal handler called>
#6  0xf7f4b279 in printf_oop (stream=0x8303b60, info=0xffffca58,
    args=0x8303584) at print.c:211
#7  0xf7f7c91b in printf_generic (stream=0x82eae30, pinfo=0xffffca58,
    args=0x8303584) at custom.c:132
#8  0xf7f7aff4 in do_printfv (stream=0x82eae30,
    format=0xf7f8b7e8 "%O did not understand selector %O\n\n", args=0x8303578)
    at printf.c:516
#9  0xf7f7bc10 in stream_vprintf (stream=0x82eae30,
    format=0xf7f8b7e8 "%O did not understand selector %O\n\n",
    ap=0xffffcb9c "\260\206\365\367\002") at printf.c:907
#10 0xf7f7bec2 in snv_vprintf (
    format=0xf7f8b7e8 "%O did not understand selector %O\n\n",
    ap=0xffffcb94 "\340\204\244", <incomplete sequence \363>) at printf.c:1112
#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
#13 0xe1fe105c in ?? ()
#14 0xf7fa2000 in ?? () from /root/smalltalk-2/libgst/.libs/libgst.so.7
#15 0xf7f65823 in _gst_nvmsg_send (receiver=0xf3a21658,
    sendSelector=0xf39c9ef8, args=0xffffce64, sendArgs=2) at interp.c:2318
#16 0xf7f32840 in _gst_va_msg_sendf (resultPtr=0xffffd034,
    fmt=0xf7f7fcf6 "%s %o value: %o value: %o",
    ap=0xffffd024 "\340\025\242\363\333<\357", <incomplete sequence \367>)
    at callin.c:305
#17 0xf7f32a7d in _gst_msg_sendf (resultPtr=0xffffd034,
    fmt=0xf7f7fcf6 "%s %o value: %o value: %o") at callin.c:380
#18 0xf7ef3d64 in install_method (methodOOP=0xf3a48508, classOOP=0xf39ca3f8)
    at comp.c:2515
#19 0xf7ef03a6 in _gst_compile_method (method=0x82e7414, returnLast=false,
    install=true, undeclaredTemps=false) at comp.c:891
#20 0xf7ee36b6 in parse_method (p=0xffffd3dc, at_end=93) at gst-parse.c:1359
#21 0xf7ee28f6 in parse_class_definition (p=0xffffd3dc, classOOP=0xf39ca3f8,
    extend=true) at gst-parse.c:907
#22 0xf7ee20eb in parse_scoped_definition (p=0xffffd3dc, first_stmt=0x82e6cc0)
    at gst-parse.c:718
#23 0xf7ee1d84 in parse_doit (p=0xffffd3dc, fail_at_eof=false)
    at gst-parse.c:624
#24 0xf7ee156c in parse_chunks (p=0xffffd3dc) at gst-parse.c:475
#25 0xf7ee1462 in _gst_parse_chunks (currentNamespace=0x0) at gst-parse.c:449
#26 0xf7ee7655 in _gst_parse_stream (currentNamespace=0x0) at lex.c:1209
#27 0xf7f2c3c0 in _gst_process_file (
    fileName=0xf7f7d73a <standard_files+1274> "CFuncs.st", dir=GST_DIR_KERNEL)
    at input.c:855
#28 0xf7ee03e2 in load_standard_files () at files.c:580
#29 0xf7ee0227 in _gst_initialize (
    kernel_dir=0x804f2b8 "/root/smalltalk-2/kernel",
    image_file=0xf7f7d8ab "gst.im", flags=10) at files.c:522
#30 0xf7edf587 in gst_initialize (kernel_dir=0x0, image_file=0x0, flags=2)
    at gstpub.c:156
#31 0x080492fb in main (argc=1, argv=0xffffd754) at main.c:386
---%<---

#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

> holger

Thanks,
Paulo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]