Добрый вечер!
Правильно ли понимаю, что cross compile toolchain - это набор binutils + gcc + gdb, сконфигуренных и скомпиленных для соответствующей аппаратной платформы?
Чем отличаются arm-elf-tools (arm-elf-gcc и т.д.) от arm-linux-tools (соответственно, arm-linux-gcc)? Сам собирал RedBoot при помощи arm-elf- и linux на эту же платформу при помощи arm-linux-. Все работает и не жалуется. В другой ситуации, uClinux для LPC2468 собирается arm-elf, но не хочет arm-linux. В чем тут разница, чего не понимаю?
Где можно взять относительно свежие бинарники этих тулчаинов для linux? На какие параметры целевой платформы надо обращать внимание, чтобы собрать самому? Или там просто типа configure --target=arm-elf?
Полная версия этой страницы: Вопрос о toolchain
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > Cредства разработки для МК > GNU/OpenSource средства разработки
Правильно ли понимаю, что cross compile toolchain - это набор binutils + gcc + gdb, сконфигуренных и скомпиленных для соответствующей аппаратной платформы?
прально, тока еще забыли как минимум библиотеку libc ( бывают ее реализации newlib uClib glibc и тд )
Чем отличаются arm-elf-tools (arm-elf-gcc и т.д.) от arm-linux-tools (соответственно, arm-linux-gcc)? Сам собирал RedBoot при помощи arm-elf- и linux на эту же платформу при помощи arm-linux-. Все работает и не жалуется. В другой ситуации, uClinux для LPC2468 собирается arm-elf, но не хочет arm-linux. В чем тут разница, чего не понимаю?
разница в компоновке исполняемых модулей. если вы имеете простейшие ARM машинки например LPC2000 то компилируется нипосредственный исполняемый код с реальной адресацией - тоесть все адреса, регистры и тд - есть совершенно четко физические понятия в этом коде приминительно к железу. Мы это называем "просто бинарь, исполняемый непосредственно процом ". arm-elf говорит о том что выходной файл компиляции имет формат ELF - тоесть сами бинарные данные и код + ELF объвязка (таблицы символов, размещенией флагов, отладочных и профилировояных секций ..........). Тоесть это еще не то что заливается в флеш и исполняется процом. Даее обычно используется утилита *-objcopy которая выдирает из этого изобилия непосредственно бинарь. ELF нужен для отладки : на кристале запускается бинарь а GDB засасывает ELF парсит заголовки,бинарь и грубо говоря устанавливает соответствие между состоянеием прогаммы на проце и ее модели которую он посторил по ELF файлу. Источнок даных о состоянии является например JTAG, типа дальше должно стать понятным в общем ввиде как идет оладка.
А вот если линукс - то тут все совсем по другому - компоновка подразумевает не настоящие адреса физической памяти а просто какета адреса линейной модели. Программа понятия не миее что и где реально лежит, ей достаточно что система гарантирует целостность данных и их адресов. Реальные адреса используются при работе с ячейками озу только в уже в специальном аппаратном модуле MMU который по табличкам соостветствия виртуальных адресов с которыми работает программа связывает реальные ячейки. Управляет этими табличками ядро операционной системы. Зачем этот гимарой? в первом приближении можно сказать что это практически едиственный метод резделит от взаимного влияни я различные задачи выполняющиеся паралельно и независимо. Далее должно стать понятно что вытекает совершенно другая компоновка исполняемого файла - стате это тоже ELF тока запускается именно он, таблички смволов и тд используется загрузчико процесса для настройки процесса на выполнение в конкретной операционной среде.
пример1 FreeRTOS + lpc2103 - шедуллер задач, все адреса реальные все задачи работают в едином ареальном адресном пространстве - и !!!!! каждая задача может засрать ВСЕ И ВСЕМ. Зато быстро и без шаманства.
пример2 Linux + ep9312 - настоящая OC, все задачки работаюст в своем ненастоящем(виртуальном пространстве) и имеют доступ к реальной памяти через MMU - он то и не дает согласно таблицам трансляции "пересечся" процессам, тоесть OC путем управления табличками MMU выполняет свою класическое предназначение - раздача и контроль ресурсов ( в данном случае памяти, но это относится ко всему - временные интервалы, файлы, каналы,семафоры..... ) в системе - тесть создание операционой среды для множества задач(пользователей ресурсов).
Где можно взять относительно свежие бинарники этих тулчаинов для linux? На какие параметры целевой платформы надо обращать внимание, чтобы собрать самому? Или там просто типа configure --target=arm-elf?
искать с собаками. обычно кому нада берет и сам собирает и подпиливат под себя.
свежий бинарники бывают у меня, выкладываю сюда. Вот кстате протрахался неделю сделал для ep9312/ep9315 тулчейн и ядро 2,6,24,3 uClibc которые полностю вытряхивают весь дух из Mavericka. ес!! всю жизнь мечтал о FPU, плата ТионПро - немного птестил вроде плавучка без ошибок. Это моя первая более менее серьезная зелезячка, в планах изготовит миниатюрынй девайс с mips64 и выжать из связки mips64 20Kc + кусок гетинакса с линухом порядка + GCC инфраструктуры порядка гигафлопса. А че? что нам помешает.
Удачи.
прально, тока еще забыли как минимум библиотеку libc ( бывают ее реализации newlib uClib glibc и тд )
Чем отличаются arm-elf-tools (arm-elf-gcc и т.д.) от arm-linux-tools (соответственно, arm-linux-gcc)? Сам собирал RedBoot при помощи arm-elf- и linux на эту же платформу при помощи arm-linux-. Все работает и не жалуется. В другой ситуации, uClinux для LPC2468 собирается arm-elf, но не хочет arm-linux. В чем тут разница, чего не понимаю?
разница в компоновке исполняемых модулей. если вы имеете простейшие ARM машинки например LPC2000 то компилируется нипосредственный исполняемый код с реальной адресацией - тоесть все адреса, регистры и тд - есть совершенно четко физические понятия в этом коде приминительно к железу. Мы это называем "просто бинарь, исполняемый непосредственно процом ". arm-elf говорит о том что выходной файл компиляции имет формат ELF - тоесть сами бинарные данные и код + ELF объвязка (таблицы символов, размещенией флагов, отладочных и профилировояных секций ..........). Тоесть это еще не то что заливается в флеш и исполняется процом. Даее обычно используется утилита *-objcopy которая выдирает из этого изобилия непосредственно бинарь. ELF нужен для отладки : на кристале запускается бинарь а GDB засасывает ELF парсит заголовки,бинарь и грубо говоря устанавливает соответствие между состоянеием прогаммы на проце и ее модели которую он посторил по ELF файлу. Источнок даных о состоянии является например JTAG, типа дальше должно стать понятным в общем ввиде как идет оладка.
А вот если линукс - то тут все совсем по другому - компоновка подразумевает не настоящие адреса физической памяти а просто какета адреса линейной модели. Программа понятия не миее что и где реально лежит, ей достаточно что система гарантирует целостность данных и их адресов. Реальные адреса используются при работе с ячейками озу только в уже в специальном аппаратном модуле MMU который по табличкам соостветствия виртуальных адресов с которыми работает программа связывает реальные ячейки. Управляет этими табличками ядро операционной системы. Зачем этот гимарой? в первом приближении можно сказать что это практически едиственный метод резделит от взаимного влияни я различные задачи выполняющиеся паралельно и независимо. Далее должно стать понятно что вытекает совершенно другая компоновка исполняемого файла - стате это тоже ELF тока запускается именно он, таблички смволов и тд используется загрузчико процесса для настройки процесса на выполнение в конкретной операционной среде.
пример1 FreeRTOS + lpc2103 - шедуллер задач, все адреса реальные все задачи работают в едином ареальном адресном пространстве - и !!!!! каждая задача может засрать ВСЕ И ВСЕМ. Зато быстро и без шаманства.
пример2 Linux + ep9312 - настоящая OC, все задачки работаюст в своем ненастоящем(виртуальном пространстве) и имеют доступ к реальной памяти через MMU - он то и не дает согласно таблицам трансляции "пересечся" процессам, тоесть OC путем управления табличками MMU выполняет свою класическое предназначение - раздача и контроль ресурсов ( в данном случае памяти, но это относится ко всему - временные интервалы, файлы, каналы,семафоры..... ) в системе - тесть создание операционой среды для множества задач(пользователей ресурсов).
Где можно взять относительно свежие бинарники этих тулчаинов для linux? На какие параметры целевой платформы надо обращать внимание, чтобы собрать самому? Или там просто типа configure --target=arm-elf?
искать с собаками. обычно кому нада берет и сам собирает и подпиливат под себя.
свежий бинарники бывают у меня, выкладываю сюда. Вот кстате протрахался неделю сделал для ep9312/ep9315 тулчейн и ядро 2,6,24,3 uClibc которые полностю вытряхивают весь дух из Mavericka. ес!! всю жизнь мечтал о FPU, плата ТионПро - немного птестил вроде плавучка без ошибок. Это моя первая более менее серьезная зелезячка, в планах изготовит миниатюрынй девайс с mips64 и выжать из связки mips64 20Kc + кусок гетинакса с линухом порядка + GCC инфраструктуры порядка гигафлопса. А че? что нам помешает.
Удачи.
Спасибо за информацию!
А откуда линкер узнает, где и как размещать бинарник в памяти?
А откуда линкер узнает, где и как размещать бинарник в памяти?
Цитата(DmitryV @ Mar 25 2008, 23:30) 
Спасибо за информацию!
А откуда линкер узнает, где и как размещать бинарник в памяти?
А откуда линкер узнает, где и как размещать бинарник в памяти?
в случаях arm-elf ВЫ! ему об этом говорите - подавая на вход линкерный скрипт с картой памяти.
в случае с ОС (без всяких тонкостей) компиллер должен скомпилять PIC (код который работает независимо от адресов положения , это просто метод компиляции без какихлибо предположений от том где будет лежать код, проще говоря все в относительных адресах ) линкеру нада по минимуму связать перекресные сцылки на символы ( функции, данные и тд, это кстате позволяет еще и динамическим библиотекам работать - ведь она должна уметь подгружена в дресное пространство процесса в случайное свободное место) из разных модулей и ВСЕ!! остальное делает загрузчие ОС - 1 размещает в памяти образ процесса, настраивает среду (регистры и тд) переключает процессор в пользовательский режим и передает управление на точку входа .... далее внутренняя жизнь процесса.
Позвольте еще один вопрос касательно GDB.
Собрал gdbserver для uCLinux на LPC2468 при помощи такой-то матери, запускается, пишет:
Запускаю arm-elf-gdb (из дистрибутива kgp_arm-bu2.18.50.20080115_gcc4.3.0.20080111_newlib1.16.0.20080115_gdb6.7.50.20080108 либо свой собранный под cygwin - без разницы):
Ответ:
Терминал LPC:
Соответственно, адекватно работает только команда "continue".
Вопрос: что делаю неправильно? в чем может быть проблема?
Собрал gdbserver для uCLinux на LPC2468 при помощи такой-то матери, запускается, пишет:
Код
# /mnt/mmc/gdbserver 192.168.200.3:1234 /mnt/mmc/main
Process /mnt/mmc/main created; pid = 62
Listening on port 1234
Process /mnt/mmc/main created; pid = 62
Listening on port 1234
Запускаю arm-elf-gdb (из дистрибутива kgp_arm-bu2.18.50.20080115_gcc4.3.0.20080111_newlib1.16.0.20080115_gdb6.7.50.20080108 либо свой собранный под cygwin - без разницы):
Код
This GDB was configured as "--host=i686-pc-mingw32 --target=arm-elf".
(gdb) file D:\\main.gdb
Reading symbols from D:\main.gdb...done.
(gdb) target remote 192.168.200.100:1234
(gdb) file D:\\main.gdb
Reading symbols from D:\main.gdb...done.
(gdb) target remote 192.168.200.100:1234
Ответ:
Код
Remote debugging using 192.168.200.100:1234
warning: Remote failure reply: E01
0xa02a0050 in ?? ()
(gdb) step
Remote communication error: Bad file descriptor.
Cannot find bounds of current function
(gdb)
warning: Remote failure reply: E01
0xa02a0050 in ?? ()
(gdb) step
Remote communication error: Bad file descriptor.
Cannot find bounds of current function
(gdb)
Терминал LPC:
Код
Remote debugging from host 192.168.200.3
<1>Unhandled fault: alignment exception (0x5000001) at 0xa1d13eec
Internal error: Oops: 0 [#3]
Modules linked in: spi rtc sfr pwm i2c adc lpc2468mmc lpc2468eth
CPU: 0
pc : [<a0055f18>] lr : [<00000000>] Not tainted
sp : a1d13eec ip : 9ede1000 fp : a1d13f0c
r10: a1d36820 r9 : 00000000 r8 : a01d09e4
r7 : a01d097c r6 : a1d13f2c r5 : a1d13f28 r4 : 00000001
r3 : a0000093 r2 : 00000000 r1 : a0000013 r0 : 00000000
Flags: NzCv IRQs off FIQs on Mode SVC_32 Segment user
Process gdbserver (pid: 61, stack limit = 0xa1d12194)
Stack: (0xa1d13eec to 0xa1d14000)
3ee0: a1d37dec a1d13f64 00000004 00000000 a1d37dc0
3f00: a1d13f58 a1d13f10 a0035a34 a0055ec8 00000000 00000001 a1d13f2c a1d13f28
3f20: a1d37dec a1d13f64 a01d09ec 9ede1000 a1d36820 a1d36820 00000001 00000000
3f40: 0000003e a1c5fe88 00000000 a1d13f78 a1d13f5c a001e4a8 a0035908 00000000
3f60: a1c5fe88 a1d12000 a1d12000 a1d13fa4 a1d13f7c a001e7c4 a001e40c 00000001
3f80: 00000000 00000001 0000001a a001b800 a1d12000 00000000 00000000 a1d13fa8
3fa0: a001b680 a001e6b0 00000001 a002a8ec 00000001 0000003e 00000000 a1c5fe88
3fc0: 00000001 00000000 00000001 00000000 00000000 00000000 00000000 a1c5fee0
3fe0: 00000000 a1c5fe80 a1c4b6d8 a1c4b684 80000010 00000001 ffffffff ffffffff
Backtrace:
Function entered at [<a0055eb8>] from [<a0035a34>]
r8 = A1D37DC0 r7 = 00000000 r6 = 00000004 r5 = A1D13F64
r4 = A1D37DEC
Function entered at [<a00358f8>] from [<a001e4a8>]
Function entered at [<a001e3fc>] from [<a001e7c4>]
r4 = A1D12000
Function entered at [<a001e6a0>] from [<a001b680>]
Code: 0a000006 e10f1000 e3813080 e121f003 (e59c2004)
SIGSEGV
#
<1>Unhandled fault: alignment exception (0x5000001) at 0xa1d13eec
Internal error: Oops: 0 [#3]
Modules linked in: spi rtc sfr pwm i2c adc lpc2468mmc lpc2468eth
CPU: 0
pc : [<a0055f18>] lr : [<00000000>] Not tainted
sp : a1d13eec ip : 9ede1000 fp : a1d13f0c
r10: a1d36820 r9 : 00000000 r8 : a01d09e4
r7 : a01d097c r6 : a1d13f2c r5 : a1d13f28 r4 : 00000001
r3 : a0000093 r2 : 00000000 r1 : a0000013 r0 : 00000000
Flags: NzCv IRQs off FIQs on Mode SVC_32 Segment user
Process gdbserver (pid: 61, stack limit = 0xa1d12194)
Stack: (0xa1d13eec to 0xa1d14000)
3ee0: a1d37dec a1d13f64 00000004 00000000 a1d37dc0
3f00: a1d13f58 a1d13f10 a0035a34 a0055ec8 00000000 00000001 a1d13f2c a1d13f28
3f20: a1d37dec a1d13f64 a01d09ec 9ede1000 a1d36820 a1d36820 00000001 00000000
3f40: 0000003e a1c5fe88 00000000 a1d13f78 a1d13f5c a001e4a8 a0035908 00000000
3f60: a1c5fe88 a1d12000 a1d12000 a1d13fa4 a1d13f7c a001e7c4 a001e40c 00000001
3f80: 00000000 00000001 0000001a a001b800 a1d12000 00000000 00000000 a1d13fa8
3fa0: a001b680 a001e6b0 00000001 a002a8ec 00000001 0000003e 00000000 a1c5fe88
3fc0: 00000001 00000000 00000001 00000000 00000000 00000000 00000000 a1c5fee0
3fe0: 00000000 a1c5fe80 a1c4b6d8 a1c4b684 80000010 00000001 ffffffff ffffffff
Backtrace:
Function entered at [<a0055eb8>] from [<a0035a34>]
r8 = A1D37DC0 r7 = 00000000 r6 = 00000004 r5 = A1D13F64
r4 = A1D37DEC
Function entered at [<a00358f8>] from [<a001e4a8>]
Function entered at [<a001e3fc>] from [<a001e7c4>]
r4 = A1D12000
Function entered at [<a001e6a0>] from [<a001b680>]
Code: 0a000006 e10f1000 e3813080 e121f003 (e59c2004)
SIGSEGV
#
Соответственно, адекватно работает только команда "continue".
Вопрос: что делаю неправильно? в чем может быть проблема?
сам внимательно почитаю че про это напишут. оч интересно. не пробываж каких комбинаций
Возникла похожая проблема - пытаюсь отлаживать программы с помощью собственноручно собранный arm-linux-gdb на хосте + gdbserver из uClinux 20070130 на целевом (EA LPC2468).
Соединение как понимаю проходит нормально:
Но отлаживать не получается:
Бинарники собирались в sdk, который поставляют Embedded Artists, Makefile для простенького HW следующий:
Еще я честно говоря не очень понимаю, каким образом elf файл hello.gdb c отладочной информацией должен согласовываться с flt файлом на целевом. Может у кого-нибудь был опыт отладки в подобных условиях?
Соединение как понимаю проходит нормально:
CODE
root# gdbserver 192.168.0.7:1234 hello
Process hello created; pid = 195
Listening on port 1234
Remote debugging from host 192.168.0.7
Process hello created; pid = 195
Listening on port 1234
Remote debugging from host 192.168.0.7
Но отлаживать не получается:
CODE
$ arm-linux-gdb hello.gdb
GNU gdb 6.8
This GDB was configured as "--host=i686-pc-linux-gnu --target=arm-linux"...
(gdb) target remote 192.168.0.10:1234
Remote debugging using 192.168.0.10:1234
0xa1840050 in ?? ()
(gdb) b main
Cannot access memory at address 0x3c
GNU gdb 6.8
This GDB was configured as "--host=i686-pc-linux-gnu --target=arm-linux"...
(gdb) target remote 192.168.0.10:1234
Remote debugging using 192.168.0.10:1234
0xa1840050 in ?? ()
(gdb) b main
Cannot access memory at address 0x3c
Бинарники собирались в sdk, который поставляют Embedded Artists, Makefile для простенького HW следующий:
CODE
CC=/home/user/uClinux-dist/tools/ucfront-gcc arm-elf-gcc
DEST=/home/user/nfs
FLAGS=-Wall
CFLAGS=-Os -DEMBED -Dlinux -D__linux__ -Dunix -D__uClinux__ -fomit-frame-pointer -fno-common -fno-builtin
LFLAGS=-Wl,-elf2flt="-r"
TARGET=hello
OBJECTS=$(TARGET).o
.PHONY: all
all: $(TARGET)
$(TARGET): $(OBJECTS)
$(CC) $(FLAGS) $(LFLAGS) -o $@ $^
%.o: %.c
$(CC) $(FLAGS) $(CFLAGS) -c $^
install:
cp $(TARGET) $(DEST)
clean:
rm -f *~ *.gdb *.o
DEST=/home/user/nfs
FLAGS=-Wall
CFLAGS=-Os -DEMBED -Dlinux -D__linux__ -Dunix -D__uClinux__ -fomit-frame-pointer -fno-common -fno-builtin
LFLAGS=-Wl,-elf2flt="-r"
TARGET=hello
OBJECTS=$(TARGET).o
.PHONY: all
all: $(TARGET)
$(TARGET): $(OBJECTS)
$(CC) $(FLAGS) $(LFLAGS) -o $@ $^
%.o: %.c
$(CC) $(FLAGS) $(CFLAGS) -c $^
install:
cp $(TARGET) $(DEST)
clean:
rm -f *~ *.gdb *.o
Еще я честно говоря не очень понимаю, каким образом elf файл hello.gdb c отладочной информацией должен согласовываться с flt файлом на целевом. Может у кого-нибудь был опыт отладки в подобных условиях?
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.