В то время как почти все команды 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 позволяет разработчикам запускать и отлаживать с Unix-машин
задачи, выполняющиеся на сетевых целях VxWorks. Уже выполняющиеся
задачи, запущенные из оболочки 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"(16)). Для использования
этой конфигурации с целями 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 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 на вашей плате разработки
В любом случае, 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 использовать регистры ЦП, соответствующие микросхеме
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-машине.
remotetimeout арг
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 в качестве аргумента. Поскольку это файл в формате a.out, программа
должна быть загружена по начальному адресу. Чтобы определить, чему
равна эта величина, вы можете использовать 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,
куда отобразить таблицу символов.
Теперь вы можете начать отлаживать задачу, используя команды
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)
target sparclite устр
target remote устр, используя стандартный удаленный
протокол GDB.
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.