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

Question

Я пытаюсь использовать GDB для отладки оценочной платы Stellaris LM3S8962 с использованием OpenOCD и инструментальной цепи GNU ARM (устанавливается с MacPorts), всякий раз, когда я устанавливаю удаленную цель в GDB, она всегда возвращает «Неправильный ответ на запрос смещения 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 (флэш пишет и работает нормально), main.d, main.o из команды make.Что-то странное в моем Makefile?

Answer 1

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

http://pastebin.com/rdFF2eZd

Произведено исправление для коммита openocd 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

Answer 2

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

Answer 3

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

Answer 4

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

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

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

Патчможет быть доступен любому, кто захочет.

Answer 5

Я делаю много удаленной отладки на 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 и найти то, что работает для других.

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