On Sun, Sep 12, 2010 at 17:38, Peter Tyser ptyser@xes-inc.com wrote:
Using -fno-toplevel-reorder causes gcc to not reorder functions. This ensures that an application's entry point will be the first function in the application's source file.
This change, along with commit 620bbba524fbaa26971a5004793010b169824f1b should cause a standalone application's entry point to be at the base of the compiled binary. Previously, the entry point could change depending on gcc version and flags.
Note -fno-toplevel-reorder is only available in gcc version 4.2 or greater.
Signed-off-by: Peter Tyser ptyser@xes-inc.com
I didn't have a version of gcc < 4.2. The change is pretty trivial so it should work, but it'd be appreciated if someone with an old toolchain installed could give the patch a shot.
Since I was writing a standalone test program today, I manually tested against an older u-boot and arm gcc 4.4.1. Worked fine. You can add my tested-by if you feel that's sufficient.
I wonder if this is the right way to fix this. It seems a bit subtle. I thought of two other possible workarounds - have the Makefile use mkimage as part of the output so the entry point is embedded in the mkimage file, or redo the programs to have a main() as entry and write a crt0.S equivalent and have the entry location for that fixed in a linker file.