arm gcc toolchain как arm-elf или arm-none-eabi, в чем разница?
Когда вы создаете цепочку инструментов gcc, есть возможность построить ее как arm-elf или как arm-none-eabi, но в чем разница?
Сегодня я использую eabi, но это только потому, что все остальные, кажется, делают это… но поскольку это действительно плохой аргумент, было бы очень приятно понять разницу.
Примечание: эта цепочка инструментов будет кросскомпилировать код для Cortex-M3 на основе mcu:s, как и stm32.
Спасибо
Некоторые ссылки :
EABI:
ELF:
gcc
arm
elf
cortex-m3
eabi
Поделиться
Источник
Johan
11 мая 2011 в 09:01
4 ответа
- Генерация elf — файла из cpp с помощью arm-none-eabi-gcc
Я хочу сделать покрытие кода на исходном коде c++ на встроенном целевом объекте. Основная идея заключается в том, чтобы сгенерировать elf вместе с включенным покрытием-frofile-arcs-ftest-coverage с помощью gcc. Загрузите его на устройство ARM, а затем соберите данные для анализа покрытия кода с…
- Как скомпилировать ARM eabi toolchain?
я собираюсь скомпилировать kernel для моего устройства на базе aarch64 kernel источников готовы. и kernel документы говорят, что я должен использовать arm-встроенном-4.9 набор инструментов для ARM встроенном для составления kernel. но что это? другой тип компилятора GCC или что? это то же самое,…
39
Каждая архитектура или пара архитектура / ОС имеет ABI. ABI (двоичный интерфейс приложения) описывает, как должны вызываться функции, числа системных вызовов, передаваемые аргументы, какие регистры можно использовать …
Abi описывает, как компилятор должен генерировать ассемблер.
Если вы используете только ассемблер, вам не нужно заботиться о ABI.
arm-elf и arm-none-eabi просто используют две версии Arm ABI. Цепочка инструментов eabi использует более новую версию, но также может называться arm-elf-eabi, так как она также генерирует elf.
Поделиться
paul
15 мая 2011 в 07:46
38
Вот отличное объяснение.
Наборы соблюдать свободные правила именования: арка [поставщиков] [-ОС] -встроенном
arch refers to target architecture (which in our case is ARM)
vendor refers to toolchain supplier
os refers to the target operating system
eabi refers to Embedded Application Binary Interface
Некоторые примеры:
arm-none-eabi: эта цепочка инструментов нацелена на архитектуру ARM, не имеет поставщика, не нацелена ни на одну операционную систему и соответствует EABI ARM.
arm-none-linux-gnueabi: эта цепочка инструментов нацелена на архитектуру ARM, не имеет поставщика, создает двоичные файлы, работающие в операционной системе Linux, и использует GNU EABI. Он используется для таргетирования систем ARM-based Linux.
Поделиться
zhigang
17 апреля 2015 в 16:30
36
Насколько я знаю:
arm-ELF toolchain генерирует obj-код для некоторых OS, которые поддерживают выполнение формата elf (пример linux ABI). OS будет контролировать выполнение вашей программы.
arm-none-eabi toolchain генерирует obj-код для микроконтроллеров или микропроцессоров (для голого металла это будет EABI-embedded ABI). Этот код загружается для очистки flash от MC, а ядро MC начинает выполнять его после включения питания. Нет OS, расширенного набора команд, нет возможности связываться с общими модулями.
Поделиться
dartan
13 июня 2013 в 12:24
- make: arm-eabi-gcc: команда не найдена
android development noob здесь (до сих пор был просто веб-программистом), выход из моей лиги, и мог бы использовать несколько указателей.
я установил все, что перечислил здесь: http://forum.xda-developers.com/showthread.php?t=2474543, и получил результаты, приведенные ниже. позже я установил…
- arm-none-eabi-binutils и arm-none-eabi-gcc против binutils и gcc
Я нахожу arm-none-eabi-binutils и arm-none-eabi-gcc в папке /opt/local/var/macports/software в то время как обычные binutils и gcc находятся в папке /usr/bin в чем разница между ними? когда будут использоваться eabi-binutils и eabi-gcc? нацелены ли они на разные архитектуры?
4
На встроенном ARM-это стандарт, разработанный по ARM, что позволяет осуществлять различные наборы для создания совместимых объектов. Например, чтобы одна цепочка инструментов могла связывать объекты, созданные другой цепочкой инструментов.
Поделиться
Roger Dahl
12 марта 2012 в 16:51
Похожие вопросы:
В чем разница между arm-eabi-gcc и arm-elf-gcc?
В чем разница между arm-eabi-gcc и arm-elf-gcc? Могут ли они оба скомпилировать один и тот же исходный код для arch cortex-m3?
Можно ли смешать arm-eabi с arm-elf?
У меня есть продукт, загрузчик и приложение которого компилируются с помощью компилятора (gnuarm GCC 4.1.1), который генерирует arm-elf. Загрузчик и приложение разделены в разных областях памяти…
bin/arm-none-eabi-gcc и arm-none-eabi/bin/gcc
В чем разница между ними? Я взял этот пример из CodeSourcery toolchain, но я встречал подобную структуру в других цепочках инструментов. Оба они, кажется, имеют одинаковый размер. На моем хосте…
Генерация elf — файла из cpp с помощью arm-none-eabi-gcc
Я хочу сделать покрытие кода на исходном коде c++ на встроенном целевом объекте. Основная идея заключается в том, чтобы сгенерировать elf вместе с включенным покрытием-frofile-arcs-ftest-coverage с. ..
Как скомпилировать ARM eabi toolchain?
я собираюсь скомпилировать kernel для моего устройства на базе aarch64 kernel источников готовы. и kernel документы говорят, что я должен использовать arm-встроенном-4.9 набор инструментов для ARM…
make: arm-eabi-gcc: команда не найдена
android development noob здесь (до сих пор был просто веб-программистом), выход из моей лиги, и мог бы использовать несколько указателей. я установил все, что перечислил здесь:…
arm-none-eabi-binutils и arm-none-eabi-gcc против binutils и gcc
Я нахожу arm-none-eabi-binutils и arm-none-eabi-gcc в папке /opt/local/var/macports/software в то время как обычные binutils и gcc находятся в папке /usr/bin в чем разница между ними? когда будут…
связывание успешно выполняется с arm-none-eabi-g++, но не с arm-none-eabi-gcc
Я использую инструменты компилятора Launchpad Arm. Конкретно, arm-none-eabi-g++ и arm-none-eabi-gcc от: (GNU Tools for ARM Embedded Processors) 5.2.1 20151202 (release) [ARM/embedded-5-branch…
Есть ли какая-то разница в формате исполняемого файла, сгенерированного цепочками инструментов arm-elf и arm-none-eabi?
Я пытаюсь построить голый металлический проект arm. Я попробовал GNU цепочек инструментов arm-elf и arm-none-eabi . Исполняемые файлы, сгенерированные обеими цепочками инструментов, при…
Для чего нужны arm-none-eabi-c++ и arm-none-eabi-cpp?
Я использую GNU Arm Embedded Toolchain для кросс-компиляции на Windows, и мне было интересно, для чего используются следующие выделенные исполняемые файлы. Уже есть arm-none-eabi-gcc и…
Как установить gcc-arm-none-eabi для MinGW пользователей?
Я заинтересован в том, чтобы взять свою программу C++ и скомпилировать ее во что-то, что может работать на микроконтроллере ARM. Для этого мне необходимо установить gcc-arm-none-eabi
. В настоящее время я нахожусь на машине Windows 7, и поэтому я установил GCC/make/g++/etc. через MinGW.
Из исследований, которые я провел, кажется, что MinGW не поддерживает эту цепочку инструментов, что наводит меня на мысль, что разработка Windows на основе ARM невозможна. Поэтому я спрашиваю: как использовать MinGW для локальной установки цепочки инструментов gcc-arm-none-eabi
?
c++
windows
gcc
arm
cross-compiling
Поделиться
Источник
smeeb
19 мая 2015 в 19:23
2 ответа
- Кросс-компиляция библиотеки для arm-none-eabi-gcc
Мои проблемы здесь привели к решению / новой проблеме, которую я наивно построил во внешней библиотеке, которую использую для своей хост-машины. Таким образом, конечно, компилятор arm-none-eabi-gcc вызывает припадок, когда он встречает объектные файлы elf32-i386 . Первоначально я построил…
- Компиляция с использованием ошибки arm-none-eabi-gcc libc.a
Я пытаюсь скомпилировать для ARM Cortex M3 и получаю эту ошибку при построении программы Hello World. Пробовали строить с помощью —specs=rdimon.specs, что позволяет программе компилироваться, но затем она становится Killed целевой платформой. $ gcc-arm-none-eabi-5_2-2015q4/bin/arm-none-eabi-gcc…
4
Для этого вы можете использовать MinGW; вам просто нужно поменять цепочку инструментов C++ на выбранную вами. Вы все еще можете вызвать его из консоли MSYS, и все ваши другие инструменты по-прежнему будут работать. Нет ничего присущего MinGW или MSYS, что делает это «not supported».
Лично я устанавливаю GCC 4.9 gcc-arm-none-eabi из launchpad.net, mount каталога toolchain в MSYS, а затем экспортирую нужные мне пути:
mount 'C:\PROGRA~2\GNUTOO~1\4947E~1.920' /foo
mount 'C:\PROGRA~2\GNUTOO~1\4947E~1.
920\ARM-NO~1' /foo_local
Чтобы узнать краткое имя путей, напишите dir /X
в командной строке Windows. На моей машине пути выше эквивалентны следующим, соответственно:
C:\Program Files (x86)\GNU Tools ARM Embedded\4.9 2014q4
C:\Program Files (x86)\GNU Tools ARM Embedded\4.9 2014q4\arm-none-eabi
Монтаж необходимо выполнить только один раз; директивы export
могут быть добавлены к /etc/profile
:
export CPPFLAGS="-I/foo_local/include"
export CFLAGS="-I/foo_local/include"
export CXXFLAGS="-I/foo_local/include"
export LDFLAGS="-L/foo_local/lib -mthreads"
export PATH=".:/foo_local/bin:/foo/bin:/bin:/opt/bin"
Тогда просто запустите g++
.
Или, Конечно, вы можете пропустить все экспортные операции и просто вызвать выбранный вами GCC напрямую:
/foo/bin/g++
Поделиться
Lightness Races in Orbit
19 мая 2015 в 19:30
0
ELLCC-это еще один вариант. Для его запуска не обязательно устанавливать mingw или mingw-64, так как он статически связан. В этом посте говорится об использовании его для таргетинга Windows, но тот же двоичный файл также может быть использован для таргетинга ARM и других процессоров . Однако он основан на clang/LLVM, а не на gcc.
Поделиться
Richard Pennington
20 мая 2015 в 02:13
Похожие вопросы:
bin/arm-none-eabi-gcc и arm-none-eabi/bin/gcc
В чем разница между ними? Я взял этот пример из CodeSourcery toolchain, но я встречал подобную структуру в других цепочках инструментов. Оба они, кажется, имеют одинаковый размер. На моем хосте…
arm-none-eabi-binutils и arm-none-eabi-gcc против binutils и gcc
Я нахожу arm-none-eabi-binutils и arm-none-eabi-gcc в папке /opt/local/var/macports/software в то время как обычные binutils и gcc находятся в папке /usr/bin в чем разница между ними? когда будут. ..
Ошибка компиляции программы hello world C с arm-none-eabi-gcc
Я пытаюсь скомпилировать программу hello world в C году на машине Linux 64-bit. Я использую кросс-компилятор ARM для загрузки моего приложения на процессор ARM. Однако при компиляции кода с…
Кросс-компиляция библиотеки для arm-none-eabi-gcc
Мои проблемы здесь привели к решению / новой проблеме, которую я наивно построил во внешней библиотеке, которую использую для своей хост-машины. Таким образом, конечно, компилятор arm-none-eabi-gcc…
Компиляция с использованием ошибки arm-none-eabi-gcc libc.a
Я пытаюсь скомпилировать для ARM Cortex M3 и получаю эту ошибку при построении программы Hello World. Пробовали строить с помощью —specs=rdimon.specs, что позволяет программе компилироваться, но…
я не могу компилировать с arm-none-eabi-gcc
Я пытаюсь скомпилировать код с помощью arm-none-eabi-gcc , но получаю следующие ошибки. Может ли кто-нибудь помочь мне или объяснить, в чем заключается возможная причина? Спасибо!…
Флаг оптимизации не учитывается при компиляции с arm-none-eabi-gcc
Я хочу скомпилировать программу с arm-none-eabi-gcc 9.2.1 , используя проект libopencm3, и запустить ее на процессорах ARM Cortex-M4. Моя программа состоит из двух файлов: main.c #include…
Для чего нужны arm-none-eabi-c++ и arm-none-eabi-cpp?
Я использую GNU Arm Embedded Toolchain для кросс-компиляции на Windows, и мне было интересно, для чего используются следующие выделенные исполняемые файлы. Уже есть arm-none-eabi-gcc и…
Установка и использование arm-none-eabi-gcc на MSYS2
Я пытаюсь построить встроенную программу, используя make all с набором инструментов GNU ARM, но она пока не работает. Я установил его с помощью xpm в соответствии с этим сайтом с помощью установщика…
как указать Cortex-A53 в arm-none-eabi-gcc?
Я пытаюсь скомпилировать HELLOWORLD. c с arm-none-eabi-gcc в minGW, команда выглядит так: D:\code>arm-none-eabi-gcc hello.c -o hello -shared и это сработало, и генерирует hello, подробная…
Компилируем для ARM · Tuxotronic
Как известно, программный код на языке выского уровня сам в микроконтроллер не полезет,
его требуется предварительно скомпилировать в машинный код
(мы не берём интерпретируемые языки, но в этом случае в микроконтроллер должен быть уже прошит интерпретатор).
Для микроконтроллеров на базе ядра ARM/Cortex можно воспользовать кросскопилятором gcc-arm-none-eabi
.
Магическое название компилятора gcc-arm-none-eabi
означает следующее:
gcc
— название компилятора;arm
— архитектура процессора;none
— компилятор не вносит никакого дополнительного bootstrap кода от себя;eabi
— код соответствует спецификации EABI.
GCC ARM Embedded
Самый простой способ, это использовать готовые бинарные сборки для своей операционной системы. Доступны сборки для Linux, Mac, Windows.
Сборка уже все необходимые инструменты для компиляции ваших приложений а так же адаптированную для встраиваемых устройств стандартную библиотеку функция newlib.
TODO как распаковать и прописать пути.
Ubuntu
Если у вас Ubuntu 12.04/14.04/15.10⁄16.04 32⁄64-bit, то вы можете воспользоваться PPA репозиторием.
Debian
В свою очередь Debian начиная с Jessie содержит в своих репозиториях пакетов сборку arm-none-eabi-gcc
. Версии пакетов не самые свежие, но как правило вполне достаточные для работы.
Установить полный фарш можно командой:
sudo apt-get install -t jessie-backports gcc-arm-none-eabi binutils-arm-none-eabi gdb-arm-none-eabi libnewlib-arm-none-eabi libnewlib-dev libstdc++-arm-none-eabi-newlib
Дополнительно можно установить документацию по newlib
:
sudo apt-get install -t jessie-backports libnewlib-doc
Обратите внимание на параметр -t jessie-backports
. В моём случае он означает, что пакеты необходимо устанавливать из репозитория backports, там они новее, чем в stable версии.
Please enable JavaScript to view the comments powered by Disqus.
comments powered by
Архитектура | Версия | Размер пакета | В установленном виде | Файлы |
---|---|---|---|---|
alpha (неофициальный перенос) | 15:8-2019-q3-1+b1 | 31 485,8 Кб | 519 659,0 Кб | [список файлов] |
amd64 | 15:8-2019-q3-1+b1 | 30 147,0 Кб | 507 111,0 Кб | [список файлов] |
arm64 | 15:8-2019-q3-1+b1 | 28 216,3 Кб | 503 216,0 Кб | [список файлов] |
armel | 15:8-2019-q3-1+b1 | 26 661,1 Кб | 497 971,0 Кб | [список файлов] |
armhf | 15:8-2019-q3-1+b1 | 26 907,9 Кб | 484 675,0 Кб | [список файлов] |
hppa (неофициальный перенос) | 15:8-2019-q3-1+b1 | 29 943,6 Кб | 512 700,0 Кб | [список файлов] |
i386 | 15:8-2019-q3-1+b1 | 30 848,3 Кб | 511 531,0 Кб | [список файлов] |
m68k (неофициальный перенос) | 15:8-2019-q3-1+b1 | 27 338,9 Кб | 503 320,0 Кб | [список файлов] |
mips64el | 15:8-2019-q3-1+b1 | 28 900,1 Кб | 520 154,0 Кб | [список файлов] |
mipsel | 15:8-2019-q3-1+b1 | 28 846,2 Кб | 515 522,0 Кб | [список файлов] |
ppc64 (неофициальный перенос) | 15:8-2019-q3-1+b1 | 30 020,0 Кб | 524 108,0 Кб | [список файлов] |
ppc64el | 15:8-2019-q3-1+b1 | 30 496,2 Кб | 522 717,0 Кб | [список файлов] |
riscv64 (неофициальный перенос) | 15:8-2019-q3-1+b1 | 29 339,4 Кб | 495 808,0 Кб | [список файлов] |
s390x | 15:8-2019-q3-1+b1 | 28 411,5 Кб | 510 476,0 Кб | [список файлов] |
sh5 (неофициальный перенос) | 15:8-2019-q3-1 | 31 358,8 Кб | 498 913,0 Кб | [список файлов] |
sparc64 (неофициальный перенос) | 15:8-2019-q3-1+b1 | 27 220,4 Кб | 504 776,0 Кб | [список файлов] |
x32 (неофициальный перенос) | 15:8-2019-q3-1+b1 | 30 285,9 Кб | 503 860,0 Кб | [список файлов] |
ubuntu — Сообщение «Невозможно запустить arm-none-eabi-gdb: невозможно найти libncurses.
so.5″
Недавно я установил набор инструментов ARM GCC в Ubuntu 18.10 (Cosmic Cuttlefish), используя sudo apt-get install gcc-arm-none-eabi
, и пытаюсь запустить arm-none-eabi-gdb
.
Всякий раз, когда я пытаюсь запустить его, я получаю следующую ошибку:
arm-none-eabi-gdb: error while loading shared libraries: libncurses.so.5: cannot open shared object file: No such file or directory
Я попытался установить libncurses, используя sudo apt-get install libncurses5-dev libncursesw5-dev
— библиотеки успешно установлены, но у меня все еще остается та же проблема.
Я также проверил, чтобы файл был 64-битным: arm-none-eabi-gdb: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.24, BuildID[sha1]=340c78388950836989ecda5c89474e1bf7b03820, stripped
Что я могу попробовать отсюда?
1
user2828776
23 Ноя 2018 в 20:19
3 ответа
Лучший ответ
Я установил рабочий стол Ubuntu 18.10 (Космические каракатицы) с здесь, но я не смог установить gcc-arm-none-eabi:
[email protected]:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 18.10
Release: 18.10
Codename: cosmic
[email protected]:~$ sudo apt-get install gcc-arm-none-eabi
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to locate package gcc-arm-none-eabi
Затем я установил libncurses5-dev и gcc-linaro-7.3.1-2018.05-x86_64_arm и получил ту же ошибку, связанную с .so, которую вы получили.
Поскольку у меня нет этой проблемы ни с 16.04, ни с 18.04, я бы посоветовал вам скомпилировать последнюю версию GDB из исходного кода, чтобы избежать проблемы несоответствия библиотек пакетов / динамических ссылок в Ubuntu 18. 10:
sudo apt-get install build-essential libncurses5-dev libexpat1-dev texinfo-doc-nonfree
pushd /tmp
wget -qO- ftp://ftp.gnu.org/gnu/gdb/gdb-8.2.tar.xz | tar Jxv
mkdir gdb
cd gdb
../gdb-8.2/configure --enable-tui --with-expat --prefix=/usr/local --target=arm-eabi --program-prefix=arm-eabi-
make all
sudo make install
popd
Установить не удастся, потому что makeinfo отсутствует, хотя я установил texinfo-doc-nonfree, но будут установлены двоичные файлы:
ls /usr/local/bin
arm-eabi-gdb arm-eabi-gdb-add-index arm-eabi-run
И на этот раз arm-eabi-gdb запустится корректно:
arm-eabi-gdb --version
GNU gdb (GDB) 8.2
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
arm-eabi-gdb -tui
также будет работать — я рекомендую вам использовать TUI режим. Тебе должно нравиться это так же, как и мне — наверное.
0
Peter Mortensen
5 Дек 2019 в 20:53
Я начал работать над Kubuntu19.10, загрузив версия 2019 с arm.com вместо версии 2015 с панели запуска.
0
Kuky
4 Мар 2020 в 18:21
Я установил его на Kubuntu 19.10, установив:
apt install libncurses5
Не устанавливать 32-разрядные версии библиотеки «-dev», development или «: i386».
0
James
12 Фев 2020 в 10:32
Как установить arm-none-eabi-gcc 4.
9.3? — КодИндекс
Если совсем ничего непонятно, то делайте так:
- Разтарьте архив кросс-компиллера в любое место.
- Переложите его бинарники куда-то, куда считаете нужным. Например у меня они лежат в каталоге /usr/bin/ Под словом «бинарники» я понимаю файлы вида «arm-linux-gnueabihf-*». Среди них будет нечто вроде:
arm-linux-gnueabihf-ar arm-linux-gnueabihf-as ... arm-linux-gnueabihf-g++-5 arm-linux-gnueabihf-gcc-5
Не обязательно их ложить в /usr/bin/, можно в отдельный каталог, но тогда этот каталог нужно добавить в PATH. Туда же нужно положить и символические ссылки, если понадобятся.
- Создайте каталог проекта, в котором будет кросс-компилировать приложение.
В этом каталоге создайте tool-chain для cMake приблизительно такого вида:
$ cat ARM-toolchain
SET( CMAKE_C_COMPILER linux-gnueabihf-gcc ) SET( CMAKE_CXX_COMPILER linux-gnueabihf-g++ ) SET( CMAKE_STRIP arm-cortexa9_neon-linux-gnueabihf-strip ) SET( CMAKE_BUILD_TYPE MinSizeRel ) SET( CROSS true ) add_definitions( -DCROSS )
Обратите внимание, что здесь я уже использую символические ссылки, что бы не менять
toolchain при смене версии кросс-компиляторов. Вместо arm-linux-gnueabihf-gcc-5 я указал линк linux-gnueabihf-gcc которая указывает на версию компилятора по умолчанию.
- В каталоге проекта создайте CMakeLists.txt Что это такое, я здесь уж объяснять не буду.
- Создайте папку ARM_build и перейдите в эту папку.
Выполните команду:
cmake -DCMAKE_TOOLCHAIN_FILE=../ARM-toolchain ..
cmake возьмёт Вашу toolchain и создаст Makefile, в котором пропишет копиляторы для кросс-компиляции.
Запускаем сборку
make
- 20 янв 2019
2019-01-20 01:38:28 - Sergey
Обзор «вспомогательных» утилит из GCC toolchain.
Часть 1.
Думаю каждый, кто использует GCC, знает, что представляет из себя GCC toolchain. В данный комплект, помимо собственно компиляторов и линкера, входит ряд «вспомогательных» утилит из пакета GNU binutils. Эти утилиты отлично описаны в контексте применения в UNIX системах. А вот о «тонкостях» применения этих утилит при корос-компиляции под МК — информации немного. Предлагаю восполнить данный пробел.
Прежде всего, давайте вспомним, как выглядит «типичная» сборка GCC toolchain. Для примера возьмем yagarto (хотя в данном случае это не принципиально). Вот содержание каталога bin:
arm-none-eabi-addr2line.exe
arm-none-eabi-ar.exe
arm-none-eabi-as.exe
arm-none-eabi-c++.exe
arm-none-eabi-c++filt.exe
arm-none-eabi-cpp.exe
arm-none-eabi-elfedit.exe
arm-none-eabi-g++.exe
arm-none-eabi-gcc-4.6.0.exe
arm-none-eabi-gcc.exe
arm-none-eabi-gcov.exe
arm-none-eabi-gdb.exe
arm-none-eabi-gprof.exe
arm-none-eabi-ld.bfd.exe
arm-none-eabi-ld.exe
arm-none-eabi-nm.exe
arm-none-eabi-objcopy.exe
arm-none-eabi-objdump.exe
arm-none-eabi-ranlib.exe
arm-none-eabi-readelf.exe
arm-none-eabi-run.exe
arm-none-eabi-size.exe
arm-none-eabi-strings.exe
arm-none-eabi-strip.exe
«arm-none-eabi-» — это префикс, который позволяет отличить один установленный набор утилит для корос-компиляции от другого. На одном ПК может быть установлено несколько разных toolchain’ов под разные платформы и чтобы избежать конфликта имен (и не играться с переопределением PATH) все инструменты toolchain’a принято называть с определенного префикса. Например, в WINAVR название всех утилит начинается с «avr-» либо с «avr32-» (для семейств AVR и AVR32 соответственно).
Инструменты, предназначенные непосредственно для генерации кода (as, gcc, g++, ld), мы трогать не будем – это тема для отдельных статей. Также, пока, опустим отладчик (gdb). Давайте по порядку пройдемся по оставшимся утилитам.
addr2line
Как следует из названия, данная утилита позволяет получить номер сроки в С файле по абсолютному адресу в коде. На входе утилита принимает имя ELF-файла и абсолютный адрес.
Например:
arm-none-eabi-addr2line.exe -e LcdTest.elf 0x08001400
Результат:
D:\Tmp\LcdTest\Debug/../cmsis_boot/system_stm32f10x.c:666
Теперь мы знаем, что по адресу 0x08001400 в нашей прошивке содержится код, полученный при компиляции строки 666 файла system_stm32f10x.c.
Практическая полезность данной утилиты (IMHO) сомнительна. Для того чтобы утилита работала ELF файл должен содержать отладочную информацию (опция –g в GCC).
ar
Данная утилита предназначена для создания статических библиотек (*.а). На самом деле, статическая библиотека – это просто архив из объектных файлов (*.о). Соответственно, «ar» в названии утилиты – сокращение от archiver.
Например, мы хотим создать библиотеку с набором функций реализованных в файлах LED.c Font.c. Сначала компилируем эти файлы и получаем объектные файлы LED.o Font.o соответственно.
Теперь вызываем утилиту ar с ключом «q» (q – быстрое добавление в архив).
arm-none-eabi-ar.exe q liblcd.a Font.o LCD.o
liblcd.a – это имя библиотеки, которую мы хотим создать. Если библиотека с таким именем уже существует – то Font.o LCD.o будут добавлены в существующую библиотеку. В противном случае – будет создана новая библиотека.
Теперь можно подключить библиотеку к проекту, указав линкеру опцию –llcd.
Здесь следует обратить внимание, что отцы основатели (K&R) заложили следующую логику: имя библиотеки всегда начинается с префикса «lib», а в параметры линкера передается название библиотеки БЕЗ префикса и расширения. Вот такая «фича».
Рассмотрим еще несколько полезных ключей данной утилиты.
Ключ «t» позволяет просмотреть содержание архива (библиотеки):
arm-none-eabi-ar. exe t liblcd.a
Результат:
Font.o
LCD.o
Ключ «x» позволяет распаковать архив – извлечь объектные файлы из библиотеки.
arm-none-eabi-ar.exe x liblcd.a
Иногда это полезно при изучении сторонних библиотек.
На практике, в программировании под МК, библиотеки обычно распространяются в исходниках, которые программист просто включает в свой проект. Однако статические библиотеки иногда полезны. Например, таким образом можно спрятать свой «быдлокод» 🙂
c++filt
Утилита предназначена для декодирования имен С++ методов. Дело в том, что в С++ допускается «перегрузка» методов класса. В одном классе могут быть несколько методов с одинаковым именем (но они должны отличаться числом/типом принимаемых аргументов). При создании объектного файла компилятор кодирует имена методов определенным образом, в результате закодированные имена становятся уникальными (не повторятся в пределах объектного файла), но теряется «читабельность» имен. Вот утилита c++filt и позволяет декодировать такие имена.
Например, мы видим, что объектный файл содержит символ (метод/функцию) «getCount__7AverageFv». Вызываем c++filt и передаем ей на вход этот «шифр».
arm-none-eabi-c++filt.exe getCount__7AverageFv
Результат:
Average::getCount(void)
Все просто и понятно 🙂
elfedit
Утилита позволяет модифицировать некоторые поля в заголовке ELF файла. В нашем контексте – вещь абсолютно бесполезная.
gcov и gprof
Утилиты предназначены для анализа выполнения кода в рантайме. Другими словами – profiler.
Сразу скажу – во всех известных мне toolchain’ах эта, безусловно полезная, вещь не работает 🙁
Идея в следующем – мы компилируем нашу программу с опцией компилятора «-pg».
При этом компилятор генерирует дополнительный код при входе в каждую функцию. Этот код обирает статистику вызовов по каждой функции (сколько раз вызывалась функция, суммарное время выполнения функции).
Далее мы запускаем нашу программу, и вся статистика выгружается в специальный файл. Полученный файл мы скармливаем gprof и получаем детальный отчет по каждой функции – сколько раз она вызывалась, сколько времени выполнялась и т. д.
Например, из отчета следует, что функция А() выполнялась 90% времени от общего времени выполнения программы. Ура! Вот он кандидат для оптимизации №1! Вообще, profiler – очень полезная вещь при оптимизации.
Но, как уже было сказано, вся эта красота в нашем применении не работает. Компилятор просто не генерирует тот самый дополнительный код для сбора статистики. В этом я убедился, дизассемблируя код собранный с опцией «-pg». Об этом также пишут на форумах.
UPD: После комментария grand1987 решил еще раз все перепроверить. Оказалось компилятор (по крайней мере из yagarto ) генерирует дополнительный код (вставляет вызовы __gnu_mcount_nc() в начале каждой функции).
Попробую написать реализацию __gnu_mcount_nc() и собрать статистику.
Огромное спасибо grand1987, и извиняюсь за то, что ввел читателей в заблуждение.
nm
Утилита для анализа объектных файлов.
Сразу рассмотрим пример с ключом «-S» (S – показать размер для каждого символа):
arm-none-eabi-nm.exe -S LCD.o
Результат:
00000000 00000016 t ClrCS
00000000 00000016 t ClrRS
00000000 00000016 t ClrReset
00000000 00000016 t ClrWR
U GPIO_Init
U GPIO_ResetBits
U GPIO_SetBits
U GPIO_WriteBit
00000000 00000052 T LCD_Clear
00000000 0000004e t LCD_Delay
00000000 000000ba T LCD_DrawChar
00000000 00000158 T LCD_DrawCircle
00000000 000000d4 T LCD_DrawLine
00000000 0000003e T LCD_DrawStr
00000000 000003be T LCD_Init
00000000 00000056 t LCD_PortOutDir
00000000 0000006a t LCD_PortWrite
00000000 0000002e t LCD_SetCursor
00000000 0000002a T LCD_SetLine
00000000 00000032 T LCD_SetPoint
00000000 00000026 t LCD_WriteData
00000000 00000026 t LCD_WriteIndex
00000000 0000001a T LCD_WriteLine
00000000 00000026 t LCD_WriteReg
U RCC_APB2PeriphClockCmd
00000000 00000016 t SetRD
00000000 00000016 t SetRS
00000000 00000016 t SetReset
00000000 00000016 t SetWR
Мы видим все символы содержащиеся в данном объектном фале. Во второй колоне показан размер символа (переменной или функции) в HEX, далее идет тип символа (t – «text», функция НЕ экспортируемая из файла, static-функция; T – «text», функция экспортируемая из файла; U – внешя зависимость), далее идет собственно имя символа.
Например: 00000000 00000016 t ClrCS означает, что в данном обектном файле содержится не експортируемая (недоступная извне) функция с именем ClrCS, реализация функция занимает 16 HEX = 22 байта.
Данная утилита вполне юзабельна, более детально ознакомится с возможностями утилиты можно здесь.
В следующей статье мы рассмотрим оставшиеся утилиты из набора.
GNU Toolchain | Загрузки GNU Arm Embedded Toolchain — Arm Developer
GNU Arm Embedded Toolchain 2020-q2-preview
Это предварительная версия функций M-profile Vector Extension (MVE) и
Custom Datapath Extension (CDE), а не производственная версия.
Для создания инструментальной цепочки производственного качества используйте GNU Arm Embedded Toolchain
9-2020-q2-update release.
Этот выпуск включает предварительно созданные двоичные файлы для целей AArch42 EABI,
, которые могут быть размещены на:
* Windows 10 или более поздней версии на 32/64-разрядной архитектуре
* Linux
— на AArch64 (RHEL 7, Ubuntu 14.04 или новее)
— на x86_64 (RHEL 7, Ubuntu 16.04 или новее)
* Mac OS X 10.14 или новее на 64-битной архитектуре
Для Windows двоичные файлы предоставляются с установщиком и в виде zip-файла.
Для Linux двоичные файлы предоставляются в виде файлов tarball.
Для Mac OS X двоичные файлы предоставляются в виде файлов tarball и pkg.
Релиз также содержит пакет исходного кода (вместе со сценариями сборки и инструкциями
для настройки среды сборки), который состоит из:
* gcc: refs / vendors / ARM / Head / arm-10
git: // gcc.gnu.org/git/gcc.git commit 58ae4fa0f1563eacac56291c00c876e6594f9925
* binutils: master
git: //sourceware. org/git/binutils-gdb.git commit cceb53b8849bc76f5224118890b new 9853b849bc76f5229318890b новый git: //sourceware.org/git/newlib-cygwin.git commit 6d79e0a58866548f435527798fbd4a6849d05bc7
* gdb: master
git: //sourceware.org/git/binutils-gdb620002.com/ru/git/binutils-gdb620009/git/binutils-gdb620002/
c188553129c188553129ecb53002 следующие предварительные условия загружаются при сборке
из источника:
* EnvVarUpdate NSIS script:
http: // nsis.sourceforge.net/mediawiki/images/a/ad/EnvVarUpdate.7z
* expat 2.1.1:
https://downloads.sourceforge.net/project/expat/expat/2.1.1/expat-2.1.1. tar.bz2
* gmp 6.1.0:
https://gmplib.org/download/gmp/gmp-6.1.0.tar.bz2
* isl 0.18:
http: //isl.gforge.inria. fr / isl-0.18.tar.xz
* libelf 0.8.13:
https://fossies.org/linux/misc/old/libelf-0.8.13.tar.gz
* libiconv 1.15:
https: //ftp.gnu.org / pub / gnu / libiconv / libiconv-1.15.tar.gz
* mpc 1.0.3:
ftp://ftp.gnu.org/gnu/mpc/mpc-1.0.3.tar.gz
* mpfr 3.1.4:
http://www.mpfr.org/mpfr-3.1.4/mpfr-3.1.4.tar.bz2
* python 2.7.7:
https://www.python.org/ ftp / python / 2.7.7 / python-2.7.7.msi
* zlib 1.2.8:
http://www.zlib.net/fossils/zlib-1.2.8.tar.gz
Возможности:
* Все функции GCC 10.1
Тесты:
* Цели:
+ Разнообразие плат Cortex-M0 / M0 + / M3 / M4 / M7 / A9
+ Qemu
+ Arm Fast Models
Заметные изменения в предварительном выпуске 2020-q2 :
* Добавлена поддержка:
+ Ассемблер M-profile Vector Extension (MVE)
+ Custom Datapath Extension (CDE)
+ Cortex-M55
Известные проблемы:
* Выполнение IPA на CMSE приводит к ошибке компоновщика:
Компоновщик выдаст ошибку, если результирующий объектный файл будет содержать символ для
функции клонирования с __acle_ se с нелокальной привязкой.
Проблема возникает при компиляции двоичных файлов для M-profile Secure Extensions, где
компилятор может решить клонировать функцию с атрибутом cmse_nonsecure_entry
.
Хотя клонирование незащищенных функций входа является законным, пока клон
используется только внутри защищенного приложения, сама функция клонирования
не должна рассматриваться как безопасная точка входа, и поэтому она не должна иметь префикса __acle_se
.
Возможный обходной путь для этого — добавить атрибут noclone к функциям
с помощью cmse_nonsecure_entry.Это предотвратит клонирование
таких функций GCC.
* Загрузка или сохранение типа __fp16 вместе с MVE может сгенерировать недопустимый код:
Если вы используете тип __fp16 вместе с включенным MVE, тогда, когда компилятору потребуется
для генерации инструкции для загрузки регистра расширения с плавающей точкой
(регистр S ) из памяти или инструкции для сохранения регистра расширения
с плавающей точкой (регистр S) в памяти, то компилятор сгенерирует неправильную инструкцию сборки
.
Неправильная инструкция сборки генерируется внешним интерфейсом для любой оптимизации
, кроме -O0.Неправильная инструкция вызывает ошибку во время сборки
, например:
«Ошибка: инструкция не поддерживает обратную запись -` vstr.16 s15, [r0]! ‘»«
»Ошибка: инструкция не поддерживает обратную запись -` vldr.16 s15 , [r0]! ‘»
Временным решением является использование параметра командной строки -O0 для генерации правильной инструкции
при загрузке или сохранении типа __fp16 вместе с MVE.
* При распаковке zip-файла Windows запрашивается разрешение на перезапись файла:
Когда вы распаковываете zip-файл Windows,
gcc-arm-none-eabi-10-2020-q2-preview-win32.zip, при распаковке запрашивается разрешение
на перезапись файла frame-apply.html. Это связано с тем, что документация GDB
в папке share / doc / gcc-arm-none-eabi / html / gdb содержит файлы с именами
frame-apply.html и Frame-Apply.html, которые на
хост Windows.
Вы можете перезаписать файл frame-apply.html с помощью Frame-Apply.html. Если вы
распаковываете zip-файл с помощью инструмента командной строки, вы можете использовать параметр командной строки, чтобы
автоматически перезаписал файл, например, используя параметр командной строки -y с 7zip.
* Readme.txt ссылки на версию 9.3 онлайн-документов GCC:
Readme.txt содержит следующие ссылки на версию 9.3 онлайн-документов GCC:
https://gcc.gnu.org/onlinedocs/gcc-9.3. 0 / gcc / ARM-Options.html # index-mcpu-2
https://gcc.gnu.org/onlinedocs/gcc-9.3.0/gcc/ARM-Options.html#index-mfloat-abi
Правильный ссылки на версию 10.1 онлайн-документов GCC:
https://gcc.gnu.org/onlinedocs/gcc-10.1.0/gcc/ARM-Options.html#index-mcpu-2
https: // gcc.gnu.org/onlinedocs/gcc-10.1.0/gcc/ARM-Options.html#index-mfloat-abi
Установка Cross Tools для ARM — последняя документация Apache Mynewt
На этой странице показано, как установить инструменты для сборка, запуск и отладка
Приложения Mynewt OS, работающие на поддерживаемых целевых платах ARM. Это показывает
вы, как установить следующие инструменты в Mac OS, Linux и Windows:
ARM поддерживает предварительно созданный набор инструментов GNU с gcc и gdb, ориентированный на
Встроенные процессоры ARM, а именно семейства процессоров Cortex-R / Cortex-M.Mynewt OS была протестирована с версией набора инструментов 4.9, и мы
рекомендую вам установить эту версию, чтобы начать работу. Mynewt OS будет
в конечном итоге работать с несколькими доступными версиями, включая последнюю
выпускает.
Установка ARM Toolchain для Mac OS X¶
Добавьте кран для домашнего пивоварения PX4 / homebrew-px4 и установите версию 4.9
набор инструментов. После установки убедитесь, что символьная ссылка на доморощенный
created указывает на правильную версию отладчика.
$ кран для варки PX4 / homebrew-px4 $ brew update $ brew install gcc-arm-none-eabi-49 $ arm-none-eabi-gcc --version arm-none-eabi-gcc (Инструменты GNU для встроенных процессоров ARM) 4.9.3 20150529 (выпуск) [ARM / embedded-4_9-branch revision 224288] Авторское право (C) 2014 Free Software Foundation, Inc. Это бесплатное программное обеспечение; см. источник для условий копирования. Здесь нет гарантия; даже не для КОММЕРЧЕСКОЙ ЦЕННОСТИ или ПРИГОДНОСТИ ДЛЯ КОНКРЕТНОЙ ЦЕЛИ.$ ls -al / usr / местный / bin / arm-none-eabi-gdb lrwxr-xr-x 1 aditihilbert admin 69 22 сентября 17:16 / usr / local / bin / arm-none-eabi-gdb -> / usr / local / Cellar / gcc-arm-none-eabi-49/20150609 / bin / arm-none-eabi-gdb
Примечание. Если версия не указана, brew установит последнюю версию
версия доступна.
Установка ARM Toolchain для Windows¶
Загрузите и запустите установщик
для установки arm-none-eabi-gcc и arm-none-eabi-gdb. Выберите значение по умолчанию
папка назначения: C: \ Program Files (x86) \ GNU Tools ARM Embedded \ 8 2018-q4-major.Примечания:
Установите флажок
Добавить путь к переменной среды
, прежде чем нажимать кнопкуЗавершить
для установки.Вы можете выбрать другую папку, но установку
инструкции используют значения по умолчанию.
Убедитесь, что вы используете установленные версии
arm-none-eabi-gcc и arm-none-eabi-gdb. Откройте терминал MinGW и запустите
, который командует
.Примечание. Чтобы унаследовать новый терминал, необходимо запустить новый терминал MinGW.
Значения пути.$ который arm-none-eabi-gcc / c / Program Files (x86) / GNU Tools ARM Embedded / 8 2018-q4-major / bin / arm-none-eabi-gcc $ который arm-none-eabi-gdb / c / Program Files (x86) / GNU Tools ARM Embedded / 8 2018-q4-major / bin / arm-none-eabi-gdb
Mynewt использует, в зависимости от платы, OpenOCD или SEGGER J-Link.
отладчики.
Установка отладчика OpenOCD¶
OpenOCD (открытый на кристалле
Debugger) — это программное обеспечение с открытым исходным кодом, которое позволяет вашему компьютеру взаимодействовать
с разъемом отладки JTAG на различных платах. JTAG-соединение
позволяет отлаживать и тестировать встроенные целевые устройства. Чтобы узнать больше об OpenOCD, перейдите
по адресу http://openocd.org.
Требуется
OpenOCD версии 0. 10.0 с поддержкой nrf52. Бинарный файл для этого
версия доступна для загрузки для Mac OS, Linux и Windows.
Установка OpenOCD в Mac OS¶
Установите последнюю версию OpenOCD с Homebrew:
$ brew обновить $ brew install open-ocd --HEAD
Проверьте версию OpenOCD, которую вы используете:
$ который openocd / USR / местные / бен / openocd $ openocd -v Откройте встроенный отладчик 0.10.0 Под лицензией GNU GPL v2 Для отчетов об ошибках прочтите http://openocd.org/doc/doxygen/bugs.html
Вы должны увидеть версию: 0.10.0 + dev-
.
Установка OpenOCD в Linux¶
Загрузите двоичный архив для
LinuxПерейти в корневой каталог:
Распакуйте архив и установите его в / usr / local / bin. Ты
необходимо заменить ~ / Downloads на каталог, в котором
tarball загружается в.Примечание. Для команды tar необходимо указать параметр -p.
$ sudo tar -xpf ~ / Загрузки / openocd-bin-0.10.0-Linux.tgz
Проверьте версию OpenOCD, которую вы используете:
$ который openocd / USR / местные / бен / openocd $ openocd -v Откройте встроенный отладчик 0.10.0 Под лицензией GNU GPL v2 Для отчетов об ошибках прочтите http://openocd.org/doc/doxygen/bugs.html
Вы должны увидеть версию: 0.10.0.
Если вы видите одно из этих сообщений об ошибке:
openocd: ошибка при загрузке разделяемых библиотек: libhidapi-hidraw.итак.0:
невозможно открыть файл общих объектов: нет такого файла или каталогаopenocd: ошибка при загрузке разделяемых библиотек: libusb-1.0.so.0:
невозможно открыть файл общих объектов: нет такого файла или каталога
выполните следующую команду для установки библиотек:
$ sudo apt-get install libhidapi-dev: i386
Установка OpenOCD в Windows¶
Загрузите двоичный zip-файл для
Windows.Распаковать в C: \ openocd-0.Папка 10.0.
Добавьте путь: C: \ openocd-0.10.0 \ bin к вашему пользователю Windows
Переменная среды пути. Примечание: вы должны добавить корзину к пути.Проверьте версию OpenOCD, которую вы используете. Откройте новый MinGW
терминал и выполните следующие команды:Примечание. Чтобы унаследовать новый терминал, необходимо запустить новый терминал MinGW.
Значения пути.$ который openocd /c/openocd-0.10.0/bin/openocd $ openocd -v Откройте встроенный отладчик 0.10.0 Под лицензией GNU GPL v2 Для отчетов об ошибках прочтите http: // openocd.org / doc / doxygen / bugs.html
Вы должны увидеть версию: 0.10.0.
Установка SEGGER J-Link¶
Вы можете загрузить и установить пакет программного обеспечения и документации Segger J-LINK с веб-сайта
СЕГГЕР.
Примечание. В Windows после установки выполните следующие действия:
Добавьте путь к папке назначения установки вашему пользователю Windows
Переменная среды пути. Вам не нужно добавлять корзину в
путь.Откройте новый терминал MinGW, чтобы унаследовать новые значения Path.
Код Visual Studio
— конфигурация задачи для arm-none-eabi-gcc
Мне нужна помощь в правильной настройке файла task.json для сборки проекта C / C ++ с компилятором arm-none-eabi-gcc
.
Я могу скомпилировать C-проект как arm-none-eabi-gcc -specs = nosys.specs hello_c.c -o hello_c.out
из командной строки.
, но конфигурация с использованием task.json под vscode
"версия": "2.0.0",
"задания": [
{
"тип": "cppbuild",
"label": "arm-none-eabi-gcc build активный файл",
"command": "c: \\ Program Files (x86) \\ GNU Arm Embedded Toolchain \\ 9 2020-q2-update \\ bin \\ arm-none-eabi-gcc.исполняемый файл",
"аргументы": [
"-specs = nosys.
specs",
"$ {file}",
"-о",
"$ {fileDirname} \\ $ {fileBasenameNoExtension} .bin"
],
"опции": {
"cwd": "c: \\ Program Files (x86) \\ GNU Arm Embedded Toolchain \\ 9 2020-q2-update \\ bin"
},
"проблемаМатчер": [
"$ gcc"
],
"группа": {
"вид": "строить",
"isDefault": true
},
"деталь": "компилятор: c: \ Program Files (x86) \ GNU Arm Embedded Toolchain \\ 9 2020-q2-update \\ bin \\ arm-none-eabi-gcc.исполняемый файл"
}
]
}
выводит
> Выполнение задачи: arm-none-eabi-gcc build active file <
Начинаем сборку ...
Сборка завершена с ошибкой:
c: / program files (x86) / gnu arm embedded toolchain / 9 2020-q2-update / bin /../ lib / gcc / arm-none-eabi / 9.3.1 /../../../. ./arm-none-eabi/bin/ld.exe: c: / program files (x86) / gnu arm встроенный набор инструментов / 9 2020-q2-update / bin /../ lib / gcc / arm-none-eabi / 9.3.1 /../../../../ arm-none-eabi / lib \ libg.a (lib_a-exit.o): в функции `exit ':
выход.c :(. text.exit + 0x2c): неопределенная ссылка на `_exit '
c: / program files (x86) / gnu arm embedded toolchain / 9 2020-q2-update / bin /../ lib / gcc / arm-none-eabi / 9.3.1 /../../../. ./arm-none-eabi/bin/ld.exe: c: / program files (x86) / gnu arm встроенный набор инструментов / 9 2020-q2-update / bin /../ lib / gcc / arm-none-eabi / 9.3.1 /../../../../ arm-none-eabi / lib \ libg.a (lib_a-sbrkr.o): в функции `_sbrk_r ':
sbrkr.c :(. text._sbrk_r + 0x18): неопределенная ссылка на `_sbrk '
c: / программные файлы (x86) / gnu arm встроенный набор инструментов / 9 2020-q2-update / bin /../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/bin/ld.exe: c: / программные файлы (x86) / gnu встроенный набор инструментов для руки / 9 2020-q2-update / bin /../ lib / gcc / arm-none-eabi / 9.3.1 /../../../../ arm-none-eabi / lib \ libg.
a (lib_a-writer.o): в функции `_write_r ':
writer.c :(. text._write_r + 0x28): неопределенная ссылка на `_write '
c: / program files (x86) / gnu arm embedded toolchain / 9 2020-q2-update / bin /../ lib / gcc / arm-none-eabi / 9.3.1 /../../../. ./arm-none-eabi/bin/ld.exe: c: / program files (x86) / gnu arm встроенный набор инструментов / 9 2020-q2-update / bin /../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/lib\libg.a(lib_a-closer.o): в функции ` _close_r ':
close.c :(. text._close_r + 0x18): неопределенная ссылка на `_close '
c: / program files (x86) / gnu arm embedded toolchain / 9 2020-q2-update / bin /../ lib / gcc / arm-none-eabi / 9.3.1 /../../../. ./arm-none-eabi/bin/ld.exe: c: / program files (x86) / gnu arm встроенный набор инструментов / 9 2020-q2-update / bin /../ lib / gcc / arm-none-eabi / 9.3.1 /../../../../ arm-none-eabi / lib \ libg.a (lib_a-lseekr.o): в функции `_lseek_r ':
lseekr.c :(.text._lseek_r + 0x28): неопределенная ссылка на `_lseek '
c: / program files (x86) / gnu arm embedded toolchain / 9 2020-q2-update / bin /../ lib / gcc / arm-none-eabi / 9.3.1 /../../../. ./arm-none-eabi/bin/ld.exe: c: / program files (x86) / gnu arm встроенный набор инструментов / 9 2020-q2-update / bin /../ lib / gcc / arm-none-eabi / 9.3.1 /../../../../ arm-none-eabi / lib \ libg.a (lib_a-readr.o): в функции `_read_r ':
readr.c :(. text._read_r + 0x28): неопределенная ссылка на `_read '
c: / программные файлы (x86) / gnu arm встроенный набор инструментов / 9 2020-q2-update / bin /../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/bin/ld.exe: c: / программные файлы (x86) / gnu встроенный набор инструментов arm / 9 2020-q2-update / bin /../ lib / gcc / arm-none-eabi / 9.3.1 /../../../../ arm-none-eabi / lib \ libg.a (lib_a-fstatr.o): в функции `_fstat_r ':
fstatr.c :(. text._fstat_r + 0x20): неопределенная ссылка на `_fstat '
c: / program files (x86) / gnu arm embedded toolchain / 9 2020-q2-update / bin /../ lib / gcc / arm-none-eabi / 9.3.1 /../../../.
./arm-none-eabi/bin/ld.exe: c: / program files (x86) / gnu arm встроенный набор инструментов / 9 2020-q2-update / bin /../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/lib\libg.a(lib_a-isattyr.o): в функции ` _isatty_r ':
isattyr.c :(. text._isatty_r + 0x18): неопределенная ссылка на `_isatty '
collect2.exe: ошибка: ld вернул 1 статус выхода
Не удалось запустить процесс терминала (код выхода: -1).
xPack GNU Arm Embedded GCC v9.3.1-1.1 выпущен
Версия 9.3.1-1.1 — это новый выпуск xPack GNU Arm Embedded GCC, следующий за выпуском Arm от 1 июня 2020 г. (версия 9-2020-q2-update).Это также первый выпуск, в котором добавлена поддержка работы на платформах Arm, таких как Raspberry Pi.
Это дистрибутив xPack
GNU Arm Embedded Toolchain.
Существуют отдельные двоичные файлы для Windows, macOS и
GNU / Linux, 32/64-бит.
Начиная с этой версии, поддержка 32/64-битных платформ Arm GNU / Linux,
как и Raspberry Pi.
Скачать
Бинарные файлы доступны в выпусках GitHub.
Установить
Полная информация об установке xPack GNU Arm Embedded GCC на
различные платформы представлены в отдельных
Установить страницу.
Простая установка
Самый простой способ установить GNU Arm Embedded GCC — это
x мин.
используя двоичный xPack, доступный как
@ xpack-dev-tools / arm-none-eabi-gcc
из реестра npmjs.com
.
Чтобы установить последнюю доступную версию, используйте:
$ xpm install --global @ xpack-dev-tools / arm-none-eabi-gcc @ latest
Чтобы установить эту конкретную версию, используйте:
$ xpm install --global @ xpack-dev-tools / arm-none-eabi-gcc @ 9.3.1-1.1.1
Соответствие
Этот выпуск следует за официальным
Встроенный набор инструментов GNU Arm
9-2020-q2-update релиз от 1 июня 2020 г. и основан на
gcc-arm-none-eabi-9-2020-q2-update-src.tar.bz2
исходный инвариант.
Для получения дополнительной информации см. Исходные текстовые файлы релиза Arm:
-
информация о дистрибутиве / arm-readme.txt
-
информация о дистрибутиве / arm-release.txt
Поддерживаемые библиотеки
Поддерживаемые библиотеки:
$ arm-none-eabi-gcc -print-multi-lib
.;
arm / v5te / softfp; @ марм @ марш = armv5te + fp @ mfloat-abi = softfp
arm / v5te / hard; @ marm @ march = armv5te + fp @ mfloat-abi = хард
thumb / nofp; @ mthumb @ mfloat-abi = мягкий
thumb / v7 / nofp; @ mthumb @ march = armv7 @ mfloat-abi = мягкий
большой палец / v7 + fp / softfp; @ mthumb @ march = armv7 + fp @ mfloat-abi = softfp
thumb / v7 + fp / hard; @ mthumb @ march = armv7 + fp @ mfloat-abi = жесткий
большой палец / v7-r + fp.sp / softfp; @ mthumb @ march = armv7-r + fp.sp @ mfloat-abi = softfp
thumb / v7-r + fp.sp / hard; @ mthumb @ march = armv7-r + fp.sp @ mfloat-abi = жесткий
thumb / v6-m / nofp; @ mthumb @ march = armv6s-m @ mfloat-abi = мягкий
thumb / v7-m / nofp; @ mthumb @ march = armv7-m @ mfloat-abi = мягкий
thumb / v7e-m / nofp; @ mthumb @ march = armv7e-m @ mfloat-abi = мягкий
большой палец / v7e-m + fp / softfp; @ mthumb @ march = armv7e-m + fp @ mfloat-abi = softfp
thumb / v7e-m + fp / hard; @ mthumb @ march = armv7e-m + fp @ mfloat-abi = жесткий
большой палец / v7e-m + dp / softfp; @ mthumb @ march = armv7e-m + fp.dp @ mfloat-abi = softfp
thumb / v7e-m + dp / hard; @ mthumb @ march = armv7e-m + fp.dp @ mfloat-abi = жесткий
thumb / v8-m.base / nofp; @ mthumb @ march = armv8-m.base @ mfloat-abi = мягкий
thumb / v8-m.main / nofp; @ mthumb @ march = armv8-m.main @ mfloat-abi = мягкий
thumb / v8-m.main + fp / softfp; @ mthumb @ march = armv8-m.main + fp @ mfloat-abi = softfp
thumb / v8-m.main + fp / hard; @ mthumb @ march = armv8-m.main + fp @ mfloat-abi = жесткий
thumb / v8-m.
main + dp / softfp; @ mthumb @ march = armv8-m.main + fp.dp @ mfloat-abi = softfp
thumb / v8-m.main + dp / hard; @ mthumb @ march = armv8-m.main + fp.dp @ mfloat-abi = hard
Исправления ошибок
Изменения
Функциональных изменений быть не должно.
Начиная с 9.x, новые архивы создаются с помощью
одна папка с именем xpack-arm-none-eabi-gcc-9.3.1-1.1
вместо
иерархический xPacks / arm-none-eabi-gcc / 9.3.1-1.1
. Этот внутренний
имя папки используется единообразно на всех платформах. Расширение архива
был изменен на .tar.gz
.
С этими изменениями архивы теперь могут использоваться непосредственно в других
среды разработки (например, Arduino), без необходимости их перепаковывать.
Питон
В GDB добавлена поддержка сценариев Python.Этот дистрибутив обеспечивает
два отдельных двоичных файла,
arm-none-eabi-gdb-py
с поддержкой Python 2.7 и arm-none-eabi-gdb-py3
с поддержкой
поддержка Python 3.7.
Необходимо, чтобы были установлены именно эти версии, в противном случае
GDB не запускается должным образом.
Для этого рекомендуется установить двоичные файлы, предоставленные
Python,
не те, которые есть в дистрибутиве, так как они могут быть неполными, для
например, те, что в Ubuntu / Debian, которые разбивают системную библиотеку Python на
несколько пакетов.
В GNU / Linux рекомендуется сборка из исходных кодов, и
установить локально:
python3_version = "3.7.9"
mkdir -p "$ {HOME} / Загрузки"
curl -L --fail -o "$ {HOME} / Downloads / Python - $ {python3_version} .tgz" https://www.python.org/ftp/python/${python3_version}/Python-${python3_version} .tgz
rm -rf "$ {HOME} / Work / Python - $ {python3_version}"
mkdir -p "$ {HOME} / Работа"
cd "$ {HOME} / Work"
tar xzf "$ {HOME} / Downloads / Python - $ {python3_version} .tgz"
cd "$ {HOME} / Work / Python - $ {python3_version}"
баш./ configure --prefix = "$ {HOME} / opt"
делать
сделать altinstall
Чтобы запустить GDB с этой версией Python, используйте скрипт для установки правильного
среда, например:
mkdir -p "$ {HOME} / opt / bin"
cat << '__ EOF__'> "$ {HOME} /opt/bin/arm-none-eabi-gdb-py3.
sh"
#! / usr / bin / env bash
PYTHONPATH = "$ ($ HOME / opt / bin / python3.7 -c 'import os; import sys; print (os.pathsep.join (sys.path))')" \
PYTHONHOME = "$ ($ HOME / opt / bin / python3.7 -c 'import sys; print (sys.prefix)')" \
arm-none-eabi-gdb-py3 "$ @"
__EOF__
chmod + x "$ {HOME} / opt / bin / arm-none-eabi-gdb-py3.ш "
Текстовый интерфейс пользователя (TUI)
В GDB добавлена поддержка TUI. Библиотека ncurses
(v6.2) была добавлена в
распространение.
Примечание. TUI недоступен в Windows.
Известные проблемы
- двоичные файлы GDB с поддержкой Python были собраны с версией 2.7 / 3.7,
и требуют именно этих версий для правильной работы; - Исключения C ++ в библиотеках, отличных от нано, не перехватываются; фиксируется в
9.3.1-1.2.
Общие библиотеки
На всех платформах пакеты являются автономными и ожидают только стандартные
время выполнения присутствовать на хосте.
Все зависимости, построенные как разделяемые библиотеки, копируются локально в
в той же папке, что и исполняемый файл.
дорожка
В GNU / Linux двоичные файлы настроены на использование относительного пути:
$ readelf -d library.so | grep runpath
0x000000000000001d (RUNPATH) Путь выполнения библиотеки: [$ ORIGIN]
Обратите внимание, что в GNU ld.так что стратегия поиска DT_RUNPATH
имеет
более низкий приоритет, чем LD_LIBRARY_PATH
, поэтому, если установлен этот более поздний
в среде это может мешать двоичным файлам xPack.
@executable_path
Точно так же в macOS динамические библиотеки настроены с помощью otool
для использования
относительный путь.
Документация
Исходная документация в формате PDF находится в папке share / doc
.
Поддерживаемые платформы
Предоставляются бинарные файлы
для Windows, macOS и GNU / Linux.
Бинарные файлы были собраны с использованием
xPack Build Box (XBB), набор
среды сборки, основанной на немного более старых дистрибутивах, это должно быть
совместим с самыми последними системами.
- Intel GNU / Linux: все двоичные файлы были собраны с GCC 9.3, запущены в
Контейнер Docker в Ubuntu 12 - Arm GNU / Linux: все двоичные файлы были собраны с GCC 9.3, запущены в
Контейнер Docker для Ubuntu 16 - Windows: все двоичные файлы были собраны с помощью mingw-w64 GCC 9.3, работающего в
Контейнер Docker в Ubuntu 12 - macOS: все двоичные файлы были собраны с использованием GCC 9.3, работающая в отдельном
папка в macOS 10.10.5.
Сборка
Скрипты, использованные для сборки этого дистрибутива, находятся в:
Предварительные требования и дополнительные сведения о процедуре сборки см. В
Как создать page.
Тесты Трэвиса
Первая серия тестов была проведена на Трэвисе, запустив
простой скрипт для проверки запуска двоичных файлов и компиляция нескольких простых
программ на широком спектре платформ и дистрибутивов:
Тесты
Бинарные файлы были тестами на Windows 10 Pro 32/64-bit, Ubuntu 18 LTS 64-bit,
Xubuntu 18 LTS 32-бит и macOS 10.13.
Тесты состоят в построении и отладке некоторых
простые проекты Eclipse
имеется в проекте.
Поскольку исходный код, используемый для GCC, идентичен тому, который используется Arm,
длинные и сложные тесты, проведенные Arm для подтверждения их выпуска, не были
снова казнен.
Контрольные суммы
Хэши SHA-256 для файлов:
6f5e5b94ecf2afece992b46a60465e3ed5aae172202c2a4e34f8e81e5b0da790
xpack-arm-none-eabi-gcc-9.3.1-1.1-дарвин-x64.tar.gz
8791f653f1fc15b004987a2b84a7c0aabd71bde11e0e68eb32846e9b1ad80986
xpack-arm-none-eabi-gcc-9.3.1-1.1-linux-arm64.tar.gz
bb4e1f6c72e32a1696edcfdec57d32ece64ac691a0363e4781db559addac7b79
xpack-arm-none-eabi-gcc-9.3.1-1.1-linux-arm.
tar.gz
be98731e1bb05fd78e2ec5727f7d6c9a6f2ae548970bbd0998de7079021d8e11
xpack-arm-none-eabi-gcc-9.3.1-1.1-linux-x32.tar.gz
10b859d83c7a451add58eaf79afdb9a4a66fc38920884e8a54c809e0a1f4ed3e
xpack-arm-none-eabi-gcc-9.3.1-1.1-linux-x64.tar.gz
5cc86c9d17c4fda97107b374ae939fedf9d7428d06e6c31418ea0e5ff1e6aa41
xpack-arm-none-eabi-gcc-9.3.1-1.1-win32-x32.zip
91ab5e1b9b3ffcc606262e2be96bd70ab0be26a42d21e610340412f65de2bb16
xpack-arm-none-eabi-gcc-9.3.1-1.1-win32-x64.zip
Скачать аналитику
Кредит для Shields IO за значки и
Сомсубра / github-release-stats
для индивидуальных счетчиков файлов.
Переключение ARM GNU gcc Toolchain в Eclipse
CodeWarrior для MCU10.3 поставляется с установленной ARM GNU 4.6.2:
gcc 4_6_2 в макете MCU10.3
А как насчет перехода на другой (более новый) gcc?
Используемая инструментальная цепочка ARM GCC GNU предоставляется и поддерживается ARM Inc.в Launchpad. MCU10.3 был выпущен в начале декабря 2012 года, и только в конце декабря ARM выпустила новую версию 4.7 gcc. Так что есть смысл хотя бы попробовать новую 4.7.
Для этого я скопировал схему установки MCU10.3 и добавил набор инструментов 4.7. Чтобы избежать конфликтов, я удалил набор инструментов 4.6, поэтому у меня есть такая структура:
gcc 4_7_0 в макете MCU10.3
Примечание: на момент написания этой статьи уже существует версия 4.7.есть в наличии 2.
Хорошая новость: мои существующие проекты работали нормально. Запутывающая часть заключалась в том, что существующие проекты, созданные с помощью 4.6.0, создавали эти предупреждения об аутентификации:
Описание Тип местоположения пути к ресурсу Неверный путь к проекту: путь включения не найден (C: \ Freescale \ CW MCU v10.3_gcc4_7_0 \ Cross_Tools \ arm-none-eabi-gcc-4_7_0 \ lib \ gcc \ arm-none-eabi \ 4.6.2 \ include-fixed) . Freedom_Blue Проблема входа в путь пути Неверный путь к проекту: Включить путь не найден (C: \ Freescale \ CW MCU v10.3_gcc4_7_0 \ Cross_Tools \ arm-none-eabi-gcc-4_7_0 \ lib \ gcc \ arm-none-eabi \ 4.6.2 \ include). Проблема входа пути Freedom_Blue
Предупреждения из-за разных gcc
Похоже, что система сборки Eclipse каким-то образом перепутала 4.6.2 и 4.7.0? Я проверил настройки проекта и пути, но не нашел места для исправления предупреждений. Очистка и восстановление не помогли. И Google на этот раз мне не друг :-(. Что теперь?
Что ж, после долгих часов поисков и проб я наконец нашел решение, которое работает.Уловка состоит в том, чтобы зайти в Project> Properties> C / C ++ Build> Discovery Options. Здесь и компилятор, и ассемблер настроены для «открытия»: таким образом инструментальная цепочка может находить свои библиотеки и пути поиска. Очевидно, это не сработало для меня.
Очистка информации об обнаружении
Итак, решение состоит в том, чтобы выбрать один инструмент (ARM Ltd Windows GCC C Compiler и ARM Ltd Windows GCC Assembler) и очистить обнаруженные записи (кнопка «Очистить»). Это вызовет неформальный диалог:
Записи открытий очищены
На этом моя проблема решена.
❓ Инструменты сборки Eclipse GNU хранят такую информацию в папке .metadata рабочей области. В моем вышеупомянутом случае я использовал ту же рабочую область с измененными инструментами сборки GNU. Этой проблемы можно было бы избежать, если бы я использовал отдельные рабочие области для каждого варианта компоновки Eclipse.
Счастливой постановки на охрану 000
Нравится:
Нравится Загрузка …
Связанные
GCC и libc — предварительная версия библиотеки librambutan
В этом документе приведены примечания по использованию arm-none-eabi-gcc
,
CodeSourcery версия компиляторов GNU GCC, используемых для плат Maple.это
не предназначен в качестве справочного руководства для GCC; такие руководства доступны
в другом месте.
Пользователи, которые хотят использовать arm-none-eabi-gcc
напрямую, вместе с
стандартный набор инструментов Unix на основе Make, следует прочитать
Краткое руководство Unix Toolchain, в котором описывается, как настроить такой
среда.
LeafLabs обслуживает зеркала для некоторых из
последние версии компилятора, включая версии для OS X, Win32,
и 32-битный Linux.
В этом разделе описаны флаги, переданные в arm-none-eabi-gcc
пользователем
Makefile по умолчанию, поставляемый с набором инструментов Unix.Информация в этом разделе может изменяться между выпусками libmaple.
Следующие флаги передаются компилятору C:
-Os -g -mcpu = cortex-m3 -mthumb -march = armv7-m -nostdlib -ffunction-section -fdata-section -Wl, - gc-разделы
В дополнение к тем флагам, которые только что указаны для компилятора C,
следующие флаги передаются компилятору C ++:
-fno-rtti -fno-exceptions -Стена
Следующие флаги переданы ассемблеру:
-mcpu = cortex-m3 -march = armv7-m -mthumb
По умолчанию arm-none-eabi-gcc
настроен на
ссылка на newlib, стандарт C
библиотека, предназначенная для использования со встроенными приложениями.Вы можете
включить любой из его заголовков.
Однако имейте в виду, что различные системные вызовы могут быть только частично
реализовано, если вообще. См. Файл libmaple syscalls.c и
документацию newlib для более подробной информации.
В этом разделе, который, как ожидается, со временем будет расти, описывается
методы для переноса кода, который использует функции AVR-GCC (AVR-GCC является
компилятор, используемый многими платами микроконтроллеров Atmel на базе AVR,
включая Arduino) для использования на Maple.
Замена
PROGMEM
: если вам нужно сохранить много постоянных данных,
вы можете хранить переменные во Flash (вместо RAM), используя
Макрос libmaple__FLASH__
.Вот пример:массив uint32 [] __FLASH__ = {0, 1, 2};
Это поможет вам сэкономить оперативную память, когда вам нужно хранить большие объемы
данные, такие как справочные таблицы.Вы можете хранить только значения, которые являются константами времени компиляции (например,
числа и строки, а также массивы чисел и строк) таким образом.
Кроме того, если вы попытаетесь изменить переменную, хранящуюся во Flash, ваша программа
рухнет.Если вам нужно перенести код AVR / Arduino, который использует pgmspace.h,
эти объявления могут вам помочь:typedef const unsigned char prog_uchar; #define pgm_read_byte_near (x) (* (prog_uchar *) x) #define pgm_read_byte (x) (* (prog_uchar *) x)
Предпочитайте gcc-ar ar в ваших системах сборки
Работая над нашим курсом «Создание кроссплатформенной системы сборки для встраиваемых проектов с использованием Meson», я попал в кроличью нору, когда писал урок по оптимизации времени компоновки (LTO).
Я включил поддержку LTO, используя встроенную опцию Meson:
$ meson buildresults -Db_lto = true
Все работало отлично с настройкой родной цепочки инструментов.
Затем я протестировал поддержку LTO с кросс-компиляцией:
$ meson buildresults -Db_lto = true --cross-file = build / cross / arm.txt --cross-file = build / cross / cortex-m4_hardfloat.txt
Наши правила кросс-компиляции используют набор инструментов gnu-arm-none-eabi
:
[двоичные файлы]
c = 'рука-нет-eabi-gcc'
cpp = 'рука-нет-eabi-c ++'
ар = 'рука-ни-еаби-ар'
полоса = 'рука-ни-еаби-полоса'
Когда я запустил сборку, я был удивлен, получив поток предупреждений от arm-none-eabi-ar
:
arm-none-eabi-ar: src / 25a6634 @@ c @ sta / stdlib_imaxabs.c.o: плагин, необходимый для обработки объекта lto
arm-none-eabi-ar: src / 25a6634 @@ c @ sta / stdlib_imaxdiv.c.o: плагин, необходимый для обработки объекта lto
arm-none-eabi-ar: src / 25a6634 @@ c @ sta / stdlib_labs.c.o: плагин, необходимый для обработки объекта lto
arm-none-eabi-ar: src / 25a6634 @@ c @ sta / stdlib_ldiv.c.o: плагин, необходимый для обработки объекта lto
Я исследовал проблему и нашел несколько рекомендаций по добавлению аргумента --plugin
к вызову arm-none-eabi-ar
для устранения проблемы:
--plugin = $ (arm-none-eabi-gcc --print-file-name = liblto_plugin.
так)
Я протестировал этот подход, вручную добавив аргумент к сгенерированной команде -ar
, и это действительно устранило проблему. Однако я просто не мог поверить, что это действительно решение. Это такой хакерский флаг, что никто не делает это, когда используют LTO.
Я провел немного больше исследований, и этот поток переполнения стека привел меня к решению: используйте arm-none-eabi-gcc-ar
вместо arm-none-eabi-ar
. Вариант * -gcc-ar
— это оболочка для * -ar
, которая предоставляет аргументы плагина, которые нам нужны.
gcc-ar ... => ar --plugin = / путь / к / liblto_plugin.so ...
Как только я переключил свою цепочку инструментов на использование * -gcc-ar
, предупреждения исчезли.
[двоичные файлы]
c = 'рука-нет-eabi-gcc'
cpp = 'рука-нет-eabi-c ++'
# * -gcc-ar используется вместо * -ar для поддержки флагов LTO.
# Без -gcc-ar LTO выдаст предупреждение компоновщика:
# arm-none-eabi-ar: file.o: плагин, необходимый для обработки объекта lto
ar = 'рука-нет-eabi-gcc-ar'
полоса = 'рука-ни-еаби-полоса'
Я пришел к выводу, что мы должны предпочесть gcc-ar
, а не ar
по умолчанию в наших системах сборки.Таким образом, мы можем поддерживать LTO в качестве опции для наших проектов.
Также стоит отметить, что nm
и ranlib
имеют эквиваленты gcc-nm
и gcc-ranlib
, которые обеспечивают правильные аргументы плагина LTO. Их следует использовать всякий раз, когда вы работаете с файлами LTO.
.