• State Accepted Answer
  • Locked Locked
  • Replies 5 replies
  • Subscribers 19 subscribers
  • Views 11734 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

ENTRY directive for assembly code

Gopal Amlekar

Hi,

I am trying to understand the startup code and assembly language (more for learning and not for a specific project) for ARM Cortex M4.

I made a project in KEIL with just one assembly file and added a stack declaration and a vector table there. It was based on STM32F4 startup file in the Keil software pack.

In the reset handler I added just a couple of lines of code to load an immediate value into R0 and R1.

The program worked fine in the simulator however there was a warning issued during build - Warning: L6305W: Image does not have an entry point. (Not specified or not set due to multiple choices.).

Searching on the net, it led me that the ENTRY directive is required so the code knows where to start. So there should be either an ENTRY directive if programming in pure assembly or there should be __main symbol if programming in C.

Adding and ENTRY directive after the RESET code section helped eliminate the warning. But I wonder that even without ENTRY directive, the code worked properly. So what is the significance of the directive, if any? Or it is necessary for the ARM7 etc. and not for Cortex M?

Thanks,

Gopal

Parents
  • 0

    The ENTRY directive is explained here: ARM Compiler armasm User Guide : 13.25 ENTRY

    But basically...

    The ENTRY directive marks a point in your code where execution can "arrive" without the code explicitly branching to it.  Classic examples: reset handler and vector table.  You don't "branch" to the reset handler, execution goes there automatically when the processor resets.

    The Linker uses the ENTRY points for a couple of things....

    First, an ELF image has an entry point.  This is the PC value the debugger will set the target processor to when it loads the image.  If you've defined multiple ENTRY points, you'll need to tell the linker which one to use for the ELF header (otherwise I believe it sets it to 0x0).  If you're flashing the image onto the target, rather than loading the image through the debugger, this might not be too important to you.

    Second, the linker performs redundant code elimination.  That is, it tries to remove code that is never called.  It does this by checking whether the code is ever referenced from somewhere else.  For things like the vector table, it's quite possible that you never explicitly reference it - meaning it looks like it's redundant to the linker.  The ENTRY points tell the linker that execution can arrive at a point independently - so it knows that even if not referenced elsewhere it shouldn't eliminate it.

Reply
  • 0

    The ENTRY directive is explained here: ARM Compiler armasm User Guide : 13.25 ENTRY

    But basically...

    The ENTRY directive marks a point in your code where execution can "arrive" without the code explicitly branching to it.  Classic examples: reset handler and vector table.  You don't "branch" to the reset handler, execution goes there automatically when the processor resets.

    The Linker uses the ENTRY points for a couple of things....

    First, an ELF image has an entry point.  This is the PC value the debugger will set the target processor to when it loads the image.  If you've defined multiple ENTRY points, you'll need to tell the linker which one to use for the ELF header (otherwise I believe it sets it to 0x0).  If you're flashing the image onto the target, rather than loading the image through the debugger, this might not be too important to you.

    Second, the linker performs redundant code elimination.  That is, it tries to remove code that is never called.  It does this by checking whether the code is ever referenced from somewhere else.  For things like the vector table, it's quite possible that you never explicitly reference it - meaning it looks like it's redundant to the linker.  The ENTRY points tell the linker that execution can arrive at a point independently - so it knows that even if not referenced elsewhere it shouldn't eliminate it.

Children