Re: [avr-gcc-list] GCC 3.4.1 function address discrephancies

[Theodore A. Roth]

On Sat, 30 Oct 2004, Joshua Perry wrote:

> I am trying to build a bootloader, with an older version of WinAVR GCC 3.3.1
> the address for main would always be .text:00000000 as so:
>

<snip>

>
> I have output from the .lst file of the newest version of WinAvr. GCC 3.4.1
> main isn't at .text:00000000, it is put at the highest progmem location
> compared to all the other functions, as so:
>

<snip>

>
> The function "SendOctet" gets executed as soon as we jump to the bootloader
> section. Does anyone know why GCC 3.4.1 is doing this, or how I could fix
> it?

I recently hit the same problem with migrating my bootloader from
gcc-3.3.x to gcc-3.4.x. I was assuming, like you, that the first
function in a C module would end up at the lowest address. That
assuption is no longer valid when using gcc-3.4.x.

I was able to work around this by using a modified linker script, but
now that I think about it more, you can probably avoid that. If you are
using the standard linker scripts that come with avr-binutils, then you
can force your main() to be first by assigning it to a .init section and
then leaving all the other code in .text.  For example, this is
essentially what did in my bootloader (the only difference is I used a
".boot.entry" defined in my linker script):

  #define ATTR_NAKED       __attribute__ ((naked))
  #define ATTR_BOOT_ENTRY  __attribute__ ((section (".init0")))
  #define ATTR_NO_RET      __attribute__ ((noreturn))

  void boot_entry (void) ATTR_NAKED ATTR_BOOT_ENTRY ATTR_NO_RET;

  void
  boot_entry (void)
  {
     /* do fun stuff here */
  }

This hack assumes that you are linking your bootloader using
"-nostartfiles -nodefaultlibs -nostdlib" in your LDFLAGS.

Hope that is useful for you.

---
Ted Roth
PGP Key ID: 0x18F846E9
Jabber ID: address@hidden