Добрый день (вечер/ночь/утро)!

Пишу на С++.

Проблема первая: Если обьект, определенного мной типа, расположить вне 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)

Посмотрите в .map, в какую входную секцию попадает ваш объект. И в скрипте линкера - в какую выходную секцию линкуется эта входная и как объявлена выходная секция.
Рискну предположить, что это код поддержки исключений или RTTI и для него надо подключать какую-то другую libc. Попробуйте отключить исключения и RTTI: CPP_FLAGS += -fno-exceptions -fno-rtti

Спасибо. Флаги -fno-exceptions -fno-rtti помогли.



Извините, не понял. Вот фрагмент 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)
}
}

Это я неточно выразился. Попробуйте arm-elg-objdump -h -S -C file.elf > file.lss Файл .lss будет начинаться с перечня выходных секций и их флагов, примерно такого:покажите его (естественно, для файла с объектом Chip), будем думать дальше.

Жаль нету смайлика "бъет себя по лбу со словами 'Семен Семеныч!' "
При размещении объекта статически вызов его конструктора кладется в секцию *.ctors а деструктора - в *.dtors

Поскольку эта входная секция у вас никуда не кладется, линкер создает для нее одноименную выходную секцию, а размещает ее после последней описанной вами секции, т.е. после .bss

Большее спасибо!

Проблема разрешилась. Однако суть происходящего мне не очень ясна.



Я правильно понимаю, что эта одноименная секция в выходном elf файле как-то неправильно описана (размер или конец не помечен), и поэтому objcopy выдает кривой bin файл?

А есть какой-нибудь хороший-хороший мануал по работе линкера?

Начну с концаСобственно, на сайте binutils описание ld. Там особое внимание уделить описанию скриптов.
Нет. В вашем случае, линкер встретил секцию ctors и положил ее следом за последней уложенной секцией, т.е. за .bss. При этом секция содержала флаги CONTENTS, ALLOC, LOAD, READONLY, CODE. А когда формировался bin-файл, objcopy вынуждена была чем-то заполнить пустое место между концом text и началом ctors. Если бы вы сформировали .hex вместо .bin, то увидели бы, что в файле есть участок кода с 0000000 по какой-то адрес и потом еще один участок с 0x40000...