I've not seen it do that by accident. The most likely thing is that it's emerged from stdout or stderr. When doing a trace these streams get mixed in with the trace. Most commonly one gets one character at a time and at the start of a line (and not necessarily at exactly the instruction which caused it).Jamie wrote:Just a couple more simulator-related issues:
Does it mean anything when the simulator spits out a '^@' character mid-trace:
Code: Select all
^@0@0@0 A-.----00010336 (initSystem + 6) : ldw r1(0x1), sp[0x0] L[0x1eff4] @4315
It's likely this is connected with the other message you're seeing...
The simulator deals with system calls by placing a pseudo break-point at the address of _DoSyscall. The address of _DoSyscall is loaded from the ELF for each core. I would guess that you've hit this address by accident with some register values which the simulator doesn't understand.And, I'm not sure what to make of this:as it's not clear what's causing it, unlike a TRAP or ECALL which give a location and time.
Code: Select all
ERROR: Unimplemented OS call '-9'
I assume your application ELF doesn't define _DoSyscall however the network setup ELF does define it and it seems that xsim is using that address even after loading your application.
There are two workarounds that spring to mind both of which have essentially the same effect: (1) Add a label named _DoSyscall in your app at a location the PC will never reach, or (2) Pass "--defsymbol _DoSyscall=0" to the linker (and don't jump to the NULL pointer!).
N.B. The pseudo break-point actually has some extra "magic" in it which makes it especially confusing when you hit it by accident. From memory, it performs the syscall function and then pretends the following instruction is a retsp. Thus control moves to the location pointed to by LR which is likely to be the address after the last branch-link instruction executed.