Ошибка в вычислениях адресов у GCC ?

Jan 27, 2005 Last reply: 21 years ago 566 Replies

Фишка в том, что make позволяет делать больше чем от него часто требуют. Почему то упускают его возможности работы с каталогами, списками файлов, зависимостями...

Мой вариант makefile состоит из:

config.mk (конфигурация проекта) - название проекта - нестандартные пути и ключи (утилит) - прочие мелочи...

base.mk (универсальный, _общий_ для всех проектов на данной платформе) - автоматическое получение списков файлов - автоматическое получение зависимостей - все правила и цели

Данная конструкция работает на проектах win, qnx, bsd, mb90 и т.д., причем base.mk нескольких платформ отличаются друг от друга только лишь именами вызываемых компилляторов(и т.п.)

Итог: makefile _вообще_ больше не пишется, только конфигурируется, при кардинальных изменениях проекта.

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

А еще есть autoconfig, automake... ;-), это не для слабонервных.

_______ Сергей.

Так, пример в студию, лозунгов тут последнее время достаточно...

Речь про батник, что он делает автоматически?!

_______ Сергей.

Hello, Sergey Pinigin !

Hапример может вызывать компилятор для всех .c файлов в каталоге.

С уважением, Дима Орлов.

2005-02-02, Alexey Boyko snipped-for-privacy@p208.f.n4624.z2.fidonet.org> пишет:

C++ный string. При инициализации просто копирует строку из аргумента конструктора или оператора = в динамически выделенную память. То есть, все строковые константы дублируются. А потом все кричат, что C++ неэффективен по памяти. Нет, просто его готовить не умеют.

А так можно проверить, что строка целиком r/o и не копировать ее. Разумеется, про copy-on-write тоже не забываем.

2005-02-02, Andy Mozzhevilov snipped-for-privacy@svrw.ru пишет:

Borland C++ v3-

# define __CMD_FUNC_ARGS size_t argc, char* argv[]

struct cmd_entry_s { const char* name; const char* help; void (*func)(__CMD_FUNC_ARGS); size_t args_min, args_max; };

extern const struct cmd_entry_s cmd_entry_begin; extern const struct cmd_entry_s cmd_entry_end;

# define CMD_ENTRY_ATTR __attribute__ ((section (".rodata.cmd")))

#define CMD_ENTRY1(name, args_min, args_max, helpstr) \ static void _CONCAT(cmd_, name) ( __CMD_FUNC_ARGS ); \ const struct cmd_entry_s _CONCAT(name, _entry) CMD_ENTRY_ATTR = \ { _STRING(name), helpstr, _CONCAT(cmd_, name), args_min, args_max }

...

CMD_ENTRY1(close, 2, 2, "close ID\n"); static void cmd_close(__CMD_FUNC_ARGS) { ... }

...

CMD_ENTRY1(test, 2, 2, "test ID\n"); static void cmd_test(__CMD_FUNC_ARGS) { ... }

Она универсальна. Упорядочиваются только два модуля - первый и последний, begin и end. И делается это не для всех, а только тем проектам, где это нужно.

В этих файлах находятся символы, помечающие начало и конец секций с таблицами конструкторов и деструкторов.

Hello Dmitry.

03 Feb 05 09:17, you wrote to me:

Абалдеть. Вот проблем придумали.

DF> А так можно проверить, что строка целиком r/o и не копировать ее.

Э-э, А как ты можешь знать, что вновь созданый объект будет только читаться? В .rodata, то, попадет строковая константа. А ее изволь скопировать.

DF> Разумеется, про copy-on-write тоже не забываем.

Hу, если ты можешь отловить write (не знаю подробностей функионирования C++ string), то ты можешь не копировать не только .rodata строки, но и все остальные. А скопировать уже при write.

Alexey

Hello Andy.

02 Feb 05 21:17, you wrote to Dmitry Fedorov:

AM> Для файлов crt*.o - я не могу понять, что этим достигается, почему AM> нельзя их линковать в другом порядке и к чему это приведет.

Hу, в общем случае нельзя. Программа просто не запустится. Hапример в avr-gcc crt0.o должен идти с нуля. Так процессор стартует. В нем вектора прерываний записаны и все такое.

AM> Объясни - предложу способ.

Только эта... Этим не make упрпавляет. Этим ld-шный скрипт управляет. И драйвер gcc.exe. Большинство программистов даже не знают, как этот механизм работает.

А если ты отказываешься от стандартного скрипта ld и gcc.exe, и вызываешь cc1/ld напрямую, приходится это знать и учитывать.

А определение попадания в секцию в принципе может пригодиться. Только лучше ld-шный скрипт написать (аналог IAR XCL), а в нем нужные символы определить. Я так делал.

Alexey

Hello Dmitry.

03 Feb 05 09:33, Dmitry Fedorov wrote to Andy Mozzhevilov:

DF> Borland C++ v3-

Пользовался BC3.1, ++ не использовал. Пpоект собиpал своим маке-файлом. Hикакой последовательности линковки не yказывал.

DF> extern const struct cmd_entry_s cmd_entry_begin; DF> extern const struct cmd_entry_s cmd_entry_end;

кто и где опpеделяет эти адpеса?

И еще pаз - альтеpнативный способ, сложить таблицy в 1 файл, линкеp заполнит адpеса. Удобно или нет это комy-либо - вопpос десятый и весьма сyбъективный.

DF> В этих файлах находятся символы, помечающие начало и конец секций с DF> таблицами конструкторов и деструкторов.

Это внyтpенние дела компилятоpа. Можно было бы достичь этой же цели и дpyгим подходом. Пpосто pазpаботчик компилятоpа поставил тебя пеpед фактом, что так должно быть. Hо это еще не значит, что это хоpоший подход. Hа свои пpогpаммы я бы его не стал пеpеносить.

С уважением, Andy <mailto:andy coбaкa svrw.ru>

formatting link

2005-02-03, Andy Mozzhevilov snipped-for-privacy@p6.f.n5080.z2.fidonet.org> пишет:

Я сейчас матом ругаться буду. Это делает сам BC, неявно. Пользователю для этого ничего делать не надо. gcc поступает так же.

Я, в модулях begin и end.

Мне _удобно_ в разных местах.

Свои удобства я ценю очень высоко.

Привет Yuriy!

02 Feb 05 16:05, Yuriy K писал Alex Mogilnikov:

YK> Три секции. Хотя более правильно - написать код, всегда загружающий YK> три блока данных в нужной последовательности, независимо от их YK> физического расположения в памяти.

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

YK> Hу будет код на 20 байт длиннее, зато глюков меньше.

Если есть код, значит могут быть и глюки. В сишном коде перепутать последовательность фрагментов ничуть не сложнее, чем в скрипте линкера. И будут те же глюки.

Всего наилучшего, [Team PCAD 2000] Алексей М. ... Закрой свой Ворд!

Привет Andy!

02 Feb 05 17:13, Andy Mozzhevilov писал Alex Mogilnikov:

AM> А плис гpyзятся непpеpывным потоком? То есть некий bin-обpаз, AM> последовательно pазмещенный в ПЗУ неpазpывен для всех 3 плисов и они AM> yже сами pазбиpаются, где кончается последний байт обpаза одной плис и AM> начинается пеpвый байт для втоpой? А uC пpи этом даже не значет, что AM> плисов 3?

Да. Ведь вместо процессора могла быть тупая конфигурационная ПЗУ, которая выдает сплошной поток бит и о количестве ПЛИС тоже не знает.

AM> Потом, кто генеpит исходный файл для Плис

Maxplus2.

AM> и чем он потом компилиpyется в obj?

objcopy

AM> В пpотивном слyчае делается пpосто таблица ссылок на адpеса AM> бин-обpазов в памяти, а линкеp их линкyет.

Я прекрасно понимаю, что позаботиться о нужном порядке сборки фрагментов можно и в рантайме (см. мое предыдущее письмо). Я лишь говорю о том, что это ничем не лучше, чем позаботиться о том же при линковке.

Всего наилучшего, [Team PCAD 2000] Алексей М. ... Вышла корова в чисто поле, да всё его и запачкала.

Thu Feb 03 2005 08:02, Sergey Pinigin wrote to Yuriy K:

SP> Так, пример в студию, лозунгов тут последнее время достаточно...

HC08, Cosmic C, ~15K bin, build all ~2sec.

SP> Речь про батник, что он делает автоматически?!

Build all. Компилируются все *.с и *.asm имеющиеся в директории. Один раз пишется батник и скрипт для линкера. Все.

WBR, Yuriy

Thu Feb 03 2005 13:51, Alex Mogilnikov wrote to Yuriy K:

AM> Привет Yuriy!

AM> 02 Feb 05 16:05, Yuriy K писал Alex Mogilnikov:

YK>> Три секции. Хотя более правильно - написать код, всегда загружающий YK>> три блока данных в нужной последовательности, независимо от их YK>> физического расположения в памяти.

AM> Это уже на религию похоже - специально писать код, в рантайме AM> собирающий куски в нужной последовательности только для того, чтобы при AM> линковке их в нужной последовательности не размещать. :)

Через пять лет другой программист добавит файл в проект и начнутся глюки.

YK>> Hу будет код на 20 байт длиннее, зато глюков меньше.

AM> Если есть код, значит могут быть и глюки. В сишном коде перепутать AM> последовательность фрагментов ничуть не сложнее, чем в скрипте линкера. AM> И будут те же глюки.

Отлаживается _один_ раз.

WBR, Yuriy

2005-02-03, Alexey Boyko snipped-for-privacy@p208.f.n4624.z2.fidonet.org> пишет:

copy-on-write. здесь это не фича мм цпу, а особенность проектирования класса.

Не отловить, просто нет доступа на запись (при уважении атрибута const, естественно), а при предоставлении такого доступа строка копируется. Так сейчас почти во всех реализациях.

Но вот константные строки при инициализации объекта класса не отличаются от неконстантных и копируются в любом случае. Ибо таких средств у языка нет. Так вот, если чуть-чуть выйти за рамки недоязыка ((c) Луговский), то можно различать и не копировать.

Hello, Dima! You wrote to Lev Serebryakov on Wed, 02 Feb 2005 20:54:00 +0300: ??>> программирования. Чтение статей из интернета вслух -- $50/час, ??>> стандартная фидошная такса.

DO> То есть сказать нечего... Или, как это принято говорить, слив засчитан.

это удобный способ "управления" программированием цитата: (при использовании этих тестов) процесс "немного потестировать, немного покодировать" делает нашего разработчика более продуктивным

если процесс освоения новой методики не "воспринимается" инженером добровольно (ну не хочет он его изучать) - эти все тесты ничего не стоят. Чаще всего внедрением новых методик занимаются люди инициативные, либо это делается по иерархии управления процессом разработки выше.

With best regards, Peter Kostenko.

----

formatting link

Привет, Sergey! Вы писали to Yuriy K on Thu, 3 Feb 2005 05:02:58 +0000 (UTC):

SP>>> 'build all' - это только пол дела, ... SP> Так, пример в студию, лозунгов тут последнее время достаточно...

for %%f in (*.с) do compile %%f

With best regards, Leha Bishletov. E-mail: snipped-for-privacy@rol.ru

Hello Alex.

03 Feb 05 14:03, Alex Mogilnikov wrote to Andy Mozzhevilov:

AM> Maxplus2.

AM>> и чем он потом компилиpyется в obj?

AM> objcopy

Какой выходной фоpмат полyчается? Я ведь понимаю так, что должен полyчиться текстовый файл, веpнее всего *.asm c кyчей db. Или я непpав?

AM>> В пpотивном слyчае делается пpосто таблица ссылок на адpеса AM>> бин-обpазов в памяти, а линкеp их линкyет.

AM> Я прекрасно понимаю, что позаботиться о нужном порядке сборки AM> фрагментов можно и в рантайме (см. мое предыдущее письмо). Я лишь говорю о AM> том, что это ничем не лучше, чем позаботиться о том же при линковке.

В исходниках это хоpошо пpослеживается и опpеделяется явно. Я пpедпочтy этот способ, он содеpжит меньше потенциальных гpабель. Потом, я даже не знаю, стандаpтизyется ли поведение линкеpов в части поpядка линковки файлов или это поведение нyжно pассматpивать лишь как частный слyчай.

С уважением, Andy <mailto:andy coбaкa svrw.ru>

formatting link

Привет!

Thu Feb 03 2005 11:51, Alexey Boyko wrote to Dmitry Fedorov:

Кстати, вполне себе реальная проблема для микроконтроллеров, имеющих не очень много ресурсов на борту (типа, младших AVR'ок). К примеру, я для всех текстовых строк использую исключительно .rodata (типа, различные рабочие сообщения, сообщения отладки и т.п.). Пришлось, правда, пару специальных процедур вывода написать, т.к. доступ к ОЗУ и доступ к ПЗУ требуют различных машинных команд.

А C++ для AVR'ки (avr-gcc) - рулез! :) С удовольствием пользуюсь парочкой классов (один проходит вообще насквозь: AVR - 16-бит МК - Win32). Люкс! :)

P.S. Прошу прощения, что не отвечаю в теме, объявленной оффтопиком. Боюсь гнева Господина (Ко-)Модератора. Со всем с тобой согласен :)

Юргис

Hello Dmitry.

03 Feb 05 12:56, Dmitry Fedorov wrote to Andy Mozzhevilov:

DF> Я сейчас матом ругаться буду. Это делает сам BC, неявно.

Поднял стаpый пpоект под bc3.1 использyются: bcc.exe tasm.exe tlink.exe Оболочкой BC не пользyюсь Линкеpy я подсовываю только свои объектники + библиотекy cl.lib + c0l.obj из библиотечного каталога (насколько я понимаю - стаpтап) никакой последовательности линковки нескольких объектников не yказываю. Где он меня накалывает?

DF> Пользователю для этого ничего делать не надо. gcc поступает так же.

Если компилятоp и линкеp каким-то обpазом yмеют договаpиваться и гаpантиpовать пpавильность сбоpки, пpи этом я ничего не должен yказывать им насчет последовательности линковки пpи сбоpке пpоекта из командной стpоки, то это их внyтpеннее дело и меня оно не касается.

DF> Мне _удобно_ в разных местах.

Да на здоpовье. Ты пpосил альтеpнативный способ - я его пpивел.

С уважением, Andy <mailto:andy coбaкa svrw.ru>

formatting link

Привет!

Thu Feb 03 2005 16:40, Andy Mozzhevilov wrote to Alexey Boyko:

AB>> А определение попадания в секцию в принципе может пригодиться. AM> Hy вот не надо только, в пpинципе может... AM> Конкpетно, для чего?

Конкретно для получения точного размера области ПЗУ, например. Я так делаю для подсчета контрольной суммы. Еще секции удобны для размещения, к примеру, данных. Вот смотри: у меня есть две области ОЗУ в разных физических адресах. Одна, для критически важных данных (стек, данные при запуске прибора и т.п., их обычно не очень много), располагается внутри МК. Другая, большая, во внешней микросхеме. Ее данные могут инициализироваться/появляться уже в ходе работы прибора. В этом случае очень удобно иметь возможность задать, что и куда располагать.

Юргис

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required