fk0, легенда (01.11.2013 15:47, просмотров: 295) ответил Илья на ОК, компиляторы "давно", а IDE "недавно": For debugging, the ELF/DWARF format is preferred, but this format is not supported by MPLAB IDE v8 or early versions of MPLAB X IDE. Before selecting the ELF file output, ensure your IDE version has
MPLAB не поддерживает ELF. Вопрос -- зачем тогда вообще ELF и что мне с ним делать??? В MPLAB-X загрузить готовый ELF тоже невозможно (покажите как...), чтоб он потом ещё и отлаживался. Собирать проект в MPLAB-X тоже невозможно или очень много времени нужно потратить (проект собирается в Makefile, правила для сборки очень нетривиальные, просто взять и перетащить файлы мышкой в project manager -- не вариант). Да и MPLAB-X в целом _не_ _работает_. Кто говорит иное -- лгут или делают проекты уровня hello world. MPLAB v8 плохо но работает. Я уже раз пять каждый раз новую версию пробовал и один результат. Последний раз для ELF или COFF, не важно, файл загружался через раз после открытия и закрытия самого mplab (на ходу вообще не перезагружался, если пересобрал), отладочной информации не было _вообще_, реалайс тоже работал через раз и нужно было выходить из mplab. Это сырое и глючное поделие, гораздо хуже классического MPLAB.
Сделать ELF, а из него nm и objdump? Это идея. Но как? В составе xc16 как будто специально исключили objcopy (да и не факт, что сработает).
Короче, пересобрал проект ворованным xc16.
Теперь xc16-nm -l file.elf выдаёт в stderr кучу "BFD: Dwarf Error: Could not find abbrev number 1." и в stdout выдаёт все символы с адресами, но информации о номерах строк и именах файлов вообще нет! Как будто nm без опции -l запускал. И в objdump тоже исходников вообще нет. Короче НЕ РАБОТАЕТ. Вообще ничего. xc16 ещё хуже, чем c30, потому, что c30 работает хотя бы "в половине случаев", как и MPLAB v8.
Правда в том, что влезли кривыми ручками в binutils, не разобрались, всё сломали, чем дальше тем хуже. Для MPLAB (без X) написали свой кривой самодельный парсер coff с похожими глюками.
[ZX]