You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
001029AE 558F subq.l #$02,a7 ; space for return value
001029B0 3F2E FFF6 move.w -$000A(a6),-(a7) ; FILEref
001029B4 486E FFF8 pea -$0008(a6) ; Pointer to length variable
001029B8 4EBA 1A2C jsr.l GETEOF ; $1A2E(pc)
001029BC 3E1F move.w (a7)+,d7 ; return error value removed from stack.
GETEOF - is a PASCAL function
001043E6 4E56 FFCE link a6,#$FFCE
001043EA 204F movea.l a7,a0
001043EC 316E 000C 0018 move.w $000C(a6),$0018(a0) ; move FILEref to offset $18 of local paramblock
001043F2 A011 illegal #$A011 ; PBGETEOFSYNC A0 - ptr to paramblock, result in D0
001043F4 3D40 000E move.w d0,$000E(a6) ; move result to space allocated by caller
001043F8 226E 0008 movea.l $0008(a6),a1 ; Get pointer from passed arg
001043FC 22A8 001C move.l $001C(a0),(a1) ; move EOF value from local paramblock to pointer location
00104400 4E5E unlk a6
00104402 225F movea.l (a7)+,a1 ; get return address
00104404 5C8F addq.l #$06,a7 ; clean up Arg 1, Arg 2 - PASCAL procedures remove passed parameters
00104406 4ED1 jmp.l (a1) ; return - via jump to return address in a1
GETEOF
ptr32GETEOF(ptr32a6, <anonymous>*dwArg00) -missingpassedArgs
{
Eq_7986tLoc36;
tLoc36.ptr0032=a6;
// Shouldn't tLoc36.t003E.u7 be listed as passed Arg and the location the value is stored is missing it's ref tLoc36..u7tLoc36..u7=tLoc36.t003E.u7;
uint32d0_11= (uint32) PBGetEOFSync(&tLoc36);
// I take it that tLoc36.w0040 is the Offset 000E from A6, the space allocated by the caller for the Pascal function return valuetLoc36.w0040= (word16) d0_11;
// Shouldn't *tLoc36.ptr003A be listed as *Arg *tLoc36.ptr003A=tLoc36.dw001C;
dwArg00();
returntLoc36.ptr0032;
}
The text was updated successfully, but these errors were encountered:
Thanks for providing an isolated sample; it helps in focusing. The indirect call to the return address popped off the stack really confuses the Reko analysis stage. I have some ideas of how to address this.
…s/platforms
We use the new explicit modeling of continuations on MacOS, and in ELF binaries for zSeries and ARM/ARM thumb. The results are excellent.
This fixes#573, #929. It also improves #1257.
Once you declare the GETEOF procedure as no-decompile, using a signature the appropriate __pascal attribute, this problem went away. Is this to your satisfaction?
Using my sample file LinkIIgs.
Expected output
Generated output
Example of call to GETEOF
GETEOF - is a PASCAL function
GETEOF
The text was updated successfully, but these errors were encountered: