[U-Boot] [PATCH] examples/standalone: Use gcc's -fno-toplevel-reorder

[Peter Tyser]

Hi Andrew,

On Sun, 2010-09-12 at 21:00 -0500, Andrew Dyer wrote:
> On Sun, Sep 12, 2010 at 17:38, Peter Tyser <ptyser at 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 at 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.

Thanks for testing.  I agree this isn't the most elegant solution, but
its one big advantage is simplicity in my mind.  Creating/maintaining a
crt0.S and/or link script for each CPU architecture seems like overkill
for a simple (deprecated?) application interface to me.  I was under the
impression the preferred application interface going forward was the one
enabled by CONFIG_API in examples/api.  It uses the crt0 solution, but
only supports ppc and arm right now.

Using a uImage format for apps seems like a fine solution too.  Do
others have a preference?

I agree we should be using main() as the entry point either way.  I'll
add that to the TODO list.  If we did go with -fno-toplevel-reorder I
could add the following to each application to make it clear what's
going on:
/* Define main() protoype first to ensure its the first function in the image */
int main(int argc, char * const argv[]);

Best,
Peter