мохоноги (01.10.2011 21:08 - 02.10.2011 04:24, просмотров: 1796)J-Link GDB Server и ошибка "Remote 'g' packet reply is too long" http://thread.gmane.org/gmane.comp.gdb.patches/58690/
Встретился с проблемой при компилировании программ для Cortex-M3 с использованием GCC для ARM EABI и последующей отладкой через GDB >= 7.3 и J-Link GDB Server (как минимум, в версиях вплоть до 4.34a -- последней, на данный момент, для Linux). Проблема специфическая; наверное, мало кто кроме меня с ней сталкивался. Но на всякий случай сохраню тут суть проблемы и решение. [Использую сахару, потому что у Segger (производителей J-Link) какой-то хитровыененный форум, где после регистрации надо ждать подтверждения админа для получения права постить.] К сути: GCC при компиляции/компоновке с флагом '-march=arm-v7m' и/или '-mcpu=cortex-m3' выставляет в результирующем ELF-файле атрибут "Tag_CPU_arch_profile: Microcontroller", что видно в выводе команды 'readelf -A out.elf'. GDB версии >= 7.3 видя этот атрибут, считает, что у целевого процессора ровно N регистров (конкретное число N неважно). Однако J-Link GDB Server при считывании регистров передаёт GDB пакет, в котором N+M регистров (значение M, опять же, неважно). GDB, видя, что пришедший пакет по длине больше ожидаемого, выдаёт ошибку: "Remote 'g' packet reply is too long". Как правило, это происходит на этапе загрузки кода в микропроцессор: тут отладка и завершается. Почему? Потому что GDB версии до 7.3 ожидал, что у всех процессоров ARM есть регистры сопроцессора VFP. И у Cortex-M3 (у которых этих регистров нет). В версии 7.3 это умолчание изменили, и GDB ожидает только значения регистров, реально присутствующие у процессора. Однако J-Link GDB Server своё поведение ещё не изменил и отвечает пакетом с "фальшивыми" значения регистров VFP. Решение: перед загрузкой кода указать GDB на файл описания устройства (процессора), который содержит, в том числе, и несуществующие регистры VFP. Делается это командой: 'set tdesc filename arm-with-m-and-fake-vfpv3.xml'. Архив с нужными файлами я приложил. (По ссылке -- тред в gdb-patches от 9 июня 2010 по теме этого изменения.)
Встретился с проблемой при компилировании программ для Cortex-M3 с использованием GCC для ARM EABI и последующей отладкой через GDB >= 7.3 и J-Link GDB Server (как минимум, в версиях вплоть до 4.34a -- последней, на данный момент, для Linux). Проблема специфическая; наверное, мало кто кроме меня с ней сталкивался. Но на всякий случай сохраню тут суть проблемы и решение. [Использую сахару, потому что у Segger (производителей J-Link) какой-то хитровыененный форум, где после регистрации надо ждать подтверждения админа для получения права постить.] К сути: GCC при компиляции/компоновке с флагом '-march=arm-v7m' и/или '-mcpu=cortex-m3' выставляет в результирующем ELF-файле атрибут "Tag_CPU_arch_profile: Microcontroller", что видно в выводе команды 'readelf -A out.elf'. GDB версии >= 7.3 видя этот атрибут, считает, что у целевого процессора ровно N регистров (конкретное число N неважно). Однако J-Link GDB Server при считывании регистров передаёт GDB пакет, в котором N+M регистров (значение M, опять же, неважно). GDB, видя, что пришедший пакет по длине больше ожидаемого, выдаёт ошибку: "Remote 'g' packet reply is too long". Как правило, это происходит на этапе загрузки кода в микропроцессор: тут отладка и завершается. Почему? Потому что GDB версии до 7.3 ожидал, что у всех процессоров ARM есть регистры сопроцессора VFP. И у Cortex-M3 (у которых этих регистров нет). В версии 7.3 это умолчание изменили, и GDB ожидает только значения регистров, реально присутствующие у процессора. Однако J-Link GDB Server своё поведение ещё не изменил и отвечает пакетом с "фальшивыми" значения регистров VFP. Решение: перед загрузкой кода указать GDB на файл описания устройства (процессора), который содержит, в том числе, и несуществующие регистры VFP. Делается это командой: 'set tdesc filename arm-with-m-and-fake-vfpv3.xml'. Архив с нужными файлами я приложил. (По ссылке -- тред в gdb-patches от 9 июня 2010 по теме этого изменения.)
-
- Спасибо за информацию. J-Link GDB Server не использую, но про ошибку слышал и объяснение записал на корочку для общего развития. - Cepгeй Бopщ(03.10.2011 10:47)