VladislavS 39 10 ноября, 2007 Опубликовано 10 ноября, 2007 · Жалоба А меня вот заинтересовал вопрос перемещаемости кода. Могу я из разных мест запускать то что IAR накомпилил? Что-то мне говорит что нет. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
NikolayZ 0 10 ноября, 2007 Опубликовано 10 ноября, 2007 · Жалоба А меня вот заинтересовал вопрос перемещаемости кода. Могу я из разных мест запускать то что IAR накомпилил? Что-то мне говорит что нет. Чтобы точно ответить на Ваш вопрос надо проанализировать объектный код, генерируемый компилятором. Я думаю и почти уверен, что ответ скорее всего будет нет, т.к. в исполняемом коде - скорее всего все переходы и вызовы подпрограмм жестко связаны с местоположением программы и не являются скорее всего перемещаемыми. Я говорю "скорее всего" потому, что у меня нет особого желания это дело выяснять точно, а процессоры с архитектурой, которая принципиально имеет только "относительную" адресацию переходов - это достаточно большая редкость - и исполняемая программа практически всегда привязана именно к точке на которую ее настроил линкер.... Грубо говоря, если линкер настроил код для раположения с адреса 0x001000 к примеру и далее вверх, то он только при таком расположении в памяти и будет корректно работать. Стоит его переместить - ну например простой переписью хотя бы на 1-2-3-4 байта в любую сторону и он - скорее всего просто перестанет работать вообще, даже если вы правильно вызовете его новую точку входа. Вообще-то то, что я говорю выше - Вы можете легко найти в любом учебнике по программированию и намного конкретнее и детальнее. Насколько я понимаю Вас вы хотите все-таки устроить нечто вроде "дозагрузки" частей Вашей системы в процессе исполнения... Это как раз и есть механизм оверлеев. Отсюда у вас и желание - запустить программу не с заданной при линковке точки, а с любой прерменной. Но в таком случае -- точка входа задаваемая линкером - к реализации вашего желания имеет минимальное отношение, и даже больше - она к этому вообще может не иметь ровно никакого отношения. Точка входа - это та точка через которую запускается Ваша программа после начальной инициализации и не более того. Вот потому ее делать переменной и не имеет никакого смысла. Она может быть нестандартной и лежать в необычном месте, но после линковки - она фиксирована и фиксирована раз и навсегда - до новой перелинковки. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Сергей Борщ 134 10 ноября, 2007 Опубликовано 10 ноября, 2007 · Жалоба А меня вот заинтересовал вопрос перемещаемости кода. Могу я из разных мест запускать то что IAR накомпилил? Что-то мне говорит что нет.Судя по описанию - может. Это задача линкера - размещать код. Опция -V позволяет генерить перемещаемый код. Более подробно - в описании линкера. P.S. Да, это относится к версии 4.xx, пятую не смотрел. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
NikolayZ 0 10 ноября, 2007 Опубликовано 10 ноября, 2007 (изменено) · Жалоба Судя по описанию - может. Это задача линкера - размещать код. Опция -V позволяет генерить перемещаемый код. Более подробно - в описании линкера. P.S. Да, это относится к версии 4.xx, пятую не смотрел. Тогда значит нужно освоить две вещи: 1) Научится делать перемещаемый код... Сделать независимые загружаемые по ходу дела модули... 2) Сотворить модуль загрузки дополнительных веток, которые в общем случае могу перекрывать друг-друга в памяти и сменять друг-друга в процессе исполнения... И насколько я понимаю вопрошающего - его задача будет решена... Но вот как это делать - пусть разберется сам. Я пока в ИАР-е Для STR912 этого делать не планирую и предпочитаю плоскую структуру софта и загрузки из одного-единственного модулябез каких-либо подгрузок по ходу работы... Изменено 10 ноября, 2007 пользователем Николай Z Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Сергей Борщ 134 10 ноября, 2007 Опубликовано 10 ноября, 2007 · Жалоба Я пока в ИАР-е Для STR912 этого делать не планирую и предпочитаю плоскую структуру софта и загрузки из одного-единственного модулябез каких-либо подгрузок по ходу работы...Вы меня радуете:потому что организация оверлеев в рамках FreeRTOS - меня самого сильно интересует... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 1 10 ноября, 2007 Опубликовано 10 ноября, 2007 · Жалоба P.S. Да, это относится к версии 4.xx, пятую не смотрел. В пятой elf, со всеми вытекажщими из этого плюсами и минусами. Тогда значит нужно освоить две вещи: 1) Научится делать перемещаемый код... Сделать независимые загружаемые по ходу дела модули... 2) Сотворить модуль загрузки дополнительных веток, которые в общем случае могу перекрывать друг-друга в памяти и сменять друг-друга в процессе исполнения... Не факт, как частный случай модули могут простона ходится во Flash слинкованные, как не перемещаемые. Таким упрощенным подходом уже можно добиться полностью независимого написания и upgrade софта разными исполнителями. Во всех моих случаях использования оверлеев именно эта причина была довлеющей. Хотя с дополнительной целью повышения быстродействия в 16bit RAM, вместо медленной 70ns Flash, были реализации и загрузки перемещаемого кода. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
NikolayZ 0 11 ноября, 2007 Опубликовано 11 ноября, 2007 (изменено) · Жалоба (Николай Z): Я пока в ИАР-е Для STR912 этого делать не планирую и предпочитаю плоскую структуру софта и загрузки из одного-единственного модулябез каких-либо подгрузок по ходу работы... Вы меня радуете: (Николай Z @ Nov 9 2007, 22:27): потому что организация оверлеев в рамках FreeRTOS - меня самого сильно интересует... А Вы в чем собственно противоречие усмотрели? Интересоваться и планировать - по моему вещи достаточно разные... Планируют обычно то, что надо реализовать в ближайшее вермя, а знать желательно немного больше - по-моему это вполне нормально: интересоваться, но за реализацию не браться. Меня много что интересует помимо того, что стоит в текущих планах и обязательно для реализации сейчас и сегодня(иногда еще вчера) В пятой elf, со всеми вытекажщими из этого плюсами и минусами. Не факт, как частный случай модули могут простона ходится во Flash слинкованные, как не перемещаемые. Таким упрощенным подходом уже можно добиться полностью независимого написания и upgrade софта разными исполнителями. Во всех моих случаях использования оверлеев именно эта причина была довлеющей. Хотя с дополнительной целью повышения быстродействия в 16bit RAM, вместо медленной 70ns Flash, были реализации и загрузки перемещаемого кода. Дык никто об этом и спорить не собирается - мне кажется. Но вопрос-то явно связан был с перемещаемыми модулями... Да и оверлеи в общем случае могут быть и "статическими" - слинкованными как неперемещаемые, так "динамическими" - занружаемыми в произвольные свободные места, что уже потребует линковать их как перемещаемые. Строго говоря - все это "хорошо забытая" классика, которая в современных учебниках обычно остается за кадром по причине всеобщего увлечения огромной динамической памятью в системах вроде Win*X или *NiX - виндоподобных или юниксоподобных... Боюсь, что скоро и во встроенных системах это станет совершенно неактуально, кроме как на "телегах с реактивными двигателями" вроде устаревших 8-битовых архитектур вроде 51-й... Изменено 11 ноября, 2007 пользователем Николай Z Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Rst7 5 12 ноября, 2007 Опубликовано 12 ноября, 2007 · Жалоба Особых проблем с изготовлением перемещаемого кода нет. В аттаче elfloader.zip собственно простенький загрузчик эльфов, изготовленных при помощи IAR4.x (про пятый - ниже). Сам загрузчик требует наличия функций fopen,fread,fclose,lseek,malloc,free,memset или zeromem, и специальной внешней функции IMB() - для выполнения прочистки кешей перед запуском. Для упрощения загрузчика .xcl-файл должен представлять из себя следующее: -carm // Declare relocation areas for code, constants and data. -V(CODE)CODE_AREA,12 -V(DATA)DATA_AREA,12 // Place segments into the relocation areas -Z(CODE_AREA)ELFBEGIN,DATA_ID,START,CODE,DATA_C,INITTAB,DATA_Z,DATA_N=0-FFFFFFFF -Z(DATA_AREA)DATA_I=0-FFFFFFFF В линкере выставляем Output Format elf/dwarf, Format variant none, Config/Override default program entry/Entry label "main", Extra Options -ynpra Вызов функций, доступных для использования в исполняемых модулях, был сделан через swi. Описаны эти функции в файле swilib.h примерно таким методом: #pragma diag_suppress=Ta035 ... #pragma swi_number=10 __swi __arm int fopen(const char * cFileName, unsigned int iFileFlags, unsigned int iFileMode, unsigned int *ErrorNumber); ... Код собственно вызывателя функций по их адресам из SWI могу привести, он похож на swi_handler в исходниках библиотеки иара. Теперь собственно про пятый иар. Там конечно все уже в формате ELF, но штатный линкер не генерирует релокации. Попытка прикрутить ld от гнуся закончилась тем, что ld при генерации эльфа с релокациями просто эмитит ВСЕ релокации в выходной файл. Посему загрузчик надо дорабатывать, чтобы он понимал все возможные типы релокаций, а не только те, которые может генерить линкер от иара 4.x (этот линкер сразу обрабатывает все релокации, которые можно обработать при линковке, например BL внутри одной секции, это резко упрощает загрузчик). Ну или какой то промежуточный пререлокатор на хост-машине, который сделает это сам (но очень лениво писать :) ) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
NikolayZ 0 13 ноября, 2007 Опубликовано 13 ноября, 2007 · Жалоба Особых проблем с изготовлением перемещаемого кода нет. В аттаче elfloader.zip собственно простенький загрузчик эльфов, изготовленных при помощи IAR4.x (про пятый - ниже). Сам загрузчик требует наличия функций fopen,fread,fclose,lseek,malloc,free,memset или zeromem, и специальной внешней функции IMB() - для выполнения прочистки кешей перед запуском. Для упрощения загрузчика .xcl-файл должен представлять из себя следующее: -carm // Declare relocation areas for code, constants and data. -V(CODE)CODE_AREA,12 -V(DATA)DATA_AREA,12 // Place segments into the relocation areas -Z(CODE_AREA)ELFBEGIN,DATA_ID,START,CODE,DATA_C,INITTAB,DATA_Z,DATA_N=0-FFFFFFFF -Z(DATA_AREA)DATA_I=0-FFFFFFFF В линкере выставляем Output Format elf/dwarf, Format variant none, Config/Override default program entry/Entry label "main", Extra Options -ynpra Вызов функций, доступных для использования в исполняемых модулях, был сделан через swi. Описаны эти функции в файле swilib.h примерно таким методом: #pragma diag_suppress=Ta035 ... #pragma swi_number=10 __swi __arm int fopen(const char * cFileName, unsigned int iFileFlags, unsigned int iFileMode, unsigned int *ErrorNumber); ... Код собственно вызывателя функций по их адресам из SWI могу привести, он похож на swi_handler в исходниках библиотеки иара. Теперь собственно про пятый иар. Там конечно все уже в формате ELF, но штатный линкер не генерирует релокации. Попытка прикрутить ld от гнуся закончилась тем, что ld при генерации эльфа с релокациями просто эмитит ВСЕ релокации в выходной файл. Посему загрузчик надо дорабатывать, чтобы он понимал все возможные типы релокаций, а не только те, которые может генерить линкер от иара 4.x (этот линкер сразу обрабатывает все релокации, которые можно обработать при линковке, например BL внутри одной секции, это резко упрощает загрузчик). Ну или какой то промежуточный пререлокатор на хост-машине, который сделает это сам (но очень лениво писать :) ) Мне все-таки кажется, что прежде чем обсуждать способы решения, надо для начала поставить правильно задачу. Иначе средства решения превращаются в самоцель и могут стать слишком сложными. А вот постановка задачи пока напрочь отметается... Зачем вообще делать в оверлеях перемещаемые секции? Мне кажется, что для решения большинства мыслимых для IAR задач вообще не стоит бодаться с перемещением и достаточно именно статических оверлеев, которые настроены на фиксированные адреса дозагрузки... А мы тут уже кинулись зачем-то разрешать задачку запуска любой ветки оверлея с произвольного адреса... Резонно спросить - а зачем это вообще нужно в достаточно простых встроенных приложениях? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 1 13 ноября, 2007 Опубликовано 13 ноября, 2007 · Жалоба Особых проблем .... Спасибо за информацию по V5 - очень пригодится. Резонно спросить - а зачем это вообще нужно в достаточно простых встроенных приложениях? Знания никогда не помешают, вот мы их и накапливаем. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
NikolayZ 0 13 ноября, 2007 Опубликовано 13 ноября, 2007 · Жалоба Знания никогда не помешают, вот мы их и накапливаем. Не помешают, и это правда... Но вот только ведь они давно уже никакие не сакральные... Давно описанных способов реализации динамической загрузки более чем достаточно есть в литературе... Здесь же имеет смысл решать вполне конкретные задачи, но для этого нету исходной постановки задачи. Потому я и задаю все время озин и тот же вопрос - а для чего это надо... Эффективность конкретного решения всегда выше, чем решение вообще в общем случае... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 1 13 ноября, 2007 Опубликовано 13 ноября, 2007 · Жалоба Давно описанных способов реализации динамической загрузки более чем достаточно есть в литературе... Ну в какой 'литературе' описан нюанс поведения линкера от V5.10 IAR при попытке сваять загружаемый модуль? Здесь же имеет смысл решать вполне конкретные задачи... Вот чистой конкретикой Rst7 и поделился. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Rst7 5 14 ноября, 2007 Опубликовано 14 ноября, 2007 · Жалоба А мы тут уже кинулись зачем-то разрешать задачку запуска любой ветки оверлея с произвольного адреса... Резонно спросить - а зачем это вообще нужно в достаточно простых встроенных приложениях? А что Вам так не нравится? Почему бы не скрестить какой-нибудь RTOS с загрузкой выполняемых файлов? Найдется ниша и такому применению, особенно с учетом того, что линукс часто тяжеловат для "достаточно простых встроенных приложений" Но вот только ведь они давно уже никакие не сакральные... А тут никто на тайное знание и не претендует. Просто делюсь наработкой. Или нельзя? Давно описанных способов реализации динамической загрузки более чем достаточно есть в литературе... Вы когда нибудь заглядывали в исходник загрузчика исполняемых файлов от никса? Там же черт ногу сломит ;) А тут все просто, для начинающих. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
alexander55 0 14 ноября, 2007 Опубликовано 14 ноября, 2007 · Жалоба А тут никто на тайное знание и не претендует. Просто делюсь наработкой. Или нельзя? Вы когда нибудь заглядывали в исходник загрузчика исполняемых файлов от никса? Там же черт ногу сломит ;) А тут все просто, для начинающих. Вы все правильно сделали, не терзайте себя сомнениями. :) Это полезная информация особенно, если делать что-нибудь типа КПК. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
NikolayZ 0 14 ноября, 2007 Опубликовано 14 ноября, 2007 (изменено) · Жалоба Ну в какой 'литературе' описан нюанс поведения линкера от V5.10 IAR при попытке сваять загружаемый модуль? Вот чистой конкретикой Rst7 и поделился. А я не об ньюансах линкера... Я об организации оверлеев. Это никак не зависит от конкретной тулзы и может быть реализовано на любой из имеющихся в наличии. Просто большими или меньшими усилиями. Тулза - это всего лишь инструмент - его свойства знать полезно, но решают не свойства тулзы, а цели которые надо достичь. За конкретику - спасибо - она несомнено никому не мешает, а может и кому-то поможет. Теперь остается только понять зачем она и куда ее применить.. Собственно мои сомнения скорее всего в том, что в топе задан несколько иной вопрос и товарищ(в топе) просто не то ищет, что ему реально было нужно... Но это как бы мои сомнения. Изменено 14 ноября, 2007 пользователем Николай Z Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
