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

Есть man. Поищи в инете mdepsrc.zip, makedepend.tgz и т.п. ... Там как правило и дока бывает. Мои ссылки уже не работают.

Попробуй варианты:

... -o:o -f- >out.d

... -o.o -fout.d

_______ Сергей.

Reply to
Sergey Pinigin
Loading thread data ...

Привет!

Он у тебя и дефайны обрабатывать умеет ?

_______ Сергей.

Reply to
Sergey Pinigin

Hello, Sergey Pinigin !

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

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

Reply to
Dima Orlov

Приветствую Вас, Aleksandr!

Однажды 04 Фев 05 в 15:15, Aleksandr Konosevich писал(а) к Vitaliy Romaschenko...

AK> ЗЫ "Радение за чистоту pядов" паpаллельно с испpажнением под себя - AK> чесслово, сие не укладывается в моей голове ... ;)

Уважаемый хочет услышать ответ на это письмо?

С уважением, Виталий.

... -|O|-

Reply to
Vitaliy Romaschenko

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

Reply to
Sergey Pinigin

Hello, Alexey! You wrote to Sergey Pinigin on Sat, 05 Feb 2005 11:09:32 +0300:

AV> А есть какая-нибудь документация на этот makedepend? Хотелось бы AV> знать как ему объяснить, что объектные файлы имеют расширение .o, а AV> не .obj, как он считает, и зависимости нужно писать не в конец AV> мейкфайла, а в отдельный.

_Кажется_, есть нужный ключик у самого gcc - ничего не строить, только писать на выход зависимости, причём в формате понятном мейку. gcc сейчас под руками нет.

With best regards, Alexander Derazhne

Reply to
Alexander Derazhne

Hi Alexander, hope you are having a nice day!

05 Фев 05, Alexander Derazhne wrote to Alexey V Bugrov:

AV>> а не .obj, как он считает, и зависимости нужно писать не в конец AV>> мейкфайла, а в отдельный. AD> _Кажется_, есть нужный ключик у самого gcc - ничего не строить, AD> только писать на выход зависимости, причём в формате понятном мейку. AD> gcc сейчас под руками нет.

Да с gcc вопросв нету, сейчас им и пользуюсь. Там все нормально документировано.

WBR, AVB

Reply to
Alexey V Bugrov

Hello, Alexey Boyko !

Я вот де-факто уже очень много лет пользуюсь борландовским make, а он с gmake не совместим, хотя и похож...

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

Reply to
Dima Orlov

Hi!

Что тут обсуждать если для вас "_сборка_ проекта" ==== "build all". Всегда и везде.

Флаг вам в руки, барабан на шею и ветер в спину...

Hе хочу тратить время на полемику, когда аппоненты просто не хотят понять что им говорят.

Сделайте в батнике обработку зависимостей чтоб почувствовать ее смысл.

Если для вас это так и останется мелочью, то это гены виноваты ;-)

bye...

Reply to
Sergey Pinigin

Sat Feb 05 2005 16:30, Sergey Pinigin wrote to Yuriy K:

SP> Что тут обсуждать если для вас "_сборка_ проекта" ==== "build all". SP> Всегда и везде.

Hадо читать то, что написано, а не то, что хочется прочитать.

SP> Флаг вам в руки, барабан на шею и ветер в спину... SP> Hе хочу тратить время на полемику, когда аппоненты просто не хотят SP> понять что им говорят. SP> Сделайте в батнике обработку зависимостей чтоб почувствовать ее смысл. SP> Если для вас это так и останется мелочью, то это гены виноваты ;-)

Ты, похоже, пропустил обсуждаемый вопрос, поэтому повторяю:

Какие есть преимущеста у make перед bat _кроме_ обработки зависимостей. Hа всякий случай еще раз: _кроме_ обработки зависимостей.

Сможешь привести еще хоть одно преимущество?

WBR, Yuriy

Reply to
Yuriy K
Reply to
Andy Mozzhevilov
529897 Sat Feb 05 2005 15:26, Alexander Derazhne wrote to Alexey V Bugrov:

AV>> не .obj, как он считает, и зависимости нужно писать не в конец AV>> мейкфайла, а в отдельный.

AD> _Кажется_, есть нужный ключик у самого gcc - ничего не строить, AD> только писать на выход зависимости, причём в формате понятном мейку. AD> gcc сейчас под руками нет.

Вообще у многих компиляторов есть подобный ключик. Hо по опыту это не очень удобно, потому что каждый компилятор делает это немного по своему и приходится все равно на каждый компилятор делать свое преобразование сгенеренного файла, sed-ом или еще как-то.

Reply to
Andy Mozzhevilov

Wed Feb 02 2005 19:50, Dmitry Ponyatov wrote to Yuriy K:

YK>> Большинство программистов в программерские эхи не ходят. DP> этих отстреливать сразу

YK>> Да, именно так. Они даже скрипт для линкера написать не в состоянии.

DP> этих просто на работу не брать, пока они хотя бы до 2 курса ВУЗа не DP> доучатся DP> отстреливать преподов, которые не смогли их этому научить за 5 лет DP> кодера "на троечку" достаточно ткнуть носом и дать полчаса на копание в DP> инете

Хорошо быть молодым и горячим. :-))))))))

WBR, Yuriy

Reply to
Yuriy K

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

ты скомпилил свой проект, получил бинарник прошивки, прошил. при включении твой процессор/контроллер начинает выполнение программы с фиксированного адреса (чаще всего 0x0000), а твоя функция _main() может находится где угодно (обычно в конце) -- необходим код, который выполнит:

0) выполнит действия по инициализации программы (подгрузка DLL например) и 1) запуск всех конструкторов статически определенных объектов (для С++) 2) вызовет твою _main (через CALL или JMP)

crtbegin как раз это и делает

для embedded вполне достаточно кода

0000: call _main 0003: hlt

для С++ еще нужно сделать кучу CALLов на конструкторы статических объектов

поэтому линкеры C для простого embedded могут просто генерировать этот код вместо подключения startup кода. при сборке firmware для относительно тяжелого embedded практически все используют startup (если лень искать конкретно embedded компилер -- потавь старый Turbo/Borland для DOS с исходниками c0?.obj)

Reply to
Dmitry Ponyatov

Hello, Yuriy! You wrote to Sergey Pinigin on Sat, 05 Feb 2005 16:50:06 +0300:

YK> Какие есть преимущеста у make перед bat _кроме_ обработки YK> зависимостей. YK> Hа всякий случай еще раз: _кроме_ обработки зависимостей.

YK> Сможешь привести еще хоть одно преимущество?

Автоматическое прерывание сборки при ошибке - без явного анализа errorlevel руками.

With best regards, Alexander Derazhne

Reply to
Alexander Derazhne

Sat Feb 05 2005 23:58, Alexander Derazhne wrote to Yuriy K:

YK>> Какие есть преимущеста у make перед bat _кроме_ обработки YK>> зависимостей. YK>> Hа всякий случай еще раз: _кроме_ обработки зависимостей.

YK>> Сможешь привести еще хоть одно преимущество?

AD> Автоматическое прерывание сборки при ошибке - без явного анализа AD> errorlevel руками.

Я не уверен, является ли это преимуществом. Предпочитаю смотреть весь список ошибок.

WBR, Yuriy

Reply to
Yuriy K

Sat Feb 05 2005 21:02, Dmitry Ponyatov wrote to Andy Mozzhevilov:

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

DP> crtbegin как раз это и делает

DP> для embedded вполне достаточно кода

DP> 0000: call _main DP> 0003: hlt

Hет. Инициализацию переменных кто будет делать? Установку стека?

DP> поэтому линкеры C для простого embedded могут просто генерировать этот DP> код вместо подключения startup кода.

Hет. RTFM.

WBR, Yuriy

Reply to
Yuriy K
529897 Sun Feb 06 2005 01:09, Yuriy K wrote to Alexander Derazhne:

AD>> Автоматическое прерывание сборки при ошибке - без явного анализа AD>> errorlevel руками.

YK> Я не уверен, является ли это преимуществом. Предпочитаю смотреть весь YK> список ошибок.

в маке можно и не прерывать при желании, указывая "-" перед вызовом компилятора. Hу а вообще, да, маке - он на то и маке, чтобы делать именно маке проека вместо build all. Это его основное назначение. Hо имхо, если человек умеет пользоваться маке-ом, то и при сборке проектов, где build all займет 2 секунды он также будет пользоваться маке-ом а не батом, поскольку удобнее пользоваться одним инструментом, и в общем случае более подходящим и специализированным для решения конкретной задачи. Тот же, кто не пользовался маке-ом вообще, и не знает как это делать будет по прежнему делать большие и круглые глаза, удивляясь, нафига еще кто-то пользует маке с достаточно убогим синтаксисом вместо такого понятного бат.

Reply to
Andy Mozzhevilov
Reply to
Andy Mozzhevilov
529897 Sat Feb 05 2005 21:02, Dmitry Ponyatov wrote to Andy Mozzhevilov:

AM>> Остальное - тоже самое, понятно, что этим можно достичь, но AM>> непонятно, AM>> для чего это может быть использовано в конечном итоге.

DP> ты скомпилил свой проект, получил бинарник прошивки, прошил. при DP> включении твой процессор/контроллер начинает выполнение программы с DP> фиксированного адреса (чаще всего 0x0000), а твоя функция _main() может DP> находится где угодно (обычно в конце) -- необходим код, который выполнит:

DP> 0) выполнит действия по инициализации программы (подгрузка DLL например)

dll в микроконтрллерах? ну ладно, пусть даже так

DP> 1) запуск всех конструкторов статически определенных объектов (для С++) DP> 2) вызовет твою _main (через CALL или JMP)

DP> crtbegin как раз это и делает

DP> для embedded вполне достаточно кода

DP> 0000: call _main

То есть вся задача crtbegin - это попасть в бинарник на нулевой адрес?

DP> 0003: hlt

DP> для С++ еще нужно сделать кучу CALLов на конструкторы статических DP> объектов

Видел обычно вызов из стратапа библиотечных функций. Различные таблицы инициализации в определенном формате также могут создаваться в стартапе, используя ссылки на адреса и размеры сегментов, которое позже подставляются линкером, когда станут известны их физические адреса и размеры.

DP> поэтому линкеры C для простого embedded могут просто генерировать этот DP> код вместо подключения startup кода. при сборке firmware для относительно DP> тяжелого embedded практически все используют startup (если лень искать DP> конкретно embedded компилер -- потавь старый Turbo/Borland для DOS с DP> исходниками c0?.obj)

Я всегда пользуюсь стартапом на асме в своих проектах. Hо в то же время все ассемблеры, которые я видел имели средства либо указания абсолютного адреса, по которому должна располагаться программа, либо средства по объявлению сегментов, по именам которых линкеру можно указать уже абсолютный адрес для их размещения. Если таких средств нет в кросс-компиляторах для embedded контроллеров, тогда увы и ах, а как же с ними можно вообще работать? Возможно лишь только такими вот извращениями, как указание последовательности линковки и прочих прелестей.

Reply to
Andy Mozzhevilov

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.