Отладка с помощью GDB - 14. Информация о конфигурации
[Содержание] [Назад] [Пред] [Вверх] [След] [Вперед]
В то время как почти все команды GDB доступны для всех чистых
и кросс-версий отладчика, существуют некоторые исключения. Эта глава
описывает вещи, доступные только в определенных конфигурациях.
Существует три основные категории конфигураций: чистые конфигурации, где
рабочая и целевая машины совпадают, конфигурации для встроенных
операционных систем, которые обычно совпадают для нескольких различных
архитектур процессоров, и отдельные встроенные процессоры, которые
сильно отличаются друг от друга.
Этот раздел описывает детали, специфичные для определенных чистых
конфигураций.
В системах HP-UX, если вы ссылаетесь на функцию или на имя переменной,
начинающуюся со знака доллара, GDB сперва ищет имя пользователя
или системы, до поиска вспомогательной переменной.
Многие версии 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
-
Показывает всю вышеперечисленную информацию о процессе.
Этот раздел описывает конфигурации, задействующие отладку встроенных
операционных систем, которые доступны для нескольких различных архитектур.
GDB включает возможность отлаживать программы, выполняющиеся в
различных операционных системах реального времени.
target vxworks имя-машины
-
Система VxWorks, присоединенная посредством TCP/IP. Аргумент
имя-машины есть имя или IP-адрес машины целевой системы.
На VxWorks, load компонует имя-файла динамически на текущей
целевой системе, и добавляет ее символьную информацию в GDB.
GDB позволяет разработчикам запускать и отлаживать задачи,
выполняющиеся на сетевых целях VxWorks, с Unix-машин. Уже выполняющиеся
задачи, запущенные из оболочки 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)
Команда 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 снова.
Если вы соединились с целевой машиной 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 удаляет все
определенные точки останова, автоматические отображения, вспомогательные
переменные, и очищает историю значений. (Это необходимо для того, чтобы
сохранить целостность структур данных отладчика, которые ссылаются
на таблицу символов целевой системы.)
Вы также можете присоединиться к существующей задаче, используя команду
attach следующим образом:
(vxgdb) attach задача
где задача является шестнадцатеричным идентификатором задачи
VxWorks. Задача может выполняться или быть приостановленной, когда вы
к ней присоединяетесь. Выполняющаяся задача приостанавливается в момент
присоединения.
Этот раздел описывает детали, специфичные для определенных встроенных
конфигураций.
target adapt устр
-
Монитор Adapt для A29K.
target amd-eb устр скорость прог
-
Удаленная PC-резидентная плата AMD EB29K, присоединенная по
последовательным линиям. Устр является последовательным
устройством, также как для
target remote; скорость
позволяет вам указать скорость линии; а прог является именем
программы, которая будет отлаживаться, так, как оно появляется в ДОС на ПК.
См. раздел 14.3.1.2 Протокол EBMON для AMD29K.
Для отладки процессоров семейства a29k, GDB поддерживает
протокол AMD UDI ("Universal Debugger
Interface"@transnote{Универсальный отладочный интерфейс}). Для использования
этой конфигурации с целями AMD, на которых выполняется монитор MiniMON,
вам нужна программа MONTIP, доступная бесплатно у AMD. Вы можете
также использовать GDB с программой ISSTIP,
UDI-совместимым эмулятором a29k, также доступным у AMD.
target udi кл-слово
-
Выбрать UDI-интерфейс к удаленной плате a29k или эмулятору, где
кл-слово является элементом в конфигурационном файле AMD
`udi_soc'. Этот файл содержит в качестве элементов ключевые слова,
которые определяют параметры, используемые при соединении к целям a29k.
Если файл `udi_soc' не находится в вашем рабочем каталоге, вы
должны установить путь к нему в переменной среды `UDICONF'.
AMD распространяет платы разработки 29K, предназначенную для помещения в
ПК, вместе с программой монитора EBMON, работающей в ДОС. Коротко эта
система разработки называется "EB29K". Чтобы использовать
GDB из Unix-системы для выполнения программ на плате EB29K, вы
должны сперва соединить последовательным кабелем ПК (в котором
установлена плата EB29K) и последовательный порт на Unix-системе. Далее
мы предполагаем, что вы соединили кабелем порт ПК `COM1' и
`/dev/ttya' на Unix-системе.
Следующим шагом нужно установить параметры порта ПК, сделав что-то
вроде этого в ДОС:
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 usrjoework29k
G:USRJOEWORK29K> 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 не загружает программы по последовательной
линии.
Наконец, перейдите в каталог, содержащий образ вашей программы 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.
Команда target amd-eb создает в текущем рабочем каталоге файл
`eb.log', чтобы помочь отладить проблемы с соединением.
`eb.log' записывает весь вывод `EBMON', включая эхо
посланных ему команд. Выполнение `tail -f' для этого файла в другом
окне часто помогает понять проблемы с EBMON, или неожиданные
события на стороне ПК.
target rdi устр
-
Монитор ARM Angel, через интерфейс библиотеки RDI к протоколу ADP. Вы
можете использовать эту цель для взаимодействия как с платами, на
которых выполняется монитор Angel, так и с устройством отладки
EmbeddedICE JTAG.
target rdp устр
-
Монитор ARM Demon.
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
необходимо знать следующие вещи:
-
что вы хотите использовать `target hms', удаленный отладочный
интерфейс для микропроцессоров Hitachi, или `target e7000',
встроенный эмулятор для Hitachi SH и Hitachi 300H. (`target hms'
используется по умолчанию, если GDB сконфигурирован специально
для Hitachi SH, H8/300 или H8/500.)
-
какое последовательное устройство соединяет вашу машину с платой 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:H8300TEST> asynctsr 2
C:H8300TEST> 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:H8300TEST) 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 20000326, 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 на плате
разработки как "нормальное завершение" вашей программы.
Вы можете использовать встроенный эмулятор E7000 для разработки кода либо
для Hitachi SH, либо для H8/300H. Используйте одну из этих форм команды
`target e7000' для соединения GDB с вашей E7000:
target e7000 порт скорость
-
Используйте эту форму, если ваша E7000 присоединена к последовательному
порту. Аргумент порт идентифицирует, какой последовательный порт
использовать (например, `com2'). Третий аргумент является
скоростью линии в битах в секунду (например, `9600').
target e7000 имя-узла
-
Если ваша E7000 установлена как узел сети TCP/IP, вы можете просто
указать его имя; GDB использует для соединения
telnet.
Некоторые команды GDB доступны только для H8/300:
set machine h8300
-
set machine h8300h
-
Настраивайте GDB на один из двух вариантов архитектур H8/300 с
помощью `set machine'. Вы можете использовать `show machine',
чтобы проверить, какой из вариантов действует в данный момент.
set memory мод
-
show memory
-
Укажите, какую модель памяти H8/500 (мод) вы используете с помощью
`set memory'; проверяйте, какая модель используется при помощи
`show memory'. Допустимыми значениями для мод являются
small, big, medium и compact.
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 Команды для управления целями.
- target nindy имя-устр
Плата Intel 960, управляемая Nindy Monitor. Имя-устр---это имя
последовательного устройства, которое должно использоваться для
соединения, например, `/dev/ttya'.
С интерфейсом Nindy к плате Intel 960, команда load загружает
имя-файла на 960, а также добавляет его символьные данные в
GDB.
Если вы просто запустите gdb без использования ключей
командной строки, у вас запросят, какой последовательный порт
использовать, до того, как вы получите обычное приглашение
GDB:
Attach /dev/ttyNN -- specify NN, or "quit" to quit:
Ответьте на запрос с любым суффиксом (после `/dev/tty'),
определяющим последовательный порт, который вы хотите использовать. Вы
можете, по своему выбору, просто начать работу без соединения с
Nindy, ответив на приглашение пустой строкой. Если вы сделаете это и позже
захотите присоединиться к Nindy, используйте target
(см. раздел 13.2 Команды для управления целями).
Вот параметры запуска для начала вашего сеанса 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' управляет скоростью линии, используемой на
последовательном порту.
reset
-
Для целей Nindy, эта команда посылает "break" удаленной целевой
системе; она полезна, только если целевая система была оборудована
схемой для выполнения аппаратного сброса (или других действий,
представляющих интерес) при обнаружении прерывания.
target m32r устр
-
Монитор ROM Mitsubishi M32R/D.
Конфигурация 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.
target bug устр
-
Монитор BUG, выполняющийся на плате MVME187 (m88k).
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 ждет бесконечно, потому что у него нет способа
узнать, сколько будет выполняться программа до остановки.
target dink32 устр
-
Монитор ROM DINK32.
target ppcbug устр
-
target ppcbug1 устр
-
Монитор ROM PPCBUG для PowerPC.
target sds устр
-
Монитор SDS, выполняющийся на плате PowerPC (такой как Motorola ADS).
target op50n устр
-
Монитор OP50N, выполняющийся на плате OKI HPPA.
target w89k устр
-
Монитор W89K, выполняющийся на плате Winbond HPPA.
target hms устр
-
Плата Hitachi SH, присоединенная через последовательную линию к вашей
рабочей иашине. Используйте специальные команды
device и
speed для управления последовательной линией и используемой
скоростью связи.
target e7000 устр
-
Эмулятор E7000 для Hitachi SH.
target sh3 устр
-
target sh3e устр
-
Целевые системы Hitachi SH-3 и SH-3E.
GDB позволяет разработчикам отлаживать с Unix-машины задачи,
выполняющиеся в целевых системах Sparclet. GDB использует код,
который выполняется как Unix-машине, так и на цели Sparclet. Программа
gdb устанавливается и работает на Unix-машине.
timeout арг
-
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)
Команда GDB file позволяет вам выбрать программу для
отладки.
(gdbslet) file prog
Затем GDB пытается прочитать таблицу символов программы
`prog'. Он находит файл путем поиска в каталогах, перечисленных в
пути поиска команд. Если файл был скомпилирован с отладочной
информацией (ключ `-g'), будет также произведен поиск исходных
файлов. GDB находит исходные файлы, производя поиск в
каталогах, перечисленных в пути поиска каталогов (см. раздел 4.4 Рабочая среда вашей программы). Если ему не удается найти файл, он выводит
сообщение, подобное этому:
prog: No such file or directory.
Когда это случается, добавьте соответствующие каталоги в пути поиска с
помощью команд GDB path и dir, и выполните
команду target снова.
Команда 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.
Когда вы установили соединение к Sparclet, вы можете использовать
команду GDB load для загрузки файла с рабочей машины на
целевую. Имя файла и смещение загрузки должно быть задано в качестве
аргумента команде load. Так как формат файла aout, программа
должна быть загружена по начальному адресу. Чтобы определить, чему
равна эта величина, вы можете использовать objdump. Смещение
загрузки--это смещение, которое добавляется к VMA@transnote{от virtual
memory address, виртуальный адрес памяти.} каждого раздела файла.
Например, если программа `prog' была скомпонована с адресом текста
0x1201000, сегментом данных по адресу 0x12010160 и сегментом стека по
адресу 0x12010170, то в GDB введите:
(gdbslet) load prog 0x12010000
Loading section .text, size 0xdb0 vma 0x12010000
Если код загружается по адресу, отличному от того, по которому программа
была скомпонована, вам может потребоваться использовать команды
section и add-symbol-file, чтобы сообщить GDB,
куда отобразить таблицу символов.
Теперь вы можете начать отлаживать задачу, используя команды
GDB для управления выполнением, b, step,
run, и так далее. Все такие команды перечислены в руководстве по
GDB.
(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)
target sparclite устр
-
Платы Fujitsu sparclite, используемые только с целью загрузки. Чтобы
отлаживать программу, вы должны использовать дополнительную команду.
Например, target remote устр, используя стандартный удаленный
протокол GDB.
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).
Будучи сконфигурированным для отладки целей 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 имитированных тактовых импульсов.
Этот раздел описывает свойства архитектур, которые воздействуют на все
применения GDB с данной архитектурой, как при чистой отладке,
так и при кросс-отладке.
set rstack_high_address адрес
-
В процессорах семейства AMD 29000, регистры сохраняются в отдельном
стеке регистров. Для GDB не существует способа
определить размер этого стека. Обычно, GDB просто
подразумевает, что стек "достаточно большой". Это может привести к
тому, что GDB попытается обратиться несуществующей области
памяти. В случае необходимости, вы можете решить эту проблему, указав
конечный адрес стека регистров с помощью команды
set
rstack_high_address. Аргумент должен быть адресом, который вы,
вероятно, захотите начать с `0x', чтобы задать адрес в
шестнадцатеричном виде.
show rstack_high_address
-
Отобразить текущее ограничение на стек регистров, для процессоров
семейства AMD 29000.
Смотрите следующий раздел.
Компьютеры, базирующиеся на архитектурах Alpha и MIPS, используют
необычный кадр стека, который иногда требует от GDB поиска в
объектном коде в обратном направлении, чтобы найти начало функции.
Чтобы сократить время ответа (особенно для встроенных приложений, где
GDB может быть ограничен медленной последовательной линией для
этого поиска), вы можете захотеть ограничить область поиска, используя
одну из этих команд:
set heuristic-fence-post предел
-
Ограничить GDB для исследования не более предела байт при
поиске начала функции. Значение 0 (по умолчанию) означает
неограниченный поиск. Обнако, исключая 0, чем больше предел, тем
больше байт
heuristic-fence-post должен просмотреть, и,
следовательно, тем дольше он будет выполняться.
show heuristic-fence-post
-
Отобразить текущее значение предела.
Эти команды доступны только когда GDB сконфигурирован
для отладки программ на процессорах Alpha или MIPS.
[Содержание] [Назад] [Пред] [Вверх] [След] [Вперед]
|
