If memory serves me right, Leopold Toetsch wrote: > pusha/popa is overkill. The called functions always save bp and bx,di,si > when used. ax is the return value, remaining is dx (cx is used by > shifts) - i386 of course.
Ok ... push_necessary() ;-) ... > > Speaking about debugging calls from JIT'd code ... Does parrot JIT > > generate a debugging segment ? like a dwarf2 segment so that we can > > debug with gdb ? ... (I hate it when I see 200 ?? in a backtrace). > > > That would be a really nice feature. Can we - and how - handle over > debug info to a running gdb? It is possible ... JIT generated code looks just like loaded code to gcc ... Typically gdb should only need access to a symfile to correctly allow debugging ... So an .o file of the JIT'd code should be correctly generated with all the trimmings. $ gdb parrot (gdb) run -debug=dwarf2 --break __main__ Foo.pbc (gdb) call Parrot_debug_make_syms() (gdb) add-symbol-file Foo.o Reading symbols from Foo.o (gdb) frame #0 __main__ at Foo.py:5 (HINT: where's the python compiler :-) The trick here is to use `gas' or the gnu assembler to generate the debugging info from the assembly dump you provide ... For example a function would be dumped as... ..string "Func" ..byte 0x13 ; METHOD_RETVAL ..byte 0x01 ; _public ..byte 0x00 ; _none (not virtual) ..long .L_TYPE_00000 - .L_debug_info_b ; return type at label ..... This would mean that in debug mode the JIT will have to turn off all the optimisations and that the packfile contains a linenumber table or something similar ... (maybe even the whole source program too.. like gcc does ..) This is just an idea ... I'm too busy in DotGNU to try this out now .. And we have no JIT to do this stuff ... just an X86 code unroller for simple instructions sort of like the u-v pipelines in pentiums .. the fast x86 run or slow interpret according to instruction complexeties .. There this idea would mean gdb has to debug both the modes together.... Hth, Gopal -- The difference between insanity and genius is measured by success
