This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

uvision disassembly is inconsistent between function calls

I'm working with a freescale FRDM-MKL25Z4 development board, writing some minimal code. I find that the simulator and the development board seem to disagree on the behavior. also in my disassembly window I often get different disassembly for the same instruction.

memcpy:
0x00000292 B5B0 DCW 0xB5B0 << why isn't this a PUSH?
0x00000294 B089 DCW 0xB089
0x00000296 4613 DCW 0x4613
...
0x000002DC BDB0 DCW 0xBDB0

memset:
0x000002DE B5B0 PUSH {r4-r5,r7,lr} <<why is it PUSH here?
0x000002E0 B088 SUB sp,sp,#0x20

any help would be appreciated.

Parents
  • I have seen lots of debuggers that shows correct assembly from the current position and forward, but might show bytes as data for earlier addresses. I have also seen a number of debuggers who shows incorrect processor instructions for earlier addresses because the debugger has tried to step back byte-for-byte while trying to identify what might be an instruction.

    A label doesn't automagically tell that an address is a jump target so must be the first byte/word of a processor instruction. With debug information, it should be reasonably simple to know what is code. With just a map file, it isn't so easy.

    A commercial grade disassembler spends a number of passes walking over the bytes just to pick up all the hints what is code and what is data.

    Did your project contain full debug information?

Reply
  • I have seen lots of debuggers that shows correct assembly from the current position and forward, but might show bytes as data for earlier addresses. I have also seen a number of debuggers who shows incorrect processor instructions for earlier addresses because the debugger has tried to step back byte-for-byte while trying to identify what might be an instruction.

    A label doesn't automagically tell that an address is a jump target so must be the first byte/word of a processor instruction. With debug information, it should be reasonably simple to know what is code. With just a map file, it isn't so easy.

    A commercial grade disassembler spends a number of passes walking over the bytes just to pick up all the hints what is code and what is data.

    Did your project contain full debug information?

Children