Hi Mike.
Thank you for your response.
I am sorry I was probably not very clear about my problem.
Let me give you a better example with this assembly code extracted from my user application:
0x16258 <__syscall>:
...
0x16270: ldm ip, {r3, r4, r5, r6}
0x16274: svc 0x00000000
0x16278: pop {r4, r5, r6, r7}
The execution of the instructions above are traced, but when the SVC instruction is executed, the user application gives way to kernel land function related to the system call.
The kernel is not traced, but during the system call is executed, a computation result from the monitor is nested before returning to user land. In order to inform the FPGA monitor that the user application entered into a system call I am using PTM traces.
The “execution flow” is:
1) Jump to __syscall function (at 0x16258)
2) SVC Instruction in the user application is executed (at 0x16274)
3) Entering into the Kernel land … (somewhere in the kernel land)
4) Waiting a response from the FPGA monitor (somewhere in the kernel land)
The traces in the FPGA monitor are: { … ; 0x16258 } (notice that the last trace is 0x16258, the address of __syscall function)
As the traces don't include any waypoint update packet nor the exception branch address packet related to the SVC instruction at 0x16274 the FPGA monitor is not aware that the application is entered into a system call.
I tried to read all documentations available, but I didn’t find when exactly the waypoint update packet and/or the exception branch address packet are packed and emitted.
I thought that by flushing the traces, at least the waypoint update packet (0x16274) will be flushed, but that's not the case.
By doing some experimentations, I understood that when an SVC instruction is traced, the corresponding waypoint update packet and the exception branch address packet are available only when returning from that exception.
Is that correct ?
To reach this conclusion, I tested to return from the kernel land without waiting the FPGA Monitor response (not wanted behaviour) and I had the result below:
The “execution flow” is:
1) Jump to __syscall function (at 0x16258)
2) SVC Instruction in the user application is executed (at 0x16274)
3) Entering into the Kernel (somewhere in the kernel land)
4) Returning from kernel land (at 0x16278)
The traces in the FPGA monitor are: { … ; 0x16258 ; 0x16274 ; 0xffff0008 ; 0x16278 }
So my question is :
Is it possible to force the waypoint update packet (0x16274) or/and the exception branch address packet (0xffff0008 ; 0x16278) to be flushed before returning from the SVC (at 0x16278) ?
Best regards,
Mounir