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

Hi!
Alexey V Bugrov wrote:
Есть 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
Hi!
Dima Orlov wrote:
"Многих устраивает", "у многих есть", "многие используют" - т.к они выбирать не умеют или не из чего уже выбирать... или им лень, или боязно, или вообще всеравно. "У многих ..." - это простейший стадный принцип... пусть в стаде и живут.
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
529897 Sat Feb 05 2005 00:19, Maxim Polyanskiy wrote to Alexey Krasnov:
MP> é ×ÏÔ ÅÝÅ - ÉÚÍÅÎÉÌ Ñ ÓËÁÖÅÍ 1 ÆÁÊÌ É ÈÏÞÕ ÐÅÒÅÓÏÂÒÁÔØ. ïÔËÕÄÁ make MP> ÚÎÁÅÔ, ÞÔÏ Ñ ÉÚÍÅÎÉÌ ÉÍÅÎÎÏ ÜÔÏÔ ÆÁÊÌ? õÓÌÏÖÎÉÍ ÚÁÄÁÞÕ - Ñ ÉÚÍÅÎÉÌ 10 MP> ÆÁÊÌÏ× É ÈÏÞÕ ÐÅÒÅÓÏÂÒÁÔØ ÐÒÏÅËÔ, ËÁË make ×ÙÄÅÌÉÔ 10 ÉÚ 190?
óÒÁ×ÎÉ× ×ÒÅÍÑ ÍÏÄÉÆÉËÁÃÉÉ ÉÓÈÏÄÎÉËÏ× Ó ×ÒÅÍÅÎÅÍ ÓÏÚÄÁÎÉÑ ÏÂßÅËÔÎÉËÏ×, × ÐÒÏÓÔÅÊÛÅÍ ÓÌÕÞÁÅ (ËÏÇÄÁ ÍÏÄÉÆÉÃÉÒÕÀÔÓÑ ÓÁÍÉ ÉÓÈÏÄÎÉËÉ, Á ÎÅ ÈÉÄÅÒÙ)
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
529897 Sat Feb 05 2005 14:27, Anton Abrosimov wrote to Andy Mozzhevilov: AM>> ×ÙÚÙ×ÁÀÔÓÑ × ÐÒÏÅËÔÅ. èÏÔÑ ÅÓÔØ ËÏÍÐÉÌÑÔÏÒÙ, ËÏÔÏÒÙÅ ÄÅÌÁÀÔ ÜÔÏ É ÎÁ AM>> ÕÒÏ×ÎÅ ÏÂÙÞÎÙÈ ÏÂßÅËÔÎÉËÏ×. ARM IAR Ë ÐÒÉÍÅÒÕ, ÓÅÊÞÁÓ ËÁË ÒÁÚ Ó ÎÉÍ AM>> ËÏ×ÙÒÑÀÓØ.
AA> á ×ÏÔ ÐÏÄÓËÁÖÉ ÍÎÅ ÐÏ ÔÁËÏÍÕ ×ÏÐpÏÓÕ. õÍÅÅÔ ÌÉ ÏÎ ÓÁÍ ÄÅÌÁÔØ ÔÁÂÌÉÃÙ AA> ×ÅËÔÏpÏ× ÐpÅpÙ×ÁÎÉÊ? ÷Ï ×ÓÅÈ ÐpÉÍÅpÁÈ, ËÏÔÏpÙÅ Ñ ×ÉÄÅÌ, ÜÔÏ ÄÅÌÁÌÏÓØ AA> ×pÕÞÎÕÀ × ÁÓÓÅÍÂÌÅpÎÏÍ ÆÁÊÌÅ. éÍÈÏ ËÁË-ÔÏ ÎÅÜÓÔÅÔÉÞÎÏ. :)
ïÂÙÞÎÏ ÔÁË É ÅÓÔØ, × ÓÔÁÒÔÁÐ.ÁÓÍ ÏÂßÑ×ÌÑÅÔÓÑ ÓÅËÃÉÑ, × ËÏÔÏÒÏÊ É ÒÁÚÍÅÝÁÀÔÓÑ ×ÅËÔÏÒÁ, ÐÏÔÏÍ ÜÔÁ ÓÅËÃÉÑ ÌÉÎËÕÅÔÑ ÐÏ ÎÕÖÎÏÍ ÁÄÒÅÓÕ. ÷ ÐÒÉÎÃÉÐÅ ÍÅÎÑ ÜÔÏ ÎÅ ÓÍÕÝÁÅÔ. ôÁËÏÊ ÐÏÄÈÏÄ ÉÓÐÏÌØÚÕÅÔÓÑ ÏÞÅÎØ ÞÁÓÔÏ.
AA> é ÞÔÏ ÄÅÌÁÅÔ "pragma vector="?
÷ÏÚÍÏÖÎÏ ÜÔÏ ÁÌØÔÅÒÎÁÔÉ×ÎÙÊ ÓÐÏÓÏ ÏÂßÑ×ÉÔØ ×ÅËÔÏÒÙ ÐÒÅÒÙ×ÁÎÉÑ × ÓÅÇÍÅÎÔ intvec. HÏ ÎÁ ÄÁÎÎÙÊ ÍÏÍÅÎÔ Ñ ÅÝÅ ÄÏ ÜÔÏÇÏ ÎÅ ÄÏÂÒÁÌÓÑ. ëÒÏÍÅ ÔÏÇÏ Õ lpc2xxx c ËÏÔÏÒÙÍÉ Ñ ÓÅÊÞÁÓ É ÐÒÏÂÕÀ arm ÐÏ ÒÅÚÅÒ×ÎÏÍÕ ×ÅËÔÏÒÕ ÌÅÖÉÔ ÄÏÐÏÌÎÅÎÉÅ ÄÏ 0 ËÏÎÔÒÏÌØÎÏÊ ÓÕÍÍÙ ×ÓÅÈ ×ÅËÔÏÒÏ× ÐÒÅÒÙ×ÁÎÉÊ. üÔÏ ÉÓÐÏÌØÚÕÅÔÓÑ ÄÌÑ ÏÐÒÅÄÅÌÅÎÉÑ ×ÁÌÉÄÎÏÓÔÉ ÀÚÅÒÏ×ÓËÏÊ ÐÒÏÇÒÁÍÍÙ ×Ï ÆÌÜÛ ×ÓÔÒÏÅÎÎÙÍ ÂÕÔÌÏÁÄÅÒÏÍ. HÁ ÁÓÓÅÍÂÌÅÒÅ ÔÕÄÁ ÍÏÖÎÏ ÐÒÏÓÔÏ ÚÁÐÉÈÁÔØ ÆÉËÓÉÒÏ×ÁÎÎÏÅ ÚÎÁÞÅÎÉÅ, ÚÁÒÁÎÅÅ ×ÙÞÉÓÌÅÎÎÏÅ. á ÐÒÉ ÐÏÄÓÔÁÎÏ×ËÅ ×ÅËÔÏÒÁ ÎÁ óÉ ÐÒÁÇÍÏÊ ÐÒÉÄÅÔÓÑ ×ÉÄÉÍÏ ÄÅÌÁÔØ ËÁËÏÊ-ÔÏ ×ÎÅÛÎÅÊ ÕÔÉÌÉÔÏÊ.
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.