c - __attribute__((OS_main)) results in strange behaviour in AVR -

i don't know how precisely described error seeing. if set port register in main() works intended. if try in function, program halts.

main.c:

__attribute__((os_main)) int main(void); int main(void) {                                                ddrd = 0xf0;     portd = 0xf0;     led( led_green, true );     while( true ); } 

this turns on green led. if move port setup seperate function nothing happens, so:

__attribute__((os_main)) int main(void); int main(void) {                                                hwinit();       led( led_green, true );     while( true ); } 

the culprit seems attribute line because if comment out second example works expected. problem understanding why, since understand os_main attribute should tell compiler should not store registers upon entry or exit function. not correct?

the following compiled avr-gcc 4.8.0 under archlinux. distribution should irrelevant situation, compiler , compiler version however, may produce different outputs. code:

#include <avr/io.h>  #define led_green pd7 #define led(p, s) { if(s) portd |= _bv(p); \                 else portd  &= _bv(p); }  __attribute__((os_main)) int main(void); __attribute__((noinline)) void hwinit(void);  void hwinit(void){     ddrd = 0xf0; }  int main(void){      hwinit();     led(led_green, 1);      while(1); } 

generates:

000000a4 <hwinit>:   a4:   80 ef           ldi r24, 0xf0   ; 240   a6:   8a b9           out 0x0a, r24   ; 10   a8:   08 95           ret  000000aa <main>:   aa:   0e 94 52 00     call    0xa4    ; 0xa4 <hwinit>   ae:   5f 9a           sbi 0x0b, 7 ; 11   b0:   ff cf           rjmp    .-2         ; 0xb0 <main+0x6> 

when compiled avr-gcc -wall -os -fpack-struct -fshort-enums -std=gnu99 -funsigned-char -funsigned-bitfields -mmcu=atmega168 -df_cpu=1000000ul -mmd -mp -mf"core.d" -mt"core.d" -c -o "core.o" "../core.c" , linked accordingly.

commenting __attribute__((os_main)) int main(void); above sources has no effect on generated assembly. curiously, however, removing noinline directive hwinit() has effect of compiler inlining function main, expected, function still exists part of final binary, when compiled -os.

this leads me believe compiler version/arguments compiler generating assembly not correct. if possible, can post disassembly relevant areas further examination?

edited late add 2 contributions, second of resolves problem @ hand: hanno binder states: "in order remove 'unused' functions binary need -ffunction-sections -wl,--gc-sections."

asker adds [paraphrased]: "i followed tutorial neglected mention avr-objcopy step create hex file. assumed compiling , linking project correct target sufficient (which reason basic functionality). after having added avr-objcopy step generate file works."