I did some tests and HAS_INIT_SECTION doesnt seem to make a difference so
it is a waste of time, I wont bother doing that anymore...

configuring gcc --with-cpu=arm7tdmi doesnt seem to make a difference, the
elf files come out different but the binary is the same. When compiling
using -mtune=arm7 or -mtune=arm9, etc do alter the size and performance of
the binary, but -mtune=arm7tdmi does not make a difference the numbers come
out the same (as if it were a default).

Compiling newlib with -O3 optimizations vs the default -O2 does not affect
the performance of the dhrystone, it does affect the binary size though,
makes it bigger. I am going to find an example or two of something other
than the dhrystone that will make calls into newlib to show what affect the
-O3 optimization has on the newlib library (good or bad).

David







> > #define HAS_INIT_SECTION,
> > ecos uses this, I was trying to do something with the do_global_ctors or
> > dtors functions, like remove them because they were wasting memory (I
> > think), I dont remember I have always added it in there, ecos.h still has
> > it, it looks like gcc/crtstuff.c might look for it...
>
>Is this the option that tells gcc to create .init and .fini sections? I
>actually use the configure option --diable-init-fini or something like
>that to disable it because Jeff's crt0.S would just ignore it. Or, is
>this handled by __gccmain. It has been too long since I investigated C++
>compilation to remember ^_^
>
> > I dont know if it has come up yet but I strongly vote to keep the long
> form
> > of the executable names: arm-agb-elf-gcc vs gcc.
>
>In dka, I keep the long names, and then use my mklinkstub program (made
>possible through clever use of objcopy ^_^) to create the short name
>versions.
>
>I never could finish building gcc if I tried to tell it not to use the
>prefix. Also, the documentation for building gcc now says that it ignores
>any attempt to set the name prefix if you are building a cross compiler.
>They probably did this because it breaks the build process.
>
>I always felt like it wasn't a big deal to type 'arm-agb-elf-gcc', but I
>did not even want to deal with the issue, so I wrote mklinkstub to
>simulate symbolic links.
>
> > I only want one gcc executable in the path and that one should build
> > for the native host environment, cygwin, mingw, linux, whatever. For
> > arm cross compiling keep the name different arm-agb-elf-gcc.
>
>I think this can be solve by being aware of your path. If the native path
>is first, then it will cover up all the linkstubs in the dka/bin
>directory.
>
>I need to look into the -b option more and see how it would relate to the
>native compiler. I was thinking something like this:
>
>arm-agb-elf-gcc ... # compile for gameboy advance
>arm-agb-elf-gcc -b agb # also compile for gameboy advance
>arm-agb-elf-gcc -b gp32 # compile for gp32
>arm-gp32-elf-gcc # compile for gp32
>arm-gp32-elf-gcc -b gp32 ... # also compile for gp32
>arm-gp32-elf-gcc -b agb # compile for gameboy advance
>gcc # native compiler or gba compiler
>depending on PATH
>gcc -b agb # fails for native compiler
>gcc -b gp32 # fails for native compiler
>
>In cygwin or msys, you would probably have your path setup so that the
>short name 'gcc' would be covered by the native compiler. But, if you
>were using cmd or command.com (I dunno why, Cygwin or msys are much nicer
>shells), then you probably do not have another gcc, so you can use the
>short name.
>
>When in doubt do a gcc --version (Unlike what rmitton says, changing
>version.c is not "just to be fancy")
>
>
> > Last comment, I cant remember what devkitadv does specifically but I have
> > seen a number of arm cross compiler builders use a huge list of switches
> > when configuring gcc, the vast majority of those are already the defaults
> > or are obsolete or dont apply to arm builds...
>
>I revisited the documentation when I started working on release 5, and
>eliminated a few switches. I am almost completely sure that all the
>switches I used before were relavent for gcc version 3.0.2, but they have
>changed slightly.
>
>--with-headers is now deprecated, and eliminating it will still result in
>a successful build. The replacement, --with-sys-root, is not required
>either.
>
>I am not sure if --disable-shared applies to generic ARM targets. Perhaps
>it only applies to targets with OSes.
>
>Same goes for --disable-threads. However, I figured that since those
>options accurately describe the GBA, that I would keep them.
>
>--enable-targets=arm-coff,arm-aout are there just for completeness. I
>figured that someone might find a use for them, and if so then they would
>not have to recompile DKA. arm-coff is their because I believe that is
>what Microsoft's ARM compiler would output. I wanted to experiment with
>it, since it is free and may make better code than gcc.
>
>Perhaps I should add arm-pe so that the devkit could compile PocketPC
>executables (I think). ^_^
>
>I kept --enable-win32-registry, although I never had any problems getting
>gcc to relocate to different directories.
>
>--with-cpu=arm7tdmi makes the gameboy processor the default.
>
>And of course --target=arm-agb-elf so that it uses the custom linkscript
>and crt0.s.
>
>I cannot think of any more switches except for --with-newlib
>
>
>
>
>
>
>
>Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/