В то время как почти все команды 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, load компонует имя-файла динамически на текущей
целевой системе, и добавляет ее символьную информацию в GDB.
GDB позволяет разработчикам запускать и отлаживать задачи,
выполняющиеся на сетевых целях VxWorks, с Unix-машин. Уже выполняющиеся
задачи, запущенные из оболочки VxWorks, также могут быть отлажены.
GDB использует код, который может выполняться как на машине
Unix, так и на целевой машине VxWorks. Программа gdb
устанавливается и выполняется на Unix-машине. (Она может быть
установлена под именем vxgdb, чтобы отличать ее от GDB
для отладки программ на рабочей машине.)
VxWorks-timeout арг
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 устр
target amd-eb устр скорость прог
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 кл-слово
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 \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 не загружает программы по последовательной линии.
Наконец, перейдите в каталог, содержащий образ вашей программы 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 устр
target rdp устр
target hms устр
device и speed для управления последовательной линией и
используемой скоростью связи.
target e7000 устр
target sh3 устр
target sh3e устр
Когда вы выбираете удаленную отладку платы Hitachi SH, H8/300 или
H8/500, команда load загружает вашу программу на плату Hitachi, и
также открывает ее как текущую выполняемую цель для GDB на
вашей машине (как команда file).
Для общения с вашим Hitachi SH, H8/300 или H8/500, GDB необходимо знать следующие вещи:
Используйте специальную команду 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 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 на вашей плате разработки
В любом случае, GDB видит результат нажатия RESET на плате разработки как "нормальное завершение" вашей программы.
Вы можете использовать встроенный эмулятор E7000 для разработки кода либо для Hitachi SH, либо для H8/300H. Используйте одну из этих форм команды `target e7000' для соединения GDB с вашей E7000:
target e7000 порт скорость
target e7000 имя-узла
telnet.
Некоторые команды GDB доступны только для H8/300:
set machine h8300
set machine h8300h
set memory мод
show memory
small, big, medium и compact.
target mon960 устр
target nindy имя-устр
Nindy---это программа ROM Monitor для целевых систем Intel 960. Когда GDB сконфигурирован для управления удаленным Intel 960 с использование Nindy, вы можете указать ему, как присоединиться к 960 несколькими способами:
target в любом месте вашего сеанса
GDB. См. раздел 13.2 Команды для управления целями.
С интерфейсом 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 порт
tty (например, `-r a').
-O
Предупреждение: если вы определите `-O', но в действительности попытаетесь связаться с системой, которая ожидает более нового протокола, соединение не будет установлено, как будто не соответствуют скорости. GDB неоднократно пытается соединиться снова на нескольких различных скоростях линии. Вы можете остановить этот процесс посредством прерывания.
-brk
BREAK, пытаясь сбросить ее, перед соединением с целью
Nindy.
Предупреждение: Многие целевые системы не имеют требуемых для этого аппаратных средств; это работает только на немногих платах.
Стандартный ключ `-b' управляет скоростью линии, используемой на последовательном порту.
reset
target m32r устр
Конфигурация Motorola m68k включает поддержку ColdFire, и команду
target для следующих мониторов ROM.
target abug устр
target cpu32bug устр
target dbug устр
target est устр
target rom68k устр
Если GDB сконфигурирован с m68*-ericsson-*, то вместо
этого у него будет только одна специальная команда target:
target es1800 устр
target rombug устр
target bug устр
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 имя-машины:номер-порта
target pmon порт
target ddb порт
target lsi порт
target r3900 устр
target array устр
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
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
set timeout секунды.
Значение по умолчанию--5 секунд. Аналогично, вы можете управлять
временем ожидания, используемом при ожидании подтверждения пакета с
помощью команды set retransmit-timeout секунды. По
умолчанию 3 секунды. Вы можете узнать обе эти величины с помощью
show timeout и show retransmit-timeout. (Эти команды
доступны только если GDB сконфигурирован для цели
`--target=mips-idt-ecoff'.)
Время ожидания, установленное при помощи set timeout, не имеет
значения, когда GDB ожидает остановки вашей программы. В этом
случае, GDB ждет бесконечно, потому что у него нет способа
узнать, сколько будет выполняться программа до остановки.
target dink32 устр
target ppcbug устр
target ppcbug1 устр
target sds устр
target op50n устр
target w89k устр
target hms устр
device и
speed для управления последовательной линией и используемой
скоростью связи.
target e7000 устр
target sh3 устр
target sh3e устр
GDB позволяет разработчикам отлаживать с Unix-машины задачи,
выполняющиеся в целевых системах Sparclet. GDB использует код,
который выполняется как Unix-машине, так и на цели Sparclet. Программа
gdb устанавливается и работает на Unix-машине.
timeout арг
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 устр
GDB может быть использован с телефонным коммутатором Tandem ST2000, поддерживающем протокол Tandem STDBUG.
Для соединения вашего ST2000 с рабочей машиной, смотрите руководство производителя. После того, как ST2000 физически подключен, вы можете выполнить:
target st2000 устр скорость
чтобы установить его как вашу отладочную среду. Устр---это обычно
имя последовательного устройства, такое как `/dev/ttya',
соединенного с ST2000 через последовательную линию. Вместо этого, вы
можете указать устр как TCP-соединение (например, к
последовательной линии, присоединенной через терминальный концентратор),
используя синтаксис имя-машины:номер-порта.
Команды load и attach не определены для этой цели;
вы должны загрузить вашу программу на ST2000 также, как вы бы обычно
сделали для автономных действий. GDB читает отладочную
информацию (например, символы) из отдельной, отладочной версии
программы, которая доступна на вашем рабочем компьютере.
Следующие вспомогательные команды GDB доступны для облегчения работы со средой ST2000:
st2000 команда
connect
Будучи сконфигурированным для отладки целей 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 адрес
set
rstack_high_address. Аргумент должен быть адресом, который вы,
вероятно, захотите начать с `0x', чтобы задать адрес в
шестнадцатеричном виде.
show rstack_high_address
Смотрите следующий раздел.
Компьютеры, базирующиеся на архитектурах Alpha и MIPS, используют необычный кадр стека, который иногда требует от GDB поиска в объектном коде в обратном направлении, чтобы найти начало функции.
Чтобы сократить время ответа (особенно для встроенных приложений, где GDB может быть ограничен медленной последовательной линией для этого поиска), вы можете захотеть ограничить область поиска, используя одну из этих команд:
set heuristic-fence-post предел
heuristic-fence-post должен просмотреть, и,
следовательно, тем дольше он будет выполняться.
show heuristic-fence-post
Эти команды доступны только когда GDB сконфигурирован для отладки программ на процессорах Alpha или MIPS.