NikAn 0 14 июля, 2008 Опубликовано 14 июля, 2008 · Жалоба Добрый день (вечер/ночь/утро)! Пишу на С++. Проблема первая: Если обьект, определенного мной типа, расположить вне main (т.е. он будет глобальным), компоновщик генерирует странный elf файл. Странность его в том, что утилита arm-elf-objcopy делает из него бинарный файл размером 1ГБ (~1КБ эффективного кода + куча нулей). Проблема вторая: Имеется такой код int main(void) { CHIP Chip; SINGLE_PORT X13_20; // X13_20.Init(0, OUTPUT, PULL_UP); // X13_20.NewConnect(&Chip, P0, 4); /*.........................*/ } Если раскоментировать методы обьекта X13_20, компоновщик arm-elf-ld вываливает следующие сообщения: main.cpp:46: undefined reference to `_Unwind_SjLj_Register' main.cpp:67: undefined reference to `_Unwind_SjLj_Resume' main.cpp:67: undefined reference to `__gxx_personality_sj0' строки 46 и 67 соответственно начало и конец main Подскажите, чтобы это могло означать Заранее благодарен Косяк видимо связан с явными деструкторами (см. http://electronix.ru/forum/index.php?showtopic=49880) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Сергей Борщ 119 14 июля, 2008 Опубликовано 14 июля, 2008 · Жалоба objcopy делает из него бинарный файл размером 1ГБ (~1КБ эффективного кода + куча нулей).Посмотрите в .map, в какую входную секцию попадает ваш объект. И в скрипте линкера - в какую выходную секцию линкуется эта входная и как объявлена выходная секция. main.cpp:46: undefined reference to `_Unwind_SjLj_Register'Рискну предположить, что это код поддержки исключений или RTTI и для него надо подключать какую-то другую libc. Попробуйте отключить исключения и RTTI: CPP_FLAGS += -fno-exceptions -fno-rtti Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
NikAn 0 15 июля, 2008 Опубликовано 15 июля, 2008 · Жалоба Спасибо. Флаги -fno-exceptions -fno-rtti помогли. Посмотрите в .map, в какую входную секцию попадает ваш объект. И в скрипте линкера - в какую выходную секцию линкуется эта входная и как объявлена выходная секция. Извините, не понял. Вот фрагмент main.map .bss 0x40000004 0x154 *(.bss) .bss 0x40000004 0x0 strup.o .bss 0x40000004 0x0 std_def.o .bss 0x40000004 0x0 ChipResource.o .bss 0x40000004 0x0 SinglePort.o .bss 0x40000004 0x154 main.o 0x40000008 InputBuf 0x40000144 Chip 0x40000138 OutputBufTail 0x4000010c InputBufTail 0x40000140 flag 0x40000004 TIMER0_IntFunc и т.д. Глобальный объект Chip вызывает описанный выше косяк А вот скрипт линкера: MEMORY { rom (rx) : ORIGIN = 0x00000000, LENGTH = 512K ram (rw) : ORIGIN = 0x40000000, LENGTH = 64K } SECTIONS { .text : { *(.text) } >rom .data : { *(.data) } >ram .bss : { *(.bss) } } Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Сергей Борщ 119 15 июля, 2008 Опубликовано 15 июля, 2008 · Жалоба Извините, не понял. Вот фрагмент main.mapЭто я неточно выразился. Попробуйте arm-elg-objdump -h -S -C file.elf > file.lss Файл .lss будет начинаться с перечня выходных секций и их флагов, примерно такого:Sections: Idx Name Size VMA LMA File off Algn 0 .text 0000092c 00200000 00200000 00008000 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 1 .bss: 000002e0 0020092c 0020092c 0000892c 2**2 ALLOC 2 .stack 00000400 00200c0c 00200c0c 0000892c 2**0 ALLOC 3 .comment 0000005a 00000000 00000000 0000892c 2**0 CONTENTS, READONLY покажите его (естественно, для файла с объектом Chip), будем думать дальше. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Сергей Борщ 119 15 июля, 2008 Опубликовано 15 июля, 2008 · Жалоба А вот скрипт линкера: Жаль нету смайлика "бъет себя по лбу со словами 'Семен Семеныч!' " При размещении объекта статически вызов его конструктора кладется в секцию *.ctors а деструктора - в *.dtors .text : { *(.text*) __ctors_start = .; *(.ctors) __ctors_end = .; __dtors_start = .; *(.dtors) __dtors_end = .; KEEP(SORT(*)(.ctors)) KEEP(SORT(*)(.dtors)) *(.rodata*) /* read-only data (constants) */ } >rom Поскольку эта входная секция у вас никуда не кладется, линкер создает для нее одноименную выходную секцию, а размещает ее после последней описанной вами секции, т.е. после .bss Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
NikAn 0 16 июля, 2008 Опубликовано 16 июля, 2008 · Жалоба Большее спасибо! :a14: Проблема разрешилась. Однако суть происходящего мне не очень ясна. Поскольку эта входная секция у вас никуда не кладется, линкер создает для нее одноименную выходную секцию, а размещает ее после последней описанной вами секции, т.е. после .bss Я правильно понимаю, что эта одноименная секция в выходном elf файле как-то неправильно описана (размер или конец не помечен), и поэтому objcopy выдает кривой bin файл? А есть какой-нибудь хороший-хороший мануал по работе линкера? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Сергей Борщ 119 16 июля, 2008 Опубликовано 16 июля, 2008 · Жалоба Начну с конца А есть какой-нибудь хороший-хороший мануал по работе линкера?Собственно, на сайте binutils описание ld. Там особое внимание уделить описанию скриптов. Я правильно понимаю, что эта одноименная секция в выходном elf файле как-то неправильно описана (размер или конец не помечен), и поэтому objcopy выдает кривой bin файл?Нет. If you do not use a SECTIONS command in your linker script, the linker will place each input section into an identically named output section in the order that the sections are first encountered in the input filesВ вашем случае, линкер встретил секцию ctors и положил ее следом за последней уложенной секцией, т.е. за .bss. При этом секция содержала флаги CONTENTS, ALLOC, LOAD, READONLY, CODE. А когда формировался bin-файл, objcopy вынуждена была чем-то заполнить пустое место между концом text и началом ctors. Если бы вы сформировали .hex вместо .bin, то увидели бы, что в файле есть участок кода с 0000000 по какой-то адрес и потом еще один участок с 0x40000... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться