Re: [avr-gcc-list] Growing .data section when compiling with GCC 4.0 instead of GCC 3.4.3

[Bernard Fouché]

Good hint Dave: of the 90 objects making the application, I find 2 
objects having a big increase in .data . The 2 C files corresponding to 
these objects both have a big switch/case and it seems that the compiler 
is making some kind of 'jump table' to each 'case', probably to optimize 
the speed of processing the switch/case.

This table is built like this:

440                           .data
441                           .section .progmem.gcc_sw_table, "a", 
@progbits
442                           .p2align 1
443                     .L60:
444                           .data
445 000a 0000              .word pm(.L34)
446 000c 0000              .word pm(.L35)
447 000e 0000              .word pm(.L36)
448 0010 0000              .word pm(.L37)
449 0012 0000              .word pm(.L38)
450 0014 0000              .word pm(.L39)
451 0016 0000              .word pm(.L40)
452 0018 0000              .word pm(.L41)
453 001a 0000              .word pm(.L42)
454 001c 0000              .word pm(.L43)
455 001e 0000              .word pm(.L44)
456 0020 0000              .word pm(.L45)
457 0022 0000              .word pm(.L46)
458 0024 0000              .word pm(.L47)
459 0026 0000              .word pm(.L48)
460 0028 0000              .word pm(.L49)
461 002a 0000              .word pm(.L50)
462 002c 0000              .word pm(.L51)
463 002e 0000              .word pm(.L52)
464 0030 0000              .word pm(.L53)
465 0032 0000              .word pm(.L54)
466 0034 0000              .word pm(.L55)
467 0036 0000              .word pm(.L56)
468 0038 0000              .word pm(.L57)
469 003a 0000              .word pm(.L58)
470 003c 0000              .word pm(.L59)

Here are my compilation options:

Compiling: ../gsm8.c
avr-gcc -c -mmcu=atmega128 -I. -I. -I.. -DHARDWARE=0xe002 -g -Os 
-fsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall 
-Wstrict-prototypes -Wa,-adhlns=../gsm8.lst  -std=gnu99 ../gsm8.c -o 
../gsm8.o

Using -Os, I do not know if there is a space win by using such a table 
compared to standard comparisons for each 'case'. Also I think that such 
a table could be stored in flash memory since all entries are known at 
compile time.

At last note that I still did not yet tried to set up and run the 
application compiled with GCC4.0 because I fear that the .data increase 
will mess up everything (I won't have enough ram for the stack)

 Bernard

Dave Hylands wrote:

> > > > Since GCC 4.0 has been released, I wanted to give it a try. First I
> > > > was very happy with the optimizer improvements, however I'm stuck
> > > > with something that I don't understand: using the same C code, the
> > > > same avr-libc, I see the .data section growing 218 bytes without any
> > > > reason.
> > > >        
>
> I would start by running
>
>    avr-objdump -h someobj.o
>
> on your object files and find an object file which has some size
> difference. Then I'd recompile and produce assembler for that file and
> see where it's coming from.
>
>