arm-none-eabi-gdb и openocd: неверный ответ на запрос смещения, qOffsets?

Я пытаюсь использовать GDB для отладки оценочной платы Stellaris LM3S8962 с использованием OpenOCD и набора инструментов GNU ARM (установленного с MacPorts), всякий раз, когда я устанавливаю удаленную цель в GDB, он всегда возвращает «Malfomred response to offset query, qOffsets». Есть идеи о том, что может пойти не так? Что-то мне не хватает?

[bcochran@narada arm]$ arm-none-eabi-gdb
GNU gdb (GDB) 7.3
Copyright (C) 2011 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.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=x86_64-apple-darwin10.7.0 --target=arm-none-eabi".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
(gdb) set remotebaud 115200
(gdb) set debug remote 1
(gdb) file ~/dev/eclipse_workspace/hello_world_arm/bin/main.axf
Reading symbols from /Users/bcochran/dev/eclipse_workspace/hello_world_arm/bin/main.axf...(no debugging symbols found)...done.
(gdb) target remote localhost:4444
Remote debugging using localhost:4444
Sending packet: $qSupported:qRelocInsn+#9a...putpkt: Junk: {{}~Open On
Nak
Sending packet: $qSupported:qRelocInsn+#9a...putpkt: Junk: Chip Debugger
> 
Ack
Packet received: qSupported:qRelocInsn+
Packet qSupported (supported-packets) is supported
...
Packet qAttached (query-attached) is supported
Sending packet: $qOffsets#4b...Ack
Packet received: qOffsets
Malformed response to offset query, qOffsets

Вот результат openocd ... как только появляется искаженный ответ, openocd разрывает соединение telnet ...

[bcochran@narada bin]$ openocd -f ../openocd/luminary.cfg -f ../openocd/stellaris.cfg
Open On-Chip Debugger 0.6.0-dev-00014-g827057f (2011-08-09-22:02)
Licensed under GNU GPL v2
For bug reports, read
    http://openocd.berlios.de/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
500 kHz
Info : clock speed 500 kHz
Info : JTAG tap: lm3s.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
Info : lm3s.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : accepting 'telnet' connection from 4444
Error: error during read: Connection reset by peer
Info : dropped 'telnet' connection

Вот выходные версии моей инструментальной цепочки arm-none-eabi- * ...

[bcochran@narada tcl]$ arm-none-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/arm-none-eabi/4.6.1/lto-wrapper
Target: arm-none-eabi
Configured with: ../gcc-4.6.1/configure --prefix=/opt/local --target=arm-none-eabi --enable-languages=c,objc,c++,obj-c++ --infodir=/opt/local/share/info --mandir=/opt/local/share/man --datarootdir=/opt/local/share/arm-none-eabi-gcc --with-system-zlib --disable-nls --with-gmp=/opt/local --with-mpfr=/opt/local --with-mpc=/opt/local --enable-stage1-checking --enable-multilib --with-newlib --enable-interwork
Thread model: single
gcc version 4.6.1 (GCC)

[bcochran@narada tcl]$ arm-none-eabi-gdb -v
GNU gdb (GDB) 7.3
Copyright (C) 2011 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.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=x86_64-apple-darwin10.7.0 --target=arm-none-eabi".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.

Я могу скомпилировать с помощью инструментальной цепочки и прошить полученный .bin файл с помощью OpenOCD. Мне не удалось найти решение проблемы «неправильного ответа», просто выполнив поиск в Интернете.

Заранее благодарим за любой совет или помощь!

ОБНОВЛЕНИЯ

Благодаря ответам @ turbo-j и @ guy-sirton я смог продвинуться немного дальше ... До сих пор наиболее полезным было то, что я действительно использовал неправильный порт (4444 вместо 3333), но теперь я получаю следующее, добавляю ли я -c "init" -c "halt" -c "reset halt" в свою командную строку openocd или нет:

(gdb) target remote localhost:3333
Remote debugging using localhost:3333
Remote 'g' packet reply is too long:     0080004000000000040000220f0000002833405451332abc009600a4d2b86092c0c118c03040d6f0284dbb93204b40c2000000000c010020ffffffff550400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000020000001

(это сразу после qOffsets req / resp, которое теперь проходит)

На стороне OpenOCD:

Info : accepting 'gdb' connection from 3333
Warn : acknowledgment received, but no packet pending
Info : dropped 'gdb' connection

Иногда с undefined debug reason 6 - target needs reset на консоли OpenOCD ... не знаю, что сейчас происходит, но кажется, что он ближе к работе

ОБНОВЛЕНИЯ 2

Кажется, что если я не загружаю файл main.axf или main.o, я не сталкиваюсь с Remote 'g' packet reply is too long, но не получаю никаких символов ... Я заметил, что другие веб-сайты имеют дело в основном с расширением .elf. В чем разница? Я использую пример «Hello World» из StellarisWare, который генерирует main.axf, main.bin (flash пишет и работает нормально), main.d, main.o из команды make. Что-то странное в моем Makefile?


person azurewraith    schedule 13.08.2011    source источник
comment
Хороший вопрос. Как выглядит Makefile?   -  person Turbo J    schedule 16.08.2011
comment
Суть Makefile и makedefs   -  person azurewraith    schedule 17.08.2011
comment
Я собираюсь отметить этот вопрос как решенный, дать отладку еще раз и сформулировать более четкий вопрос относительно текущей проблемы, если она все еще существует. Спасибо всем, что помогло!   -  person azurewraith    schedule 18.08.2011


Ответы (5)


Вот патч вроде того, что упомянул @athquad. См. Его ответ для получения дополнительной информации. Спасибо ему за то, что он точно указал мне нужное место, и действительно большой позор за то, что предложил патч, не предоставив его. :-П

http://pastebin.com/rdFF2eZd

Патч сделан против openocd commit 631b80fd0835055bb385314f569f589b99d7441d

Для использования: (параметры ./configure зависят от оборудования jtag)

git clone git://git.code.sf.net/p/openocd/code openocd
cd openocd
patch -p1 < /path/to/patch/file
./bootstrap
./configure --enable-maintainer-mode --enable-ft2232_libftdi
nice make && sudo make install
person tacos    schedule 28.03.2012
comment
Вот это да. На самом деле сработало! Для меня это черная магия, но кончик шляпы. Ваше здоровье! - person aaaidan; 15.07.2012

Вы использовали неправильный порт. Используйте target remote localhost 3333 для соединения GDB-to-OpenOCD. Порт 4444 предназначен для взаимодействия человека через терминал и может использоваться в дополнение к GDB-соединению.

person Turbo J    schedule 15.08.2011
comment
Спасибо @ turbo-j, это помогло мне преодолеть одно препятствие, но, похоже, у меня все еще есть осложнение (добавлено к исходному вопросу) ... есть мысли? - person azurewraith; 16.08.2011
comment
Только файл .bin идет на прошивку AFAIK. - person Turbo J; 16.08.2011
comment
Решил мою проблему с openocd rlink и STM32F4 - person Verax; 28.10.2013

Если вы не хотите компилировать OpenOCD, как ответ tacos и atquad, вы можете использовать более старую версию цепочки инструментов GNU ARM (например, 7.2.5 подойдет). (Предварительно скомпилированные окна 0.4.0 и 0.5.0 вызывают эту проблему).

person Claude    schedule 17.08.2012

Я только что столкнулся с той же ошибкой «ответ пакета 'g' слишком длинный» и проследил ее до ее причины.

Похоже, что в течение очень долгого времени инструменты GNU ARM использовали модель ARM с 9 устаревшими регистрами с плавающей запятой. OpenOCD поступает мудро и в ответ на запрос регистра GDB предоставляет фиктивные значения. Однако последние инструменты eabi, включая GDB, обновлены, и поэтому ваш GDB больше не ожидает этих регистров - отсюда и сообщение.

В исходном коде OpenOCD я пропатчил armv7m_get_gdb_reg_list () в armv7m.c, чтобы это работало, но мой патч недостаточно умен, чтобы знать, какая версия GDB используется - он просто использует переключатель #ifdef - поэтому потребуется немного больше работы по интеграции с исходным кодом OpenOCD.

Патч может быть доступен всем желающим.

person athquad    schedule 05.10.2011
comment
Мне интересно :) Никогда не мог понять этого. - person azurewraith; 24.12.2011

Я много выполняю удаленную отладку на ARM, но с другим процессором, ОС и набором инструментов :-) Тем не менее, вот некоторые мысли.

Это предложение:

openocd -f openocd.cfg -c "init" -c "halt" -c "reset halt"

Отсюда: http://michaldemin.wordpress.com/2010/02/22/part-2-debugging-with-gdb-and-openocd/

Иначе:

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

  • Проблема со связью. Попробуйте снизить скорость передачи данных? Убедитесь, что параметры последовательного порта верны.

person Guy Sirton    schedule 14.08.2011
comment
Спасибо @ guy-sirton, я буду иметь в виду -c "reset halt", в этой статье говорится, что Cortex M3 нужен, и это то, что у меня есть ... - person azurewraith; 16.08.2011