Index
> Windows > "call" doing wrongGoto page 1, 2 Next |
| Author |
|
|
revolution 04 Aug 2020, 12:03
No one else has reported any problem with call.
Show some representative code. We don't know what you have done. |
|||
04 Aug 2020, 12:03 |
|
|
Overclick 04 Aug 2020, 12:31
This part of code works only if declared before DlgProc
Code: alignPrepared: push rax push rbx push rcx mov rcx,4 @@: dec rcx cmp rcx,0 je @F mov rbx,Prepared add rbx,rcx mov al,[rbx] cmp al,20h jne @B mov byte[rbx],0 jmp @B @@: pop rcx pop rbx pop rax ret It doesn't work if declared inside DlgProc, but if I use some macros on it, I have to declare it inside DlgProc, even in the end of proc, otherwise it corrupt. You say no one else reported this problem, but I seen it already in google with advice to declare procedure-label before call.[/code] |
|||
|
04 Aug 2020, 12:31 |
|
|
revolution 04 Aug 2020, 12:46
There are no call instructions inside your code sample.
This works for me: Code: use64
call forward_label
forward_label: Code: 2 passes, 5 bytes. |
|||
|
04 Aug 2020, 12:46 |
|
|
Overclick 04 Aug 2020, 12:56
It was procedure called by call operator from DlgProc. What do you want to see, how I call? It is nothing wrong to put 'call label' somewhere. Problem with address it use for jump. Passed not mean working.
|
|||
|
04 Aug 2020, 12:56 |
|
|
revolution 04 Aug 2020, 12:58
I can't replicate your problem, so yes, we need to see what is happening.
Post some minimised code showing the problem. |
|||
|
04 Aug 2020, 12:58 |
|
|
Overclick 04 Aug 2020, 12:59
call alignPrepared
|
|||
|
04 Aug 2020, 12:59 |
|
|
Overclick 04 Aug 2020, 13:00
jmp alignPrepared works fine in almost the same condition.
|
|||
|
04 Aug 2020, 13:00 |
|
|
revolution 04 Aug 2020, 13:02
Do you mean like this:
Code: use64 call alignPrepared alignPrepared: push rax push rbx push rcx mov rcx,4 @@: dec rcx cmp rcx,0 je @F ; mov rbx,Prepared add rbx,rcx mov al,[rbx] cmp al,20h jne @B mov byte[rbx],0 jmp @B @@: pop rcx pop rbx pop rax ret call alignPrepared Code: 2 passes, 47 bytes. |
|||
|
04 Aug 2020, 13:02 |
|
|
Overclick 04 Aug 2020, 13:12
Code: will_work: invoke MessageBox,HWND_DESKTOP,"It is ok",0,MB_OK ret ;----------------------------------------------- proc dlgProc .... cmp [wMsg],WM_COMMAND je wmcommand ret wmcommand: ....BN_CLICKED... button_1: call will_work ret button_2: call will_not ret button_3: call will_work_too ret ;subprocedures------------------------------------ will_not: invoke MessageBox,HWND_DESKTOP,"It is ok",0,MB_OK ret will_work_too: somemacro invoke MessageBox,HWND_DESKTOP,"It is ok",0,MB_OK ret endp |
|||
|
04 Aug 2020, 13:12 |
|
|
revolution 04 Aug 2020, 13:15
You have no endp so all the rets after the proc are more complex than just the simple ret.
|
|||
|
04 Aug 2020, 13:15 |
|
|
Overclick 04 Aug 2020, 13:17
Actually last example will always work as it already use macro "invoke" (exept first button), but I hope you understand what I mean.
scroll it to see endp Last edited by Overclick on 04 Aug 2020, 13:21; edited 1 time in total |
|||
|
04 Aug 2020, 13:17 |
|
|
revolution 04 Aug 2020, 13:20
The rets inside the proc/endp are not normal rets. You need to move that code outside the proc/end
Code: proc ... call something ret ;complex ret endp something: invoke ... ret ;normal ret |
|||
|
04 Aug 2020, 13:20 |
|
|
Overclick 04 Aug 2020, 13:25
I have no problems with rets. there is wrong call address.
Any way I don't use subprocedures inside proc any more. |
|||
|
04 Aug 2020, 13:25 |
|
|
revolution 04 Aug 2020, 13:26
Overclick wrote: I have no problems with rets. there is wrong call address. |
|||
|
04 Aug 2020, 13:26 |
|
|
Overclick 04 Aug 2020, 13:35
Why it is not documented anyhow? Whatever, 'call' still unpredictable in calls to outside DlgProc.
Code: will_not: mymacro ret will_work: mymacro jmp back_to_Dlg proc DlgProc ... call will_not jmp will_work back_to_Dlg: ... ret endp There is no issues to return, mymacro doesn't even start to work. Last edited by Overclick on 04 Aug 2020, 13:40; edited 1 time in total |
|||
|
04 Aug 2020, 13:35 |
|
|
revolution 04 Aug 2020, 13:38
Then I think there is something else you have done that you have overlooked. No one else has trouble.
|
|||
|
04 Aug 2020, 13:38 |
|
|
bitRAKE 04 Aug 2020, 13:41
I've had this problem in the past - it was like revolution said. It was so annoying that I switched to using RETN every time I want a real RET instruction. You can see it in all my code on the board. If people don't know they probably think it looks crazy, but when assemblers starting making decisions what a return instruction is based on the context I moved to be more explicit. So, it's possible to have leaf functions in PROC, but they should end with RETN. This works similarly to MASM.
The macro interaction sounds like something else. _________________ ¯\(°_o)/¯ “languages are not safe - uses can be” Bjarne Stroustrup Last edited by bitRAKE on 04 Aug 2020, 13:44; edited 1 time in total |
|||
|
04 Aug 2020, 13:41 |
|
|
Overclick 04 Aug 2020, 13:42
Short and long calls missing I suppose.
|
|||
|
04 Aug 2020, 13:42 |
|
|
Overclick 04 Aug 2020, 13:51
about call:
Code: macro call destination { push rip push rax mov rax,<sum of opcodes size> add [rsp+8],rax pop rax jmp destination } Just for testing 'call'. If it will work fine, then it 100% problem in fasm Last edited by Overclick on 04 Aug 2020, 13:55; edited 2 times in total |
|||
|
04 Aug 2020, 13:51 |
|
| Goto page 1, 2 Next < Last Thread | Next Thread > |
Forum Rules:
|