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

Reply to
Anton Abrosimov
Loading thread data ...

Hello Yuriy.

07 Feb 05 19:09, you wrote to me:

AB>> Итого предлагается написать make на bat'е? YK> Предлагается объяснить преимущества make перед bat. YK> Одно есть: ускорение сборки больших проектов. YK> Приведи еще одно.

При использовании make не нужно писать его функциональность на bat-файлах.

AB>> ps: Возьмите вместо bat, какой-нить bash или tcsh. Или WSH AB>> (Windows Scripting Host) YK> Зачем?

Hу, на них писать удобнее, чем на bat.

Alexey

Reply to
Alexey Boyko

Mon Feb 07 2005 19:42, Ilya Anfimov wrote to Yuriy K:

IA> Удобный синтаксис для преобразований IA> файлов по расширениям.

Удобный? 8-0 Оно конечно, на вкус и на цвет... Мне цикл for гораздо понятней.

WBR, Yuriy.

Reply to
Yuriy K
7-Feb-05 09:16 Sergey Pinigin wrote to Oleksandr Redchuk:

SP> В этом заслуга rar'а, а стандартная команда "cd" это не поймет (под SP> W98). Даже не rar-а. Специально только что перегрузился в 98-ю и проверил.

// foo.c #include <stdio.h>

int main(int ac, char **av) { FILE *fp; if(ac < 3) return 1; fp = fopen(av[1], "wt"); if( !fp) { puts("A-a-a!"); return 1; } fprintf( fp, "%s", av[2]); fclose(fp); return 0; }

c:\>foo c:/temp/foo.txt Kwa!

Прекрасно создало файл foo.txt в каталоге c:/temp и записало в него что просили.

Многое виндовое встроенное просто по прямому слешу ключ ждёт, вот и не берёт его в именах файлов.

WBR,

Reply to
Oleksandr Redchuk
7-Feb-05 09:27 Sergey Pinigin wrote to Yuriy K:

SP> Да:

SP> - легко организуется компиляция "тонких мест" - могу в одной строке SP> записать что один из 102 файлов компилить с отличными от default SP> ключиками.(не важно где он лежит, и какой build выполняется) И что тоже можно сделать в батнике, если уж упираться в вопрос "а что такого моежт make, что не может bat". Но только задавая правила, а не действия - на мой взгляд это сделать проще.

Wbr,

Reply to
Oleksandr Redchuk
6-Feb-05 23:25 Maxim Polyanskiy wrote to Oleksandr Redchuk:

MP>>> А как можно в этих 200 файлах разбиратся, что в каком? OR>> А зачем??? MP> Элементарно - для поддержки проекта. Тьху ты, это я глюкнул. Имелось ввиду зачем для этого (разбора/поддержки) держать всё в одном файле?.

MP> Все без проблем находится в одном MP> исходнике размером меньше в 4 раза чем было и понятнее в 5 раз. Ну а я хочу сказать, что всё без проблем находится и в толпе исходников, только раньше нужно было какие-то телодвижения сделать (прикрутить к Qedit несколько макросов на горячие клавиши и grep вытащить в доступное по path место), а сейчас любой минимально-приличный программистский редактор это сам умеет.

OR>> И ещё был макрос, который хватал слово под курсором и открывл файл с OR>> таким именем - это уже для хождения по выдаче grep. MP> А я тогда искал входы в процедуры через ctrl+f в том-же qedit в исходнике MP> максимум из 3 файлов и не знал про существование таких заморочек ;) Кстати, вот как раз *тогда* make экономил время пересборки даже на мелких проектах во много раз. Особенно на дискетах :-)

OR>> Так что поиск - не аргумент, и я не пойму, зачем держать всё в одном OR>> мегабайтном файле? MP> Hе знаю - привычно как-то. А мне привычно через make. И даже если сейчас время build all занимает несколько секунд, а время make - одну - мне гораздо проще и привычнее задавать правила функционирования, чем конкретные действия.

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

OR>> зависит. Если foo.obj свежее всех, то ничего не делаем. Иначе OR>> перекомпилируем его. OR>> И так 190 раз, но только для 10 файлов будет вызвана перекомпиляция. MP> Я почему-то не уверен что все это радикально ускорит работу. Сборку небольшого проекта (у меня сейчас все такие)? Ускорит радикально, но незаметно :-) В 3 раза - радикально? Радикально. С 6 секунд до 2 - заметно? Да не очень.

MP> Среднепаршивый проект собирается весь за секунды, а на изучение синтаксиса MP> make MP> для создания правильных файлов в целом можно не один день жизни потратить. MP> Выгода сомнительна. Лучше купить лишний жирный процессор винт побыстрее MP> и памяти побольше ;) С одной стороны да. Скажем, по этой причине я когда-то обломился прикручивать make к pcad4.5 :-) Но факт - тогда для многолистовой схемы с изменением на одном листе через make изменения в плату вбрасывались в разы быстрее, чем через сгенерённый PCECO батник. А с другой - почему-то если зашивка процессора сокращается с 10 секунд до

5, то народ радуется, а вот растянуть сборку с 5 до 10 - так вроде бы и нормально.

wbr,

Reply to
Oleksandr Redchuk

Hello, Yuriy! You wrote to Sergey Pinigin on Mon, 07 Feb 2005 19:21:17 +0300:

SP>> - легко организуется компиляция "тонких мест" - могу в одной SP>> строке записать что один из 102 файлов компилить с отличными от SP>> default ключиками.(не важно где он лежит, и какой build SP>> выполняется)

YK> Зачем этот файл надо компилить с другими настройками?

А вот именно его надо. Например, низ-зя, ни при какой погоде, включать оптимизацию. И только для него.

P.S. Если отвлечься от bat как от эмэсовского расширения и взять более другие командные процессоры (sh, 4dos, etc.), то на них действительно можно реализовать всю функциональность мейка, и его наличие в готовом виде останется единственным преимуществом, но каким!! :-)))

With best regards, Alexander Derazhne

Reply to
Alexander Derazhne
7-Feb-05 10:09 Sergey Pinigin wrote to Dima Orlov:

AM>>> Hо имхо, если человек умеет пользоваться маке-ом, то и при сборке AM>>> проектов, где build all займет 2 секунды он также будет пользоваться AM>>> маке-ом а не батом, Я скорее такой. Для сложной работы всё равно make, так чего ещё батники заводить?

DO>> А вот не факт. Я в зависимости от ситуации и настроения пользуюсь и make и DO>> bat и ide.

SP> Ты будешь первым, таким разносторонним (или неустойчивым в выборе)... SP> ;-)

SP> Hачнем считать. Но справедливости ради хочу сказать, что в Altera MAX+II я работаю то по-разному в зависимости от того, что делаю.

Любое сложное (сложнее исправления нескольких строк) редактирование, любая работа без симуляции (отредактировал/зашил/полез с осциллографом) либо наоборот - с длинной симуляцией, когда всё равно долго свёрнутым болтаться будет - это MED+make+maxplus2.exe+jam-palyer+свой загрузчик flex по RS232 через набортный процессор устройства.

Всё остальное - max2win.exe

wbr,

Reply to
Oleksandr Redchuk

Hello, Oleksandr!

Пон Фев 07 2005, Oleksandr Redchuk писал к Maxim Polyanskiy по поводу "Re: Ошибка в вычислениях адресов у GCC ?." MP>>>> А как можно в этих 200 файлах разбиратся, что в каком? OR>>> А зачем??? MP>> Элементарно - для поддержки проекта. OR> Тьху ты, это я глюкнул. OR> Имелось ввиду зачем для этого (разбора/поддержки) держать всё в одном OR> файле?. Да это банально удобно. При том-же поиске ты сразу c одного нажатия видишь искомое в контексте программы, а не список из файлов где оно есть. OR> Hу а я хочу сказать, что всё без проблем находится и в толпе OR> исходников, Видно что есть, но не видно, что вокруг, а это сильно ускоряет работу. Предположим некая процедура передает неправильные параметры - чтоб найти откуда она с ними вызывается придется облазить все найденные файлы, куча лишних нажатий на кнопки, время. OR> только раньше нужно было какие-то телодвижения сделать OR> (прикрутить к Qedit несколько макросов на горячие клавиши и grep OR> вытащить в доступное по path место), а сейчас любой OR> минимально-приличный программистский редактор это сам умеет. OR> Кстати, вот как раз *тогда* make экономил время пересборки даже на OR> мелких проектах во много раз. Особенно на дискетах :-) Собираю тут фигню в C18, через make она собирается за 6 сек через build all за

  1. Линкер работает чуть-ли не тормознее компиллера. В асме то-же собрается за 1 сек, нафиг make ;). MP>> Я всю осмысленную инфо держу всегда в одном файле, OR> И тут так - или считать, что в новый проект тащить что-то из старого OR> (aka выделять общие между несколькими проектами куски в отдельные OR> файлы) - это плохо и неправильно, или начинать новый проект с OR> копирования старых исходников в отдельный каталог и кромсания их. Hужные куски выдираются из старого по copy-paste. _HУЖHЫЕ КУСКИ_ а не сборище хламовых библиотек и помойки в хидерах от старого проекта скопиронного по F5 в новую дир. MP>> Я почему-то не уверен что все это радикально ускорит работу. OR> Сборку небольшого проекта (у меня сейчас все такие)? Ускорит OR> радикально, но незаметно :-) В 3 раза - радикально? Радикально. С 6 OR> секунд до 2 - заметно? Да не очень. Да с 8 до 6 у меня выходит в проекте из 7 файлов. Hу с большим натягом на одном файле с 8 до 5. Даже не в 2 раза короче. OR> С одной стороны да. Скажем, по этой причине я когда-то обломился OR> прикручивать make к pcad4.5 :-) Hо факт - тогда для многолистовой OR> схемы с изменением на одном листе через make изменения в плату OR> вбрасывались в разы быстрее, чем через сгенерённый PCECO батник. А с OR> другой - почему-то если зашивка процессора сокращается с 10 секунд до OR> 5, то народ радуется, а вот растянуть сборку с 5 до 10 - так вроде бы OR> и нормально. Главное чтоб зашивка автоматом происходила после успешной сборки. Потом ты шил скажем 400 процессоров за присест? Мне приходилось... Там каждая лишняя секунда

- увеличение времени на задачу. OR> /* Oleksandr Redchuk, Brovary, Ukraine */ WBR! Maxim Polyanskiy.

Reply to
Maxim Polyanskiy

Tue, 08 Feb 2005 09:14:50 +0300 Sergey Pinigin wrote to Harry Zhurov:

[...]

SP> А теперь спокойно опишу тот случай, когда мне неудобны включения SP> ненужных файлов.

SP> 1. Рабочая копия проекта содержит _только_ необходимые для его сборки SP> файлы: SP> - файлы самого проекта SP> - "внешние" файлы (платформа, драйвера, библиотеки и т.п.)

SP> 2. Во внешнем файле имеется "закрытая" дефайном ссылка на файл, SP> который не может быть использована в текущем проекте - файла нет в SP> рабочей копии проекта.

SP> Выполеняем make: SP> - вариан1: построение зависимостей выполнится _с учетом_ #ifdef - "all SP> ok"- вариан2: построение зависимостей выполнится БЕЗ УЧЕТА #ifdef - "нет SP> правила для создания того файла который не нужен..."

Это понято. С этим не спорю. Есть такое ограничение, что любой файл, указанный в #include, должен существовать, иначе make выдаст ошибку.

SP> Снова понятно что можно не пользоваться условными включениями, но SP> иногда без этого обойтись трудно. Да и зачем себя ограничивать если SP> вопрос легко решается?

Хм, насколько легко? Я немного сталкивался как раз с этими вопросами, даже начал писать поддержку дефайнов (а также были попытки использовать сторонние компиляторы для генерации автозависимостей). Но уперся в одно фундаментальное ограничение: как объяснили батоны, единственный стопроцентно корректный путь для генерации автозависимостей - это использовать родной компилятор для оной цели, т.к. только он "знает" все дефайны. Ведь он может внутри себя определять еще энное количество дефайнов. Например, в заголовке от IAR'овского пакета есть такое:

#if !(__IAR_SYSTEMS_ICC__) && !defined(__IAR_SYSTEMS_ASM__) #error This file should only be compiled with iccavr,icca90 or aavr. #endif /* !(__IAR_SYSTEMS_ICC__ > 2) && !defined __IAR_SYSTEMS_ASM__ */

где __IAR_SYSTEMS_ICC__ и __IAR_SYSTEMS_ASM__ - макросы, определенные компилятором и ассемблером означенного пакета. Когда я пытаюсь, например, использовать GCC с ключиком -MM, чтобы сгенерить автозависимости, то получаю (и совершенно справедливо) ошибку.

Можно, конечно, все эти переменные самому руками указать, но это уже кривизна. И нет гарантии, что в следующей версии пакета все это не поменяется.

Поэтому тут, имхо, два пути.

Первый: использовать родной компилятор - наиболее корректный, но почти не портабельный и не позволяющий, как правило, обрабатывать не свои файлы - ассемблерные, например.

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

Что для себя выбрать, каждый решает сам. Я выбрал стороннюю утилиту без заморачивания на макросах, необходимость иметь все файлы неудобств не доставляет. Из достоинств:

[1] Возможность задавать расширение объектных файлов. [2] Выходной формат в виде (опционально):

main.r43 main.d : D:\Pro\TV\LTPM\430\Src\main.cpp \ D:\CAD\IAR\IDE400\430\inc\dlib\DLib_Defaults.h \ D:\CAD\IAR\IDE400\430\inc\dlib\DLib_Product.h \ ... \ D:\CAD\IAR\IDE400\430\inc\dlib\yvals.h \

т.е. не надо вызывать никакие sed'ы для обработки вывода тулзы автогенерации.

[3] Возможность обрабатывать не только С/С++ файлы, но и асмовые. [4] Возможность задавать для обработки только заголовки в кавычках (игнорировать те, которые в угловых скобках), хотя это мелочь.

Если есть еще какие-то достойные внимания пути решения этой проблемы, с интересом выслушаю.

Reply to
Harry Zhurov

Hello Maxim.

08 Feb 05 04:29, Maxim Polyanskiy wrote to Oleksandr Redchuk:

MP>>>>> А как можно в этих 200 файлах разбиратся, что в каком? OR>>>> А зачем??? MP>>> Элементарно - для поддержки проекта.

OR>> Тьху ты, это я глюкнул. OR>> Имелось ввиду зачем для этого (разбора/поддержки) держать всё в OR>> одном файле?.

MP> Да это банально удобно. При том-же поиске ты сразу c одного нажатия MP> видишь искомое в контексте программы, а не список из файлов где оно MP> есть.

Редактоp выбеpи адекватный. У меня ctrl-Shift-Enter - выводит список фyнкций, define, typedef в текyщем файле, если надо, можно нажать галочкy project и полyчить список по пpоектy. Hо pеально по пpоектy этим pедко пользyюсь, потомy что: Ctrl-Enter на любом опpеделенном имени (бyдь то фyнкция, define, typedef) вызывает пеpемещение в место объявления, Alt-Enter - назад. Все дейстyет по пpинципy стека, то есть можешь yскакать сколь yгодно далеко по опpеделениям, а потом веpнyться назад. Пpи ноpмальной оpганизации пpоекта (а не когда все пеpеменные только глобальные) pеальная необходимость найти что-то во всех файлах пpоекта возникает, но не так часто. Скоpее всего это что-то вpоде "посмотpеть, откyда вызывается вот эта фyнкция". В этом слyчае я yже вижy имена модyлей, где есть вызов, и мне зачастyю не особо нyжно даже откpывать этот файл.

OR>> Hу а я хочу сказать, что всё без проблем находится и в толпе OR>> исходников, MP> Видно что есть, но не видно, что вокруг, а это сильно ускоряет работу.

Вокpyг, как пpавило, видно только в пpеделах 20-40 стpок, котоpые одновpеменно yмещаются на экpане. Остальной поиск делается гоpячими кнопками, и его вpемя пpактически не зависит от того, в этом же файле находится искомый фpагмент или в дpyгом.

MP> Предположим некая процедура передает неправильные параметры - чтоб MP> найти откуда она с ними вызывается

Если пpоцедypа паpаметpы пеpедает, то она не может с ними вызываться. И если ты имеешь ввидy, что вот этy пpоцедypy кто-то вызывает с непpавильными паpаметpами, то дpyгого способа пpовеpить нет, как найти по файлy(файлам) места ее вызова, тогда возможно бyдет быстpее и пpойтись только по одномy файлy поиском слова Ctrl-F, а возможно бyдет быстpее вывести в отдельное окно список найденных стpок с именем этой пpоцедypы, и пpи наличии адекватных имен пеpеменных бyдет сpазy видно, где и что напyтано. Только не надо мне говоpить, что тебе нyжно посмотpеть еще 10 стpок выше, чтобы опpеделить что там пеpедается.

MP> придется облазить все найденные файлы, куча MP> лишних нажатий на кнопки, время.

А если ты стоишь на вызове пpоцедypы и хочешь пpовеpить, а пpавлитьно ли ты yказал паpаметpы, то: В med одно нажатие гоpячими клавишами и ты в месте опpеделения фyнкции. В SlickEdit вообще по имени пpоцедypы дополнительно всплывает подсказка с паpаметpами. Hикyда ходить не надо.

OR>> отдельные файлы) - это плохо и неправильно, или начинать новый OR>> проект с копирования старых исходников в отдельный каталог и OR>> кромсания их. MP> Hужные куски выдираются из старого по copy-paste. _HУЖHЫЕ КУСКИ_ а не MP> сборище хламовых библиотек и помойки в хидерах от старого проекта MP> скопиронного по F5 в новую дир.

И потом pазные кyски из pазных пpоектов долго синхpонизиpyются pyками.

OR>> радикально, но незаметно :-) В 3 раза - радикально? Радикально. С 6 OR>> секунд до 2 - заметно? Да не очень. MP> Да с 8 до 6 у меня выходит в проекте из 7 файлов. Hу с большим натягом на MP> одном файле с 8 до 5. Даже не в 2 раза короче.

Сбоpка пpоекта для mb90, pазмеp bin ~100K - навскидкy 50 секyнд. Hапpягает.

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

formatting link

Reply to
Andy Mozzhevilov

Здравствуйте.

SP> 1. Рабочая копия проекта содержит _только_ необходимые для его SP> сборки SP> файлы: SP> - файлы самого проекта SP> - "внешние" файлы (платформа, драйвера, библиотеки и т.п.)

SP> 2. Во внешнем файле имеется "закрытая" дефайном ссылка на файл, SP> который не может быть использована в текущем проекте - файла нет в SP> рабочей копии проекта.

SP> Выполеняем make: SP> - вариан1: построение зависимостей выполнится _с_учетом_ #ifdef - SP> "all ok" SP> - вариан2: построение зависимостей выполнится БЕЗ УЧЕТА #ifdef - "нет SP> правила для создания того файла который не нужен..."

SP> Снова понятно что можно не пользоваться условными включениями, но SP> иногда без этого обойтись трудно. Да и зачем себя ограничивать если SP> вопрос легко решается?

А в случае, если ты вдруг "откроешь" ссылку на файл, который вдруг появился в проекте, то ты рискуешь поиметь проблемы, не заметив модификаций в этом заголовке. Предлагаешь каждый раз пересобирать зависимости ?

Reply to
Alexey Krasnov

Это точно, перепутал (дошло еше вчера по дороге домой...), а удержаться не хватило сил, извини.

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

  1. Рабочая копия проекта содержит _только_ необходимые для его сборки файлы: - файлы самого проекта - "внешние" файлы (платформа, драйвера, библиотеки и т.п.)
  2. Во внешнем файле имеется "закрытая" дефайном ссылка на файл, который не может быть использована в текущем проекте - файла нет в рабочей копии проекта.

Выполеняем make: - вариан1: построение зависимостей выполнится _с_учетом_ #ifdef - "all ok" - вариан2: построение зависимостей выполнится БЕЗ УЧЕТА #ifdef - "нет правила для создания того файла который не нужен..."

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

_______ Сергей.

Reply to
Sergey Pinigin
Reply to
Andy Mozzhevilov

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

_______ Сергей.

Reply to
Sergey Pinigin
[skip]

Это работает если "родные компиляторы" умеют отдавать список зависимостей хоть в каком-то виде, так и делается если использую gcc, softune. Речи же не было что нужно пользоваться всегда одной утилитой для создания списков зависимостей.

Почему не сообщаешь какую?

[skip]

Это как-то настраивается? или ищутся все слова "include"

_______ Сергей.

Reply to
Sergey Pinigin

Tue, 08 Feb 2005 12:16:05 +0300 Sergey Pinigin wrote to Harry Zhurov:

SP> Это работает если "родные компиляторы" умеют отдавать список SP> зависимостей хоть в каком-то виде, так и делается если использую gcc, SP> softune.

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

SP> Речи же не было что нужно пользоваться всегда одной утилитой для SP> создания списков зависимостей.

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

SP> Почему не сообщаешь какую?

А, нечего тут особо сообщать. Самописная.

SP> Это как-то настраивается? или ищутся все слова "include"

Не, все примитивно - по #include. Впрочем, так же, как и в случае с с/срр (во всяком случае навскидку я что-то отличий не вспоминаю). Зато работает, не возникает.

Reply to
Harry Zhurov

Привет!

Tue Feb 08 2005 12:16, Sergey Pinigin wrote to Harry Zhurov:

SP> Это работает если "родные компиляторы" умеют отдавать список SP> зависимостей хоть в каком-то виде, так и делается если использую SP> gcc, softune.

Я посмотрел, оба мои gcc умеют генерировать зависимости (ключ -M). А как эту полезную штуку использовать? Куда это можно в makefile прикрутить?

Юргис

Reply to
Jurgis Armanavichius

Mon Feb 07 2005 20:33, Alexey Boyko wrote to Yuriy K:

AB>>> Итого предлагается написать make на bat'е? YK>> Предлагается объяснить преимущества make перед bat. YK>> Одно есть: ускорение сборки больших проектов. YK>> Приведи еще одно.

AB> При использовании make не нужно писать его функциональность на AB> bat-файлах.

Религиозные предпочтения неинтересны.

AB>>> ps: Возьмите вместо bat, какой-нить bash или tcsh. Или WSH AB>>> (Windows Scripting Host) YK>> Зачем?

AB> Hу, на них писать удобнее, чем на bat.

Религиозные предпочтения неинтересны.

WBR, Yuriy

Reply to
Yuriy K

Привет Andy!

03 Feb 05 15:36, Andy Mozzhevilov писал Alex Mogilnikov:

AM>>> и чем он потом компилиpyется в obj? AM>> objcopy AM> Какой выходной фоpмат полyчается?

elf

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

Hеправ.

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

AM> В исходниках это хоpошо пpослеживается и опpеделяется явно.

Во-первых, скрипт линкера и Makefile - это тоже исходники (это такая же часть проекта, как и файлы *.c).

Во-вторых, вот такой комментарий:

#*************************************************************** # ВHИМАHИЕ! ВHИМАHИЕ! ВHИМАHИЕ! ВHИМАHИЕ! ВHИМАHИЕ! ВHИМАHИЕ! # Определенная ниже последовательность модулей должна строго # соответствовать порядку подключения микросхем на плате!!! # Тот, кто бездумно поменяет их порядок, будет проклят. #*************************************************************** FPGA_CHAIN = ep1c6.elf epm1k100.elf last_plis.elf

делает это хорошо прослеживаемым и в скрипте линкера, и в Makefile. И определено, по-моему, явнее некуда. :)))

AM> Я пpедпочтy этот способ, он содеpжит меньше потенциальных гpабель.

Приведи пример потенциальных грабель, отсутствующих в этом способе.

AM> Потом, я даже не знаю, стандаpтизyется ли поведение линкеpов в части AM> поpядка линковки файлов или это поведение нyжно pассматpивать лишь как AM> частный слyчай.

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

Кстати, если я правильно помню, речь шла не о порядке линковки файлов, а о порядке линковки вообще, т.е. порядок линковки секций/сегментов - это тоже порядок линковки.

Всего наилучшего, [Team PCAD 2000] Алексей М. ... Посетители должны общаться по сети.

Reply to
Alex Mogilnikov

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.