Начальная страница

Отладка с помощью GDB - 14. Информация о конфигурации

[Содержание]   [Назад]   [Пред]   [Вверх]   [След]   [Вперед]  

14. Информация о конфигурации

В то время как почти все команды GDB доступны для всех чистых и кросс-версий отладчика, существуют некоторые исключения. Эта глава описывает вещи, доступные только в определенных конфигурациях.

Существует три основные категории конфигураций: чистые конфигурации, где рабочая и целевая машины совпадают, конфигурации для встроенных операционных систем, которые обычно совпадают для нескольких различных архитектур процессоров, и отдельные встроенные процессоры, которые сильно отличаются друг от друга.

14.1 Чистая конфигурация

Этот раздел описывает детали, специфичные для определенных чистых конфигураций.

14.1.1 HP-UX

В системах HP-UX, если вы ссылаетесь на функцию или переменную, имя которой начинается со знака доллара, GDB сперва ищет имя пользователя или системы, до поиска вспомогательной переменной.

14.1.2 Информация о процессах SVR4

Многие версии SVR4 предоставляют возможность, называемую `/proc', которая может быть использована для исследования образа выполняемого процесса, используя подпрограммы файловой системы. Если GDB сконфигурирован для операционной системы, поддерживающей эту возможность, команда info proc доступна для получения отчета по некоторым видам информации о процессе, выполняющем вашу программу. info proc работает только на системах SVR4, которые включают код procfs. Среди этих систем: OSF/1 (Digital Unix), Solaris, Irix и Unixware, но не HP-UX или Linux, к примеру.

info proc
Выдает доступную суммарную информацию о процессе.
info proc mappings
Сообщает диапазоны адресов, доступных в программе, с информацией, может ли ваша программа читать, записывать, или исполнять каждый из диапазонов.
info proc times
Время запуска, время пользовательского и системного ЦП для вашей программы и ее потомков.
info proc id
Сообщает информацию об идентификаторах процессов, относящихся к вашей программе: ее собственный идентификатор, идентификатор ее родителя, группы процесса и сеанса.
info proc status
Общая информация о состоянии процесса. Если процесс остановлен, то этот отчет включает причину останова и любые полученные сигналы.
info proc all
Показывает всю вышеперечисленную информацию о процессе.

14.2 Встроенные операционные системы

Этот раздел описывает конфигурации, задействующие отладку встроенных операционных систем, которые доступны для нескольких различных архитектур.

GDB включает возможность отлаживать программы, выполняющиеся в различных операционных системах реального времени.

14.2.1 Использование GDB с VxWorks

target vxworks имя-машины
Система VxWorks, присоединенная посредством TCP/IP. Аргумент имя-машины есть имя или IP-адрес машины целевой системы.

На VxWorks, load компонует имя-файла динамически на текущей целевой системе, и добавляет ее символьную информацию в GDB.

GDB позволяет разработчикам запускать и отлаживать с Unix-машин задачи, выполняющиеся на сетевых целях VxWorks. Уже выполняющиеся задачи, запущенные из оболочки VxWorks, также могут быть отлажены. GDB использует код, который может выполняться как на машине Unix, так и на целевой машине VxWorks. Программа gdb устанавливается и выполняется на Unix-машине. (Она может быть установлена под именем vxgdb, чтобы отличать ее от GDB для отладки программ на рабочей машине.)

VxWorks-timeout арг
Сейчас все цели, базирующиеся на VxWorks, поддерживают параметр vxworks-timeout. Этот параметр устанавливается пользователем, и арг представляют число секунд, в течение которых GDB ожидает ответы на вызовы удаленных процедур. Вы можете использовать это, если ваша целевая машина VxWorks является медленным программным эмулятором, или находится далеко на другом конце медленного сетевого соединения.

Следующая информация о соединении к VxWorks была свежей, когда это руководство было написано; более новые выпуски VxWorks могут использовать обновленные процедуры.

Для использования GDB с VxWorks, вы должны пересобрать ваше ядро VxWorks, чтобы включить подпрограммы интерфейса удаленной отладки в библиотеку VxWorks `rdb.a'. Чтобы это сделать, определите INCLUDE_RDB в конфигурационном файле VxWorks `configAll.h' и пересоберите ядро VxWorks. Получившееся ядро содержит `rdb.a', и порождает задачу отладки исходного кода tRdbTask, когда VxWorks загружается. Для большей информации по конфигурированию и сборке VxWorks, смотрите руководство изготовителя.

Когда вы включили `rdb.a' в образ вашей системы VxWorks и так установили ваши пути поиска выполняемых файлов, чтобы можно было найти GDB, вы готовы к вызову отладчика. Из вашей рабочей Unix-машины, выполните gdb (или vxgdb, в зависимости от вашей установки).

GDB появляется и показывает приглашение: 

(vxgdb)

14.2.1.1 Соединение к VxWorks

Команда GDB target позволяет вам соединяться с целевой машиной VxWorks в сети. Для соединения с целью, имя которой есть "tt", введите: 

(vxgdb) target vxworks tt

GDB покажет сообщения, аналогичные этим: 

Attaching remote machine across net... 
Connected to tt.

Затем GDB пытается считать таблицы символов всех объектных модулей, загруженных на целевой машине VxWorks с того момента, как она была включена. GDB находит эти файлы путем поиска в каталогах, перечисленных в путях поиска команд (см. раздел 4.4 Рабочая среда вашей программы); если ему не удается найти объектный файл, он выводит подобное сообщение: 

prog.o: No such file or directory.

Когда это происходит, добавьте соответствующий каталог к путям поиска с помощью команды GDB path, и выполните команду target снова.

14.2.1.2 Загрузка на VxWorks

Если вы соединились с целевой машиной VxWorks и хотите отладить объект, который еще не был загружен, вы можете использовать команду GDB load, чтобы загрузить файл из Unix в VxWorks. Объектный файл, заданный в качестве аргумента к load, в действительности открывается дважды: сначала целевой машиной VxWorks, чтобы загрузить код, а затем GDB, чтобы считать таблицу символов. Это может привести к проблемам, если текущие рабочие каталоги в этих системах различаются. Если обе системы монтируют по NFS одинаковые файловые системы, вы можете избежать этих проблем, используя абсолютные пути. В противном случае, проще всего установить рабочий каталог на обеих системах в тот, в котором расположен объектный файл, и затем ссылаться на него по имени, без пути. Например, программа `prog.o' может находиться в `vxpath/vw/demo/rdb' на VxWorks и в `hostpath/vw/demo/rdb' на рабочей машине. Для загрузки этой программы, введите в VxWorks следующее: 

-> cd "vxpath/vw/demo/rdb"

Затем, в GDB, введите: 

(vxgdb) cd hostpath/vw/demo/rdb
(vxgdb) load prog.o

GDB отобразит ответ, аналогичный этому: 

Reading symbol data from wherever/vw/demo/rdb/prog.o... done.

Вы также можете использовать команду load, чтобы заново загрузить объектный модуль, после редактирования и повторной компиляции соответствующего исходного файла. Заметьте, что при этом GDB удаляет все определенные точки останова, автоматические отображения, вспомогательные переменные, и очищает историю значений. (Это необходимо для того, чтобы сохранить целостность структур данных отладчика, которые ссылаются на таблицу символов целевой системы.)

14.2.1.3 Запуск задач

Вы также можете присоединиться к существующей задаче, используя команду attach следующим образом: 

(vxgdb) attach задача

где задача является шестнадцатеричным идентификатором задачи VxWorks. Когда вы присоединяетесь к задаче, она может выполняться либо быть приостановленной. Выполняющаяся задача приостанавливается в момент присоединения.

14.3 Встроенные процессоры

Этот раздел описывает детали, специфичные для определенных встроенных конфигураций.

14.3.1 Встроенный AMD A29K

target adapt устр
Монитор Adapt для A29K.
target amd-eb устр скорость прог
Удаленная PC-резидентная плата AMD EB29K, присоединенная по последовательным линиям. Устр является последовательным устройством, также как для target remote; скорость позволяет вам указать скорость линии; а прог является именем программы, которая будет отлаживаться, так, как оно появляется в ДОС на ПК. См. раздел 14.3.1.2 Протокол EBMON для AMD29K.

14.3.1.1 A29K UDI

Для отладки процессоров семейства a29k, GDB поддерживает протокол AMD UDI ("Universal Debugger Interface"(16)). Для использования этой конфигурации с целями AMD, на которых выполняется монитор MiniMON, вам нужна программа MONTIP, доступная бесплатно у AMD. Вы можете также использовать GDB с программой ISSTIP, UDI-совместимым эмулятором a29k, также доступным у AMD.

target udi кл-слово
Выбрать интерфейс UDI к удаленной плате a29k или эмулятору. Здесь кл-слово является элементом в конфигурационном файле AMD `udi_soc'. Этот файл содержит в качестве элементов ключевые слова, которые определяют параметры, используемые при соединении к целям a29k. Если файл `udi_soc' не находится в вашем рабочем каталоге, вы должны установить путь к нему в переменной среды `UDICONF'.

14.3.1.2 Протокол EBMON для AMD29K

AMD распространяет плату разработки 29K, предназначенную для помещения в ПК, вместе с программой монитора EBMON, работающей в ДОС. Коротко эта система разработки называется "EB29K". Чтобы использовать GDB из Unix-системы для выполнения программ на плате EB29K, вы должны сперва соединить последовательным кабелем ПК (в котором установлена плата EB29K) и последовательный порт на Unix-системе. Далее мы предполагаем, что вы соединили кабелем порт ПК `COM1' и `/dev/ttya' на Unix-системе.

14.3.1.3 Установка связи

Следующим шагом нужно установить параметры порта ПК, сделав в ДОС что-то вроде этого: 

C:\> MODE com1:9600,n,8,1,none

Этот пример, выполненный в системе MS DOS 4.0, устанавливает порт ПК в 9600бит/сек, без проверки четности, восьмибитные данные, один стоп-бит и отсутствие действия для "повтора"; вы должны использовать те же параметры связи при установке соединения со стороны Unix.

Чтобы передать управление с ПК стороне Unix, введите следующее в консоли ДОС: 

C:\> CTTY com1

(Позже, если вы хотите вернуть управление консоли ДОС, вы можете использовать команду CTTY con---но вы должны послать ее через устройство, имевшее управление, в нашем примере через последовательную линию `COM1'.)

На Unix-машине, для связи с ПК используйте коммуникационную программу, такую как tip или cu. Например 

cu -s 9600 -l /dev/ttya

Показанные ключи для cu определяют, соответственно, скорость линии и последовательный порт. Если вместо этого вы используете tip, ваша командная строка может выглядеть следующим образом: 

tip -9600 /dev/ttya

Ваша система может требовать другого имени в том месте, где мы показываем `/dev/ttya' в качестве аргумента к tip. Параметры связи, включая используемый порт, ассоциированы с аргументом к tip в файле описаний "remote"---обычно это `/etc/remote'.

Используя соединение tip или cu, измените рабочий каталог ДОС в тот, который содержит копию вашей программы 29K, затем запустите на ПК программу EBMON (управляющая программа EB29K, поставляемая AMD с вашей платой). Вы должны увидеть начальный вывод EBMON, аналогичный следующему, заканчивающийся приглашением EBMON `#': 

C:\> G:

G:\> CD \usr\joe\work29k

G:\USR\JOE\WORK29K> EBMON
Am29000 PC Coprocessor Board Monitor, version 3.0-18
Copyright 1990 Advanced Micro Devices, Inc.
Written by Gibbons and Associates, Inc.

Enter '?' or 'H' for help

PC Coprocessor Type   = EB29K
I/O Base              = 0x208
Memory Base           = 0xd0000

Data Memory Size      = 2048KB
Available I-RAM Range = 0x8000 to 0x1fffff
Available D-RAM Range = 0x80002000 to 0x801fffff

PageSize              = 0x400
Register Stack Size   = 0x800
Memory Stack Size     = 0x1800

CPU PRL               = 0x3
Am29027 Available     = No
Byte Write Available  = Yes

# ~.

Затем выйдите из программы cu или tip (в этом примере это сделано при помощи ввода ~. в приглашении EBMON). EBMON продолжает работать, готовый к тому, что GDB перехватит управление.

Для этого примера, мы предположили, что существует соединение PC/NFS, которое устанавливает файловую систему Unix-машины как "диск `G:'" на ПК. Это является, вероятно, самым удобным способом удостовериться, что одна и та же программа 29K находится и на ПК, и в Unix-системе. Если у вас нет PC/NFS или чего-нибудь аналогичного, соединяющего две системы, вы должны прибегнуть к другому способу передачи программы 29K из Unix на ПК--возможно переписать ее на дискету. GDB не загружает программы по последовательной линии.

14.3.1.4 Кросс-отладка EB29K

Наконец, перейдите в каталог, содержащий образ вашей программы 29K в Unix-системе, и запустите GDB, указав имя программы в качестве аргумента: 

cd /usr/joe/work29k
gdb myfoo

Теперь вы можете использовать команду target: 

target amd-eb /dev/ttya 9600 MYFOO

В этом примере мы предполагали, что ваша программа находится в файле `myfoo'. Заметьте, что имя файла, заданное в качестве последнего аргумента к target amd-eb, должно быть таким, каким его видит ДОС. В нашем примере, это просто MYFOO, но вообще оно может включать путь ДОС, и, в зависимости от механизма передачи, может быть не похоже на имя на Unix-машине.

В этом месте вы можете установить желаемые точки останова; когда вы будете готовы увидеть вашу программы выполняющейся на плате 29K, используйте команду GDB run.

Чтобы остановить отладку удаленной программы, используйте команду GDB detach.

Чтобы возвратить управление консоли ПК, используйте tip или cu снова, после завершения вашего сеанса GDB, чтобы присоединиться к EBMON. Затем вы можете ввести команду q, чтобы завершить работу EBMON, возвращая управление командному интерпретатору ДОС. Введите CTTY con, чтобы возвратить командный ввод основной консоли ДОС, и введите ~., чтобы покинуть tip или cu.

14.3.1.5 Удаленный журнал

Команда target amd-eb создает в текущем рабочем каталоге файл `eb.log', чтобы помочь отладить проблемы с соединением. `eb.log' записывает весь вывод `EBMON', включая эхо посланных ему команд. Выполнение `tail -f' для этого файла в другом окне часто помогает понять проблемы с EBMON, или неожиданные события на стороне ПК.

14.3.2 ARM

target rdi устр
Монитор ARM Angel, через интерфейс библиотеки RDI к протоколу ADP. Вы можете использовать эту цель для взаимодействия как с платами, на которых выполняется монитор Angel, так и с устройством отладки EmbeddedICE JTAG.
target rdp устр
Монитор ARM Demon.

14.3.3 Hitachi H8/300

target hms устр
Плата Hitachi SH, H8/300 или H8/500, присоединенная через последовательную линию к вашей машине. Используйте специальные команды device и speed для управления последовательной линией и используемой скоростью связи.
target e7000 устр
Эмулятор E7000 для Hitachi H8 и SH.
target sh3 устр
target sh3e устр
Целевые системы Hitachi SH-3 и SH-3E.

Когда вы выбираете удаленную отладку для платы Hitachi SH, H8/300 или H8/500, команда load загружает вашу программу на плату Hitachi, и также открывает ее как текущую выполняемую цель для GDB на вашей машине (как команда file).

Для общения с вашим Hitachi SH, H8/300 или H8/500, GDB необходимо знать следующие вещи:

  1. что вы хотите использовать: `target hms', удаленный отладочный интерфейс для микропроцессоров Hitachi, или `target e7000', встроенный эмулятор для Hitachi SH и Hitachi 300H. (`target hms' используется по умолчанию, если GDB сконфигурирован специально для Hitachi SH, H8/300 или H8/500.)
  2. какое последовательное устройство соединяет вашу машину с платой Hitachi (по умолчанию используется первое последовательное устройство, доступное на вашей машине).
  3. какую скорость использовать для этого последовательного устройства.

14.3.3.1 Соединение с платами Hitachi

Используйте специальную команду GDB `device порт', если вам нужно явно установить последовательное устройство. По умолчанию используется первый порт, доступный на вашей машине. Это необходимо только на Unix-машинах, где это обычно что-то типа `/dev/ttya'.

GDB имеет другую специальную команду для установки скорости связи: `speed bps'. Эта команда также используется только на Unix-машинах; в ДОС, устанавливайте скорость линии как обычно извне GDB командой mode (например, mode com2:9600,n,8,1,p для соединения 9600бит/сек.

Команды `device' и `speed' доступны для отладки программ микропроцессора Hitachi, только если вы используете рабочую среду Unix. Если вы используете ДОС, для взаимодействия с платой разработки через последовательный порт ПК GDB полагается на вспомогательную резидентную программу asynctsr. Вы также должны использовать команду ДОС mode, чтобы подготовить порт со стороны ДОС.

Следующий пример сеанса иллюстрирует шаги, необходимые для запуска программы на H8/300 под управлением GDB. В нем используется программа H8/300 под названием `t.x'. Для Hitachi SH и H8/500 процедура та же самая.

Сперва подсоедините вашу плату разработки. В этом примере, мы используем плату, присоединенную к порту COM2. Если вы используете другой последовательный порт, подставьте его имя в агрументе команды mode. Когда вы вызываете asynctsr, вспомогательную программу связи, используемую отладчиком, вы передаете ей только числовую часть имени последовательного порта; например, ниже `asynctsr 2' запускает asynctsr для COM2. 

C:\H8300\TEST> asynctsr 2
C:\H8300\TEST> mode com2:9600,n,8,1,p

Resident portion of MODE loaded

COM2: 9600, n, 8, 1, p

Предупреждение: Мы обнаружили ошибку в PC-NFS, которая конфликтует с asynctsr. Если вы также используете PC-NFS на вашей ДОС-машине, вам может потребоваться отключить его, или даже загрузить машину без него, чтобы использовать asynctsr для управления отладочной платой.

Теперь, когда связь установлена и плата разработки присоединена, вы можете запустить GDB. Вызовите gdb с именем вашей программы в качестве аргумента. GDB выводит обычное приглашение: `(gdb)'. Используйте две специальные команды для начала сеанса отладки: `target hms' для задания кросс-отладки для платы Hitachi, и команду load для загрузки вашей программы на нее. load выводит имена разделов программы, и `*' для каждых двух килобайт загруженных данных. (Если вы хотите обновить данные GDB для символов или для выполняемого файла без загрузки, используйте команды GDB file или symbol-file. Для описания этих команд, равно как и самой команды load, см. раздел 12.1 Команды для задания файлов.) 

(eg-C:\H8300\TEST) gdb t.x
GDB is free software and you are welcome to distribute copies
 of it under certain conditions; type "show copying" to see
 the conditions.
There is absolutely no warranty for GDB; type "show warranty"
for details.
GDB 5.0, Copyright 1992 Free Software Foundation, Inc...
(gdb) target hms
Connected to remote H8/300 HMS system.
(gdb) load t.x
.text   : 0x8000 .. 0xabde ***********
.data   : 0xabde .. 0xad30 *
.stack  : 0xf000 .. 0xf014 *

Теперь вы готовы выполнять или отлаживать вашу программу. С этого момента, вы можете использовать все обычные команды GDB. Команда break устанавливает точки останова; run запускает вашу программу; print или x отображает данные; команда continue возобновляет выполнение после остановки в точке останова. Вы можете использовать команду help в любой момент, чтобы узнать больше о командах GDB.

Помните, однако, что возможности операционной системы не доступны на вашей плате разработки; например, если ваша программа зависает, вы не можете послать сигнал прерывания--но можете нажать кнопку RESET!

Используйте кнопку RESET на вашей плате разработки

  • чтобы прервать вашу программу (не используйте ctl-C на машине с ДОС--у нее нет способа передать сигнал прерывания на плату разработки); и
  • для возврата к приглашению GDB после того, как ваша программа нормально завершается. Протокол связи не предусматривает другого способа для GDB определить, что ваша программа завершилась.

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

14.3.3.2 Использование встроенного эмулятора E7000

Вы можете использовать встроенный эмулятор E7000 для разработки кода либо для Hitachi SH, либо для H8/300H. Используйте одну из этих форм команды `target e7000' для соединения GDB с вашей E7000:

target e7000 порт скорость
Используйте эту форму, если ваша E7000 присоединена к последовательному порту. Аргумент порт идентифицирует, какой последовательный порт использовать (например, `com2'). Третий аргумент является скоростью линии в битах в секунду (например, `9600').
target e7000 имя-узла
Если ваша E7000 установлена как узел сети TCP/IP, вы можете просто указать его имя; GDB использует для соединения telnet.

14.3.3.3 Специальные команды GDB для Hitachi

Некоторые команды GDB доступны только для H8/300:

set machine h8300
set machine h8300h
Настраивайте GDB на один из двух вариантов архитектур H8/300 с помощью `set machine'. Вы можете использовать `show machine', чтобы проверить, какой из вариантов действует в данный момент.

14.3.4 H8/500

set memory мод
show memory
Укажите, какую модель памяти H8/500 (мод) вы используете с помощью `set memory'; проверяйте, какая модель используется при помощи `show memory'. Допустимыми значениями для мод являются small, big, medium и compact.

14.3.5 Intel i960

target mon960 устр
Монитор MON960 для Intel i960.
target nindy имя-устр
Плата Intel 960, управляемая Nindy Monitor. Имя-устр является именем последовательного устройства, которое должно использоваться для соединения, например `/dev/ttya'.

Nindy---это программа ROM Monitor для целевых систем Intel 960. Когда GDB сконфигурирован для управления удаленным Intel 960 с использованием Nindy, вы можете указать ему, как присоединиться к 960 несколькими способами:

  • Указав последовательный порт, версию протокола Nindy и скорость связи через ключи командной строки;
  • Ответив на запрос при старте;
  • Используя команду target в любом месте вашего сеанса GDB. См. раздел 13.2 Команды для управления целями.

С интерфейсом Nindy к плате Intel 960, команда load загружает имя-файла на 960, а также добавляет его символьные данные в GDB.

14.3.5.1 Вызов Nindy

Если вы просто запустите gdb без использования ключей командной строки, у вас запросят, какой последовательный порт использовать, до того, как вы получите обычное приглашение GDB: 

Attach /dev/ttyNN -- specify NN, or "quit" to quit:

Ответьте на запрос с любым суффиксом (после `/dev/tty'), определяющим последовательный порт, который вы хотите использовать. Вы можете, по своему выбору, просто начать работу без соединения с Nindy, ответив на приглашение пустой строкой. Если вы сделаете это и позже захотите присоединиться к Nindy, используйте target (см. раздел 13.2 Команды для управления целями).

14.3.5.2 Параметры для Nindy

Вот параметры вызова для начала вашего сеанса GDB с подключенной платой Nindy-960:

-r порт
Задайте имя порта последовательного интерфейса, который должен использоваться для соединения с целевой системой. Этот ключ доступен только когда GDB сконфигурирован для целевой архитектуры Intel 960. Вы можете определить порт любым из следующих способов: полный путь (например, `-r /dev/ttya'), имя устройства в `/dev' (например, `-r ttya') или просто уникальный суффикс для определенного tty (например, `-r a').
-O
(Заглавная буква "O", не ноль.) Определяет, что GDB должен использовать "старый" протокол монитора Nindy для соединения с целевой системой. Этот ключ доступен только когда GDB сконфигурирован для целевой архитектуры Intel 960.

Предупреждение: если вы определите `-O', но в действительности попытаетесь связаться с системой, которая ожидает более нового протокола, соединение не будет установлено, как будто не соответствуют скорости. GDB неоднократно пытается соединиться снова на нескольких различных скоростях линии. Вы можете остановить этот процесс посредством прерывания.

-brk
Определяет, что GDB должен сперва послать целевой системе сигнал BREAK, пытаясь сбросить ее, перед соединением с целью Nindy.

Предупреждение: Многие целевые системы не имеют требуемых для этого аппаратных средств; это работает только на немногих платах.

Стандартный ключ `-b' управляет скоростью линии, используемой на последовательном порту.

14.3.5.3 Команда сброса Nindy

reset
Для целей Nindy, эта команда посылает "break" удаленной целевой системе; она полезна, только если целевая система была оборудована схемой для выполнения аппаратного сброса (или других действий, представляющих интерес) при обнаружении прерывания.

14.3.6 Mitsubishi M32R/D

target m32r устр
Монитор ROM Mitsubishi M32R/D.

14.3.7 M68k

Конфигурация Motorola m68k включает поддержку ColdFire, и команду target для следующих мониторов ROM.

target abug устр
Монитор ABug ROM для M68K.
target cpu32bug устр
Монитор CPU32BUG, выполняющийся на плате CPU32 (M68K).
target dbug устр
Монитор dBUG ROM для Motorola ColdFire.
target est устр
Монитор EST-300 ICE, выполняющийся на плате CPU32 (M68K).
target rom68k устр
Монитор ROM 68K, выполняющийся на плате M68K IDP.

Если GDB сконфигурирован с m68*-ericsson-*, то вместо этого у него будет только одна специальная команда target:

target es1800 устр
Эмулятор ES-1800 для M68K.
target rombug устр
Монитор ROMBUG ROM для OS/9000.

14.3.8 M88K

target bug устр
Монитор BUG, выполняющийся на плате MVME187 (m88k).

14.3.9 Встроенный MIPS

GDB может использовать удаленный отладочный протокол MIPS для взаимодействия с платой MIPS, присоединенной к последовательной линии. Эта возможность доступна, если вы сконфигурировали GDB с `--target=mips-idt-ecoff'.

Используйте эти команды GDB для определения соединения с вашей целевой платой:

target mips порт
Для выполнения программы на плате, выполните gdb, задав имя программы в качестве аргумента. Для соединения с платой, используйте команду `target mips порт', где порт---имя последовательного порта, присоединенного к плате. Если программа еще не была загружена на плату, вы можете использовать команду load, чтобы это сделать. Затем вы можете использовать все обычные команды GDB. Например, эта последовательность команд устанавливает соединение к целевой плате через последовательный порт, загружает и начинает выполнение из отладчика программы с именем prog: 
host$ gdb prog
GDB is free software and ...
(gdb) target mips /dev/ttyb
(gdb) load prog
(gdb) run
target mips имя-машины:номер-порта
В некоторых рабочих конфигурациях GDB, вы можете задать TCP-соединение (например, к последовательной линии, управляемой терминальным концентратором) вместо последовательного порта, используя синтаксис `имя-машины:номер-порта'.
target pmon порт
Монитор ROM PMON.
target ddb порт
NEC DDB-разновидность PMON для Vr4300.
target lsi порт
LSI-разновидность PMON.
target r3900 устр
Densan DVE-R3900 монитор ROM для Toshiba R3900 Mips.
target array устр
Плата контроллера RAID Array Tech LSI33K.

GDB также поддерживает следующие специальные команды для целей MIPS:

set processor арг
show processor
Используйте команду set processor для установки типа процессора MIPS, когда вы хотите обратиться к регистрам, уникальным для данного типа процессора. Например, set processor r3041 велит GDB использовать регистры CPO, соответствующие микросхеме 3041. Используйте команду show processor, чтобы узнать, какой процессор MIPS используется GDB. Используйте команду info reg чтобы узнать, какие регистры использует GDB.
set mipsfpu double
set mipsfpu single
set mipsfpu none
show mipsfpu
Если ваша целевая плата не поддерживает сопроцессор MIPS для вычислений с плавающей точкой, вы должны использовать команду `set mipsfpu none' (если вам это нужно, вы можете поместить эту команду в ваш файл инициализации GDB). Это говорит GDB, как найти значения функций, которые возвращают величины с плавающей точкой. Это также позволяет GDB избежать сохранения регистров с плавающей точкой при вызове функций на плате. Если вы используете сопроцессор поддержки вычислений с плавающей точкой с поддержкой только одинарной точности, как на процессоре R4650, используйте команду `set mipsfpu single'. По умолчанию используется сопроцессор поддержки вычислений с плавающей точкой двойной точности; этот режим может быть выбран с помощью `set mipsfpu double'. В предыдущих версиях, единственным выбором была двойная точность или отсутствие поддержки вычислений с плавающей точкой, так что `set mipsfpu on' выберет режим двойной точности, а `set mipsfpu off' отключит эту поддержку. Как обычно, вы можете запросить значение переменной mipsfpu при помощи `show mipsfpu'.
set remotedebug n
show remotedebug
Вы можете увидеть некоторую отладочную информацию о связи с платой, установив переменную remotedebug. Если вы установите ее в 1 при помощи `set remotedebug 1', будет отображаться каждый пакет. Если вы установите ее в 2, то будет отображаться каждый символ. В любой момент вы можете проверить текущее значение переменной командой `show remotedebug'.
set timeout секунды
set retransmit-timeout секунды
show timeout
show retransmit-timeout
Вы можете управлять временем ожидания пакета, используемом в удаленном протоколе MIPS, при помощи команды set timeout секунды. Значение по умолчанию--5 секунд. Аналогично, вы можете управлять временем ожидания, используемом при ожидании подтверждения пакета с помощью команды set retransmit-timeout секунды. По умолчанию 3 секунды. Вы можете узнать обе эти величины с помощью show timeout и show retransmit-timeout. (Эти команды доступны только если GDB сконфигурирован для цели `--target=mips-idt-ecoff'.) Время ожидания, установленное при помощи set timeout, не имеет значения, когда GDB ожидает остановки вашей программы. В этом случае, GDB ждет бесконечно, потому что у него нет способа узнать, сколько программа будет выполняться, пока не остановится.

14.3.10 PowerPC

target dink32 устр
Монитор ROM DINK32.
target ppcbug устр
target ppcbug1 устр
Монитор ROM PPCBUG для PowerPC.
target sds устр
Монитор SDS, выполняющийся на плате PowerPC (такой как Motorola ADS).

14.3.11 Встроенный HP PA

target op50n устр
Монитор OP50N, выполняющийся на плате OKI HPPA.
target w89k устр
Монитор W89K, выполняющийся на плате Winbond HPPA.

14.3.12 Hitachi SH

target hms устр
Плата Hitachi SH, присоединенная через последовательную линию к вашей рабочей машине. Используйте специальные команды device и speed для управления последовательной линией и используемой скоростью связи.
target e7000 устр
Эмулятор E7000 для Hitachi SH.
target sh3 устр
target sh3e устр
Целевые системы Hitachi SH-3 и SH-3E.

14.3.13 Tsqware Sparclet

GDB позволяет разработчикам отлаживать с Unix-машины задачи, выполняющиеся на целевых системах Sparclet. GDB использует код, который выполняется как Unix-машине, так и на цели Sparclet. Программа gdb устанавливается и работает на Unix-машине.

remotetimeout арг
GDB поддерживает параметр remotetimeout. Он устанавливатся пользователем, а арг представляет число секунд, в течение которых GDB ожидает ответы.

При компиляции для отладки, используйте ключи `-g' для получения отладочной информации, и `-Ttext' для того, чтобы разместить программу в том месте, в каком вы хотите загрузить ее на целевую машину. Вы также можете добавить ключ `-n' или `-N', чтобы уменьшить размеры разделов. Например: 

sparclet-aout-gcc prog.c -Ttext 0x12010000 -g -o prog -N

Для проверки, что адреса в действительности являются теми, которые вы подразумевали, можно использовать objdump: 

sparclet-aout-objdump --headers --syms prog

После того, как вы установили путь поиска выполняемых файлов, в котором присутствует GDB, вы готовы запустить отладчик. С вашей рабочей машины Unix, выполните gdb (или sparclet-aout-gdb, в зависимости от вашей установки).

GDB запустится и покажет приглашение: 

(gdbslet)

14.3.13.1 Установка файла для отладки

Команда GDB file позволяет вам выбрать программу для отладки. 

(gdbslet) file prog

Затем GDB пытается прочитать таблицу символов программы `prog'. Он находит файл путем поиска в каталогах, перечисленных в пути поиска команд. Если файл был скомпилирован с отладочной информацией (ключ `-g'), то также будет произведен поиск исходных файлов. GDB находит исходные файлы, производя поиск в каталогах, перечисленных в пути поиска каталогов (см. раздел 4.4 Рабочая среда вашей программы). Если ему не удается найти файл, он выводит сообщение, подобное этому: 

prog: No such file or directory.

Когда это случается, добавьте соответствующие каталоги в пути поиска с помощью команд GDB path и dir, и выполните команду target снова.

14.3.13.2 Соединение к Sparclet

Команда GDB target позволяет вам установить соединение с целевой машиной Sparclet. Для соединения с последовательным портом "ttya", введите: 

(gdbslet) target sparclet /dev/ttya
Remote target sparclet connected to /dev/ttya
main () at ../prog.c:3

GDB выведет сообщение, подобное этому: 

Connected to ttya.

14.3.13.3 Загрузка на Sparclet

Когда вы установили соединение к цели Sparclet, вы можете использовать команду GDB load для загрузки файла с рабочей машины на целевую. Имя файла и смещение загрузки должно быть задано команде load в качестве аргумента. Так как формат файла aout, программа должна быть загружена по начальному адресу. Чтобы определить, чему равна эта величина, вы можете использовать objdump. Смещение загрузки--это смещение, которое добавляется к VMA (Virtual Memory Address(17)) каждого раздела файла. Например, если программа `prog' была скомпонована с адресом текста 0x1201000, сегментом данных по адресу 0x12010160 и сегментом стека по адресу 0x12010170, введите в GDB: 

(gdbslet) load prog 0x12010000
Loading section .text, size 0xdb0 vma 0x12010000

Если код загружается по адресу, отличному от того, по которому программа была скомпонована, вам может потребоваться использовать команды section и add-symbol-file, чтобы сообщить GDB, куда отобразить таблицу символов.

14.3.13.4 Выполнение и отладка

Теперь вы можете начать отлаживать задачу, используя команды GDB для управления выполнением, b, step, run, и так далее. Все такие команды перечислены в этом руководстве. 

(gdbslet) b main
Breakpoint 1 at 0x12010000: file prog.c, line 3.
(gdbslet) run
Starting program: prog
Breakpoint 1, main (argc=1, argv=0xeffff21c) at prog.c:3
3        char *symarg = 0;
(gdbslet) step
4        char *execarg = "hello!";
(gdbslet)

14.3.14 Fujitsu Sparclite

target sparclite устр
Платы Fujitsu sparclite, используемые только с целью загрузки. Чтобы отлаживать программу, вы должны использовать дополнительную команду. Например, target remote устр, используя стандартный удаленный протокол GDB.

14.3.15 Tandem ST2000

GDB может быть использован с телефонным коммутатором Tandem ST2000, поддерживающим протокол Tandem STDBUG.

Для соединения вашего ST2000 с рабочей машиной, смотрите руководство производителя. После того, как ST2000 физически подключен, вы можете выполнить: 

target st2000 устр скорость

чтобы установить его как вашу отладочную среду. Устр---это обычно имя последовательного устройства, такое как `/dev/ttya', соединенного с ST2000 через последовательную линию. Вместо этого, вы можете указать устр как TCP-соединение (например, к последовательной линии, присоединенной через терминальный концентратор), используя синтаксис имя-машины:номер-порта.

Команды load и attach не определены для этой цели; вы должны загрузить вашу программу на ST2000 также, как вы это обычно делаете для автономных действий. GDB читает отладочную информацию (например, символы) из отдельной, отладочной версии программы, которая доступна на вашем рабочем компьютере.

Следующие вспомогательные команды GDB доступны для облегчения работы в среде ST2000:

st2000 команда
Послать команду монитору STDBUG. Доступные команды описаны в руководстве производителя.
connect
Соединяет управляющий терминал с командным монитором STDBUG. Когда вы закончили взаимодействие с STDBUG, ввод одной из двух последовательностей символов возвратит вас назад к приглашению GDB: RET~. (Return, за которым следует тильда и точка) или RET~C-d (Return, за которым следует тильда и control-D).

14.3.16 Zilog Z8000

Будучи сконфигурированным для отладки целей Zilog Z8000, GDB включает имитатор Z8000.

Для семейства Z8000, `target sim' имитирует либо Z8002 (не сегментированный вариант архитектуры Z8000), либо Z8001 (сегментированный вариант). Имитатор распознает подходящую архитектуру изучая объектный код.

target sim арг
Отладка программ на имитируемом ЦП. Если имитатор поддерживает параметры установки, укажите их в арг.

После определения этой цели, вы можете отлаживать программы для имитированного ЦП таким же образом, как программы для вашего рабочего компьютера; используйте команду file для загрузки образа новой программы, команду run для запуска вашей программы, и так далее.

Помимо того, что доступны все обычные машинные регистры (см. раздел 8.10 Регистры), имитатор Z8000 предоставляет три специально названных регистра с дополнительной информацией:

cycles
Считает тактовые импульсы с имитаторе.
insts
Считает инструкции, выполненные в имитаторе.
time
Время выполнения в шестидесятых долях секунды.

Вы можете ссылаться на эти значения в выражениях GDB с помощью обычных соглашений; например, `b fputc if $cycles>5000' устанавливает условную точку останова, которая срабатывает только после как минимум 5000 имитированных тактовых импульсов.

14.4 Архитектуры

Этот раздел описывает свойства архитектур, которые воздействуют на все применения GDB с данной архитектурой, как при чистой отладке, так и при кросс-отладке.

14.4.1 A29K

set rstack_high_address адрес
В процессорах семейства AMD 29000, регистры сохраняются в отдельном стеке регистров. Для отладчика не существует способа определить размер этого стека. Обычно, GDB просто подразумевает, что стек "достаточно большой". Это может привести к тому, что GDB попытается обратиться несуществующей области памяти. В случае необходимости, вы можете решить эту проблему, указав конечный адрес стека регистров с помощью команды set rstack_high_address. Аргумент должен быть адресом, который вы, вероятно, захотите начать с `0x', чтобы задать его в шестнадцатеричном виде.
show rstack_high_address
Отобразить текущее ограничение на стек регистров для процессоров семейства AMD 29000.

14.4.2 Alpha

Смотрите следующий раздел.

14.4.3 MIPS

Компьютеры, базирующиеся на архитектурах Alpha и MIPS, используют необычный кадр стека, который иногда требует от GDB поиска в объектном коде в обратном направлении, чтобы найти начало функции.

Чтобы сократить время ответа (особенно для встроенных приложений, где GDB может быть ограничен медленной последовательной линией для этого поиска), вы можете захотеть ограничить область поиска, используя одну из этих команд:

set heuristic-fence-post предел
Ограничить GDB для исследования не более предела байт при поиске начала функции. Значение 0 (по умолчанию) означает неограниченный поиск. Однако, исключая 0, чем больше предел, тем больше байт heuristic-fence-post должен просмотреть, и, следовательно, тем дольше он будет выполняться.
show heuristic-fence-post
Отобразить текущее значение данного предела.

Эти команды доступны только когда GDB сконфигурирован для отладки программ на процессорах Alpha или MIPS.

[Содержание]   [Назад]   [Пред]   [Вверх]   [След]   [Вперед]