Ask a Question

Not understanding CallDef: properly

0 votes
by Bart Nelson (420 points)

We're obviously not understanding the useful new word CallDef: properly.

Previously, when we needed to use a double (floating point) in a callproc: we did something like this ...

3 0 CallProc: on_dmain_vpan { pgesture pdirection puser  -- } \ Vertical pan gesture event
  FGET                             \ Get offset
  ADJVMAIN gtk_adjustment_get_value            \ Get existing scroll value
  FSWAP
  pdirection GTK_PAN_DIRECTION_UP = IF            \ Pan up
    F+                            \ Add to scroll value
  ELSE                            \ Pan down
    F-                            \ Subtract from scroll value
  THEN
  ADJVMAIN gtk_adjustment_set_value             \ Set new scroll value
;

where FGET was the workaround for the lack of a method for recovering doubles in the input parameter list, defined (for SSE64) as ...

code FGET ( F: -- r ) \ Get double from input parameter
  sub        r13, # FPCELL        \ save FTOS
  movsd        0 [r13], xmm8
  movsd        xmm8, xmm0        \ Copy single input parameter to top of FP stack
  next,
end-code

The Gtk3 pan gesture signal is documented as ...

void pan (  GtkGesturePan* self,  GtkPanDirection* direction,  gdouble offset,  gpointer user_data )
So to use CallDef: we redefined on_dmain_vpan as follows ...
CallDef: void on_dmain_vpan( void * self, void * direction, double offset, gpointer user_data ):  \ Vertical pan gesture event
  { pgesture pdirection puser  -- }

cr ." vpan"
cr ." Direction " pdirection . ."  offset " fdup f. ."  user " puser .

  ADJVMAIN gtk_adjustment_get_value            \ Get existing scroll value
  FSWAP
  pdirection GTK_PAN_DIRECTION_UP = IF            \ Pan up
    F+                            \ Add to scroll value
  ELSE                            \ Pan down
    F-                            \ Subtract from scroll value
  THEN
  ADJVMAIN gtk_adjustment_set_value             \ Set new scroll value
;
But when the signal is called, we get an immediate illegal address crash - even if the entire innards of the function are commented out.
What are we doing wrong?

















 



 

 





 




 





2 Answers











 
 





0 votes 


























by 
Stephen Pelc

(3.4k points)











Please do not throw away the evidence! I need the crash dump to help you!



Also disassemble the three portions of the CALLDEF:

  entry

  action

  exit



and include the disassemblies in your reply.



























by 
Bart Nelson

(420 points)




edited




by Bart Nelson













Reduced it to its absolute minimum



CallDef: void on_dmain_vpan( void ): 



;



and it still throws an illegal memory access.



The disassembly:



DASM on_dmain_vpan 

( 00F4519B    E8D2BF4CFF )            CALL    00411172

( 00F451A0    C851F400 )              ENTER   F451, 00

( 00F451A4    0000 )                  ADD     0 [RAX], AL

( 00F451A6    0000 )                  ADD     0 [RAX], AL

( 00F451A8    EF )                    OUT     DX, EAX

( 00F451A9    CDAB )                  INT     AB

( 00F451AB    896745 )                MOV     [RDI+45], ESP

( 00F451AE    2301 )                  AND     EAX, 0 [RCX]

( 00F451B0    50 )                    PUSH    RAX

( 00F451B1    51 )                    PUSH    RCX

( 00F451B2    F4 )                    HLT

( 00F451B3    0000 )                  ADD     0 [RAX], AL

( 00F451B5    0000 )                  ADD     0 [RAX], AL

( 00F451B7    00E8 )                  ADD     AL, BPL

( 00F451B9    51 )                    PUSH    RCX

( 00F451BA    F4 )                    HLT

( 00F451BB    0000 )                  ADD     0 [RAX], AL

( 00F451BD    0000 )                  ADD     0 [RAX], AL

( 00F451BF    004051 )                ADD     [RAX+51], AL

( 00F451C2    F4 )                    HLT

( 00F451C3    0000 )                  ADD     0 [RAX], AL

( 00F451C5    0000 )                  ADD     0 [RAX], AL

( 00F451C7    00E8 )                  ADD     AL, BPL

( 00F451C9    83FFFF )                CMP     EDI, # -01

( 00F451CC    FFE8 )                  JMP     RAX

( 00F451CE    16 )                    PUSH    SS

( 00F451CF    0000 )                  ADD     0 [RAX], AL

( 00F451D1    00E8 )                  ADD     AL, BPL

( 00F451D3    69FFFFFFC300 )          IMUL    EDI, EDI, # 00C3FFFF

( 00F451D9    0000 )                  ADD     0 [RAX], AL

( 00F451DB    0000 )                  ADD     0 [RAX], AL

( 00F451DD    0000 )                  ADD     0 [RAX], AL

( 00F451DF    0000 )                  ADD     0 [RAX], AL

( 00F451E1    0000 )                  ADD     0 [RAX], AL

( 00F451E3    0000 )                  ADD     0 [RAX], AL

( 00F451E5    0000 )                  ADD     0 [RAX], AL

( 00F451E7    00E8 )                  ADD     AL, BPL

( 00F451E9    53 )                    PUSH    RBX

( 00F451EA    8C4DFF )                MOV     [RBP+-01], CS

( 00F451ED    C3 )                    RET/NEXT

( 83 bytes, 40 instructions )





















 












by 
Stephen Pelc

(3.4k points)














DASM on_dmain_vpan   wrong!



on_dmain_vpan returns a structure. See the manual section 25.4.1.



on_main_vpan dis-cd  \ disassemble whole routine

call cd-entry

call cd-action

call cd-exit

ret



To get the entry address

  on_main_vpan get-CallDefEntry \ -- entrypoint





















 












by 
Bart Nelson

(420 points)














Oh dear try again ...

Now we have

CallDef: void on_dmain_vpan( void * self, void * direction, double offset, gpointer user_data ):

  DROP DROP FDROP DROP

;

and ...

on_dmain_vpan dis-cd 

( 00F451E8    E863FFFFFF )            CALL    00F45150

( 00F451ED    E816000000 )            CALL    00F45208

( 00F451F2    E849FFFFFF )            CALL    00F45140

( 00F451F7    C3 )                    RET/NEXT

( 00F451F8    0000 )                  ADD     0 [RAX], AL

( 00F451FA    0000 )                  ADD     0 [RAX], AL

( 00F451FC    0000 )                  ADD     0 [RAX], AL

( 00F451FE    0000 )                  ADD     0 [RAX], AL

( 00F45200    0000 )                  ADD     0 [RAX], AL

( 00F45202    0000 )                  ADD     0 [RAX], AL

( 00F45204    0000 )                  ADD     0 [RAX], AL

( 00F45206    0000 )                  ADD     0 [RAX], AL

( 00F45208    488B5D08 )              MOV     RBX, [RBP+08]

( 00F4520C    488D6D10 )              LEA     RBP, [RBP+10]

( 00F45210    E87B085CFF )            CALL    00505A90  FDROP

( 00F45215    488B5D00 )              MOV     RBX, [RBP]

( 00F45219    488D6D08 )              LEA     RBP, [RBP+08]

( 00F4521D    C3 )                    RET/NEXT

( 54 bytes, 18 instructions )

...

on_dmain_vpan dis-cdentry 

( 00F45150    E86B9857FF )            CALL    004BE9C0

( 00F45155    4883ED10 )              SUB     RBP, # 10

( 00F45159    4983ED08 )              SUB     R13, # 08

( 00F4515D    488BDA )                MOV     RBX, RDX

( 00F45160    F2410F104500 )          MOVSD   XMM0, [R13]

( 00F45166    4C897D00 )              MOV     [RBP], R15

( 00F4516A    4C897508 )              MOV     [RBP+08], R14

( 00F4516E    FFA42438580100 )        JMP     [RSP+00015838]

( 00F45175    C3 )                    RET/NEXT

( 38 bytes, 9 instructions )

...

on_dmain_vpan dis-cdaction 

( 00F45208    488B5D08 )              MOV     RBX, [RBP+08]

( 00F4520C    488D6D10 )              LEA     RBP, [RBP+10]

( 00F45210    E87B085CFF )            CALL    00505A90  FDROP

( 00F45215    488B5D00 )              MOV     RBX, [RBP]

( 00F45219    488D6D08 )              LEA     RBP, [RBP+08]

( 00F4521D    C3 )                    RET/NEXT

( 22 bytes, 6 instructions )

...

on_dmain_vpan dis-cdexit 

( 00F45140    4159 )                  POP     R9

( 00F45142    488BC3 )                MOV     RAX, RBX

( 00F45145    E8669957FF )            CALL    004BEAB0

( 00F4514A    49FFE1 )                JMP     R9

( 00F4514D    C3 )                    RET/NEXT

( 14 bytes, 5 instructions )





















 












by 
Stephen Pelc

(3.4k points)














And how did you set up the entrypoint? You need

  on_main_vpan get-CallDefEntry ( -- entrypoint )



on_main_vpan is the address of a data structure!





















 












by 
Bart Nelson

(420 points)














OK so now I think I am setting the entry point correctly 



i.e.



GVPAN Z" pan" on_dmain_vpan get-CallDefEntry 0 g_signal_connect DROP        \ Enable vertical pan signal



and there is no longer a crash.



BUT - the floating point number is completely wrong.

Here is the CallDef ...



CallDef: void on_dmain_vpan( void * self, void * direction, double offset, gpointer user_data ):  \ Vertical pan gesture event

  { pgesture pdirection puser  -- }

cr ." vpan"

cr ." Direction " pdirection . ."  offset " fdup f. ."  user " puser .

  ADJVMAIN gtk_adjustment_get_value            \ Get existing scroll value

  FSWAP

  pdirection GTK_PAN_DIRECTION_UP = IF            \ Pan up

    F+                            \ Add to scroll value

  ELSE                            \ Pan down

    F-                            \ Subtract from scroll value

  THEN

  ADJVMAIN gtk_adjustment_set_value             \ Set new scroll value

;



And the debug report ...



vpan

Direction 3  offset 6.0142529e+175  user 0 



The offset should be a small number.





















 












by 
Bart Nelson

(420 points)














And this must mean that signals that use CallDef cannot be connected automatically from Glade.





















 












by 
Stephen Pelc

(3.4k points)














What this? and Why?





















 












by 
Bart Nelson

(420 points)














Simplifying as follows ...



CallDef: void on_dmain_vpan( void * self, void * direction, double offset, gpointer user_data ):  

cr ." vpan " . . . f.

;



The debug output shows ...



vpan 0 2 126408384 6.0142529e+175 



0 = the user data as set in g_signal_connect CORRECT

2 = the direction (GTK_PAN_DIRECTION_UP) CORRECT

126408384  = the handle of the pan control CORRECT, VERIFIED

6.0142529e+175 = the offset WRONG, should be (typically) 20.000000



Note that the FP number is there on the FP stack, it is just an impossible number.



The entry and exit code in just a sec ...





















 












by 
Bart Nelson

(420 points)














on_dmain_vpan dis-cdEntry 

( 00F45150    E86B9857FF )            CALL    004BE9C0

( 00F45155    4883ED10 )              SUB     RBP, # 10

( 00F45159    4983ED08 )              SUB     R13, # 08

( 00F4515D    488BDA )                MOV     RBX, RDX

( 00F45160    F2410F104500 )          MOVSD   XMM0, [R13]

( 00F45166    4C897D00 )              MOV     [RBP], R15

( 00F4516A    4C897508 )              MOV     [RBP+08], R14

( 00F4516E    FFA42438580100 )        JMP     [RSP+00015838]

( 00F45175    C3 )                    RET/NEXT

( 38 bytes, 9 instructions )

 ok

on_dmain_vpan dis-cdexit 

( 00F45140    4159 )                  POP     R9

( 00F45142    488BC3 )                MOV     RAX, RBX

( 00F45145    E8669957FF )            CALL    004BEAB0

( 00F4514A    49FFE1 )                JMP     R9

( 00F4514D    C3 )                    RET/NEXT

( 14 bytes, 5 instructions )

 ok





















 

 
 

 





 








 
 





0 votes 


























by 
Bart Nelson

(420 points)











Just to confirm that floating point doubles in callbacks now work correctly.



(Linux64 and SSE64)



























by 
Bart Nelson

(420 points)














However, a debug message has been left in CallDefSysVx64.fth in CDcopyFParg64 at line 347.

This is not a functional problem, but it alerts our compilation.

Needs to be removed in the next build.





















 












by 
Stephen Pelc

(3.4k points)














Good catch - line removed just now in source tree.





















 

 
 

 





 

 



 



















 

 

 





 













Snow Theme by Q2A Market




Powered by Question2Answer







 

 



...