Странное поведение 5.10 при компиляции в C++ Опции

[alexander55]

Добрый день!
Обнаружил следующую неприятность в IAR версии 5.10.
Привожу вариант, который каждый может попробовать.

IAR С-примерчик с одним прерыванием по таймеру при выборе языка C успешно компилируется и в ARM и Thumb (и в RAM и во Flash).
Если выбрать любую вариацию C++ объектные файлы образуются, а на этапе сборки говорит, что
нет определения для вектора IRQ_ISR_Handler.
Привожу текст для RAM (под Flash аналогично) .

Building configuration: TimerInt - JLINK_RAM
Updating build tree...
Linking
Error[Li005]: no definition for "IRQ_ISR_Handler" [referenced from C:\ARM_Projects\Education\
IAR-LPC-214X\TimerInt\Project\JLINK_RAM\Obj\lpc2xxx_cstartup.o]
Error while running Linker

Total number of errors: 1
Total number of warnings: 0

Какие есть мысли.

[zltigo]

Какие есть мысли.

Мысли обычные - соглашения о преобразовании имен в С++ другие. IRQ_ISR_Handler() должен быть объявлен, как сишный, иначе из ASM черт ногу сломит вызывая его.

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

Привожу текст для RAM (под Flash аналогично) .
....
Какие есть мысли.

Текст видать кто-то покоцал. А мысль одна: переводя слова zltigo extern "C" __arm __irq void IRQ_ISR_Handler()
{
......
}
А чтобы компилилось в обоих режимах -

Код

#include <yvals.h>
_EXTERN_C  __arm __irq void IRQ_ISR_Handler()
{
......
}
_END_EXTERN_C

насчет yvals.h - возможно в 5.10 он имеет другое название, но в предыдущих он подключается автоматически через любой из библиотечных заголовочных файлов (через тот же stdint.h)

[alexander55]

Удалось решить проблему следующим образом.
В startup и С модулях заменил
IRQ_ISR_Handler на IRQ_Handler.
После этого компилится нормально и С и в EC++ и в EEC++.
Я просмотрел примеры для других ARM uC там везде irq_handler и fiq_handler. У LPC (автор Стадомир Бонев - кажется, он с Olimex) часть irq_isr_handler, fiq_isr_handler, часть irq_handler, fiq_handler.
В документации IAR везде одназначно рекомендуется irq_handler, fiq_handler.

PS. Поздравляю всех с победой нашей сборной на eurobasket-2007.

[zltigo]

В startup и С модулях заменил
IRQ_ISR_Handler на IRQ_Handler.

Полная ерунда. Можете хоть горшком называть - что-то походя еще подправили.

[alexander55]

Полная ерунда. Можете хоть горшком называть - что-то походя еще подправили.

Я также считал, а сейчас во всем уже сомневаюсь.

Сейчас проверил. Название важно для startup, для С может даже не совпадать со startup овским.
Там важен даже регистр, т.е. IRQ_Handler проходит, а irq_handler нет.

Сообщение отредактировал alexander55 - Sep 17 2007, 06:12

[zltigo]

а сейчас во всем уже сомневаюсь.

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

[alexander55]

"Сейчас проверил. Название важно для startup, для С может даже не совпадать со startup овским.
Там важен даже регистр, т.е. IRQ_Handler проходит, а irq_handler нет."
Кажется нашел, ответы на стр.31-32 DevelopmentGuide.pdf. Как ни странно, совпало с моими субъективными ощущениями.

[zltigo]

Там важен даже регистр, т.е. IRQ_Handler проходит, а irq_handler нет."

Удивительно-то как! Оказывается в 'C' важен регистр, удивление мое не знает границ

Кажется нашел, ответы на стр.31-32 DevelopmentGuide.pdf. Как ни странно, совпало с моими субъективными ощущениями.

Повторяю, мне неведомо, что Вы там шаманите, какой startup редактируете, какой ассемблируете и какой в конце концов линкуете, и уж что такое в DevelopmentGuide.pdf страшное могли вычитать, но имя функции обработчика прерывания может быть любым.

[alexander55]

но имя функции обработчика прерывания может быть любым.

Да это так, но не в startup.

[zltigo]

Да это так, но не в startup.

Все, больше слов нет .
Срочно покупайте бубен, для дальнейшей "программерской деятельности" он Вам очень поможет.

[alexander55]

Все, больше слов нет .
Срочно покупайте бубен, для дальнейшей "программерской деятельности" он Вам очень поможет.

Купил бубен и продолжил исследование. Для меня истина дороже.
В результате шаманской деятельности все выяснил.
При компиляции в EC++ и EEC++ пропадает (бесследно)
__vector_0x14: DC32 0 ; RESERVED
При компиляции в C все ОК.
Выключены все оптимизации.

Выход, как всегда, есть. Но интересны соображения уважаемых коллег.

[alexander55]

Спасибо всем (Zltogo и особенно Сергею Борщ). Все работает.
Я уже такого накрутил, что сам запутался.
Ключевой момент это
_EXTERN_C __arm __irq void IRQ_ISR_Handler()
{
......
}
_END_EXTERN_C

PS. Прошу не расстреливать за паникерство.

Сообщение отредактировал alexander55 - Sep 19 2007, 11:41

[IgorKossak]

PS. Прошу не расстреливать за паникерство.

Наоборот, обьявляю благодарность за терпимость, самокритичность и чувство юмора!

[alexander55]

Наоборот, обьявляю благодарность за терпимость, самокритичность и чувство юмора!

Спасибо, приятно когда тебя понимают.