организация проэкта gcc, проект с использованием gcc Опции

[factorial]

При переносе проекта из IAR в gcc возник вопрос. Помогите разобраться.
Припустим у меня есть "драйвер", который
просто состоит из "с" и "h" файлов, не под ось, а просто, скажем к индикатору.
В "h" файле описаны порты ну и декларация функций.
В "с" файл также включен файл с описанием задержек, которые зависят от проца и от
частоты тактирования. В драйвере описаны как функции, которые используються
проэктом, так и функции, которые этим конкретным проектом не используються.
Так как gcc, в отличие от иара, на этапе компиляции закидывает в обьектные файлы
все функции без исключений, то это влияет на размер выходного бинарника.
Ну в принципе, хули там - делай драйер библиотекой, разбивай сишный файл
на множество сишных файликов, в каждой по своей фунции и дело с концом.
Но тут, вопервых, много гемора, во вторых, как вести отдельно поддержку драйевра,
ведь он зависит от конкретных задержек, описанных в файле, который тоже где-то
должен поддерживаться (может измениться, потом наведи лад со всеми этими библами).
Получаеться хрень какаето - что бы убрать из кода не используемые функции, нужно
проделать кучу лишних движений, плюс к этому это все нужно поддерживать, да если еще
и куча проэктов на этом висит, то это пипец.... Как это лучше организовать с ипосльзованием gcc?

[Idle]

You can enable the toolchain to remove unused code by adding these
flags:

CFLAGS += -ffunction-sections

This tells the compiler to put each function in its own section. This
must be used for all *compile* command lines, hence added to the CFLAGS
variable.

LDFLAGS += -Wl,-gc-sections

This tells GCC to send the -gc-sections flag to the linker (via -Wl).
The -gc-sections flag tells the linker to "garbage collect" (remove)
unused sections. Since all functions are now in their own individual
section, this has the effect of removing unused functions. This flag is
a linker flag, so it is set in the LDFLAGS variable.

Сообщение отредактировал Idle - Sep 29 2011, 19:14

[demiurg_spb]

А чтоб вообще заполировать:
CFLAGS += --combine
CFLAGS += -fwhole-program

нынче правда это всё в LTO перекочевало, что собственно очень хорошо ибо применимо и к проектам на плюсах.

ЗЫ: для обсуждения gcc есть отдельная ветка на форуме:
http://electronix.ru/forum/index.php?showforum=162

[factorial]

после добавления CFLAGS += -ffunction-sections LDFLAGS += -Wl,-gc-sections

компиляция каждого файла:
avr-gcc -Wall -Os -fpack-struct -fshort-enums -std=gnu99 -funsigned-char -funsigned-bitfields -mno-interrupts -DF_CPU=3686400UL -mmcu=atmega128 -ffunction-sections -c -MD
тут все Ок

компоновка:
avr-gcc -Wl,-gc-sections -L"/home/ivan/DATA1/prog/embedded/PATI" -mmcu=atmega128 -o patima.hex alm.o bc1602e.o cint.o ctmp.o def.o delay.o dmem.o ds1631.o ds18b20.o dsp.o err.o fm24c64.o iic.o ini.o kbd.o light.o mctr.o mem.o mem_fm24c64.o mexe.o mopr.o msg.o note.o patima.o pcf8583.o ptimer.o rmd.o rtc.o sgn.o sta.o stm.o stp.o stw.o tc0.o tc1.o tc3.o tmp.o tmr.o trg.o usr.o wdt.o wire.o wrt.o zmr.o -lp
/usr/lib/gcc/avr/4.3.5/../../../avr/lib/avr51/libc.a(fp_powsodd.o):../../../libm/fplib/fp_powsodd.S:59: relocation truncated to fit: R_AVR_13_PCREL against symbol `__mulsf3' defined in .text section in /usr/lib/gcc/avr/4.3.5/avr51/libgcc.a(_mul_sf.o)
/usr/lib/gcc/avr/4.3.5/../../../avr/lib/avr51/libc.a(fp_powsodd.o):../../../libm/fplib/fp_powsodd.S:69: relocation truncated to fit: R_AVR_13_PCREL against symbol `__mulsf3' defined in .text section in /usr/lib/gcc/avr/4.3.5/avr51/libgcc.a(_mul_sf.o)
make: *** [patima.hex] Ошибка 1

а тут хз. Чего не то? Без указанных опций все компилируеться...

[demiurg_spb]

Удалите руками все старые объектники и файлы зависимостей и пересоберите проект.
и
LDFLAGS += -lm

[factorial]

Добавление либы LDFLAGS += -lm на удивление помогло, все собралось и после добавления CFLAGS += -ffunction-sections LDFLAGS += -Wl,-gc-sections,
но нужного эффекта не дало, объем флеша так и остался прежним, и код не нужных функций так и содержится в нем. Добавление CFLAGS += -fwhole-program
привело к ошибкам в main(), при которых он не видит функций включенных через h.
patima.c:(.text.main+0x0): undefined reference to `ini'
patima.c:(.text.main+0x4): undefined reference to `rtc'
patima.c:(.text.main+0x8): undefined reference to `tmp'
patima.c:(.text.main+0xc): undefined reference to `stw'
patima.c:(.text.main+0x10): undefined reference to `usr'
patima.c:(.text.main+0x14): undefined reference to `alm'
patima.c:(.text.main+0x18): undefined reference to `tmr'
patima.c:(.text.main+0x1c): undefined reference to `rmd'
patima.c:(.text.main+0x20): undefined reference to `trg'
patima.c:(.text.main+0x24): undefined reference to `sgn'
patima.c:(.text.main+0x28): undefined reference to `kbd'
patima.c:(.text.main+0x2c): undefined reference to `ptimer'
make: *** [patima.hex] Ошибка 1

[demiurg_spb]

Добавление либы LDFLAGS += -lm на удивление помогло, все собралось и после добавления CFLAGS += -ffunction-sections LDFLAGS += -Wl,-gc-sections,
но нужного эффекта не дало, объем флеша так и остался прежним, и код не нужных функций так и содержится в нем.

странно.

Добавление CFLAGS += -fwhole-program привело к ошибкам...

естественно. нужно не просто добавить этот флаг а и передать все исходники компилятору разом, а не кормить по одному...

[Сергей Борщ]

LDFLAGS += -Wl,-gc-sections,
но нужного эффекта не дало, объем флеша так и остался прежним, и код не нужных функций так и содержится в нем.

LDFLAGS += -Wl,--gc-sections

[factorial]

Ррр, Работает как с --gc-sections, так и с -gc-sections. Настройки в eclipse не правильно сделал.
Со своим makefile пошло, ну потом и в eclipse конечно исправил.
Теперь лишнего кода нет!!! Был 62382 стал 60140, ну как ни как, 2242 байта тоже хорошо.
Правда уровень сжатия оставляет желать лучшего. На IAR было 46030 кБ, и то в gcc я еще
выкинул код с ненужным калькулятором. Можно сказать, что 20 кБайт разницы!!! А это серьезный уже кусок.
Можно ли еще как его ужать, а то разница относительно большая?? Все, что для оптимизации было применено это -mno-interrupts и -Os.

Сообщение отредактировал factorial - Oct 3 2011, 17:49

[factorial]

А ну и -fpack-struct -fshort-enums...

[factorial]

demiurg_spb

А чтоб вообще заполировать:
CFLAGS += --combine
CFLAGS += -fwhole-program

естественно. нужно не просто добавить этот флаг а и передать все исходники компилятору разом, а не кормить по одному...

Бомба это реально, что нужно!!! Вы имели ввиду, что оптимизация будет идти не над каждым файлом отдельно, а с учетом всех файлов, я правильно понял???
Если да, то не зря после компиляции произошло сокращение: 60140 - 57596 = еще на 2544 байта меньше! Хоть что-то...., но все равно, как-то маловато.

[factorial]

Добавление -mcall-prologues еще -2048 байт....

[demiurg_spb]

Бомба это реально, что нужно!!! Вы имели ввиду, что оптимизация будет идти не над каждым файлом отдельно, а с учетом всех файлов, я правильно понял???

Правильно. Читайте доки...
http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html

CFLAGS += -Wl,--relax
CFLAGS += --param inline-call-cost=2

[Сергей Борщ]

А ну и -fpack-struct

Уберите. Вы заставляете к каждому полю любой структуры обращаться побайтово. Если в каких-то местах программ и требуется упаковка структур (например, при организации протокола обмена), то правильнее там объявить нужную структуру с атрибутом packed:

CODE

typedef struct my_type
{
.....
} __attribute__((packed));

Бомба это реально, что нужно!!! Вы имели ввиду, что оптимизация будет идти не над каждым файлом отдельно, а с учетом всех файлов, я правильно понял???

Да но есть некоторые но: 1) это работает только с С-программами (С++ забудьте) 2)в более свежих версиях этого механизма уже нет - там появился механизм LTO (link-time optimization).

[defunct]

Уберите. Вы заставляете к каждому полю любой структуры обращаться побайтово.

Для AVR это не важно. Все структуры и так упакованы побайтово.