• State Accepted Answer
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 118 subscribers
  • Views 824 views
  • Users 0 members are here
Options
Related
How was your experience today?
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

Image Entry Point

ronenw

Hi,

I've noticed that there is a difference in the "Image Entry Point" address between the ".axf ->Header " display (or .axf ->Symbol Table" display) and the linker output file using the "--list" linker option.

The linker output file shows 0x00002af4 but also 0x00002af5 and the other displays from the IDE .axf view shows 0x00002af5

I saw that difference (one byte offset) also with other functions and not only with e image entry point.

What would be the cause for that? i.e. why thge linker "Memory Map of the image" has this offset?

Thanks,
Ronen

Parents
  • 0

    Hi Ronen

    This is a legacy of Arm. The address of all instructtions will be at least half-word (16-bit) aligned, and so the least significant bit of every instruction address will be 0b0. This bit can be reused to encode that this address is for a Thumb instruction. Some processors supported 'Arm' (32-bit only code) and 'Thumb' (mixed) code, and so this was important. All Cortex-M processors are Thumb only, and so this is slightly meaningless. You will notice debuggers etc obfuscate this.

    Regards, Ronan

Reply
  • 0

    Hi Ronen

    This is a legacy of Arm. The address of all instructtions will be at least half-word (16-bit) aligned, and so the least significant bit of every instruction address will be 0b0. This bit can be reused to encode that this address is for a Thumb instruction. Some processors supported 'Arm' (32-bit only code) and 'Thumb' (mixed) code, and so this was important. All Cortex-M processors are Thumb only, and so this is slightly meaningless. You will notice debuggers etc obfuscate this.

    Regards, Ronan

Children