On Sun, Sep 12, 2010 at 17:38, Peter Tyser <pty...@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 <pty...@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. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
