The Crossworks Disassembly window actively reads the target's memory and disassembles those values. It then intermixes that disassembly with the ELF debugging information for the associated addresses.
There is an implicit assumption by the IDE that the values read from the target memory match those in the ELF.
Particularly when code is executing from RAM, there is the real possibility that the values read (and disassembled) from the target memory have been clobbered and do not agree with the ELF. As a result, the user can be misled that the displayed intermixed ELF debugging information even corresponds to the disassembly of what is in memory. (Certainly, it throws Crossworks off balance, as its single-stepping breakpoint logic obviously breaks down if the memory doesn't matches the ELF.)
Crossworks is already performing the most time consuming task of reading (via the debugging interface) the target memory. Much, if not all, of the ELF information is presumably already memory-resident on the host PC. So perhaps it is almost a "free" operation for Crossworks to compare those target memory values against the ELF and highlight (say black on red) in the Disassembly window or warn when there is a disparity?
Such a feature would be substantively more proactive in flagging an issue than depending on the user to notice that the disassembly does something different than what the ELF information claims.
Please sign in to leave a comment.