Существует три основные категории конфигураций: чистые конфигурации, где рабочая и целевая машины совпадают, конфигурации для встроенных операционных систем, которые обычно совпадают для нескольких различных архитектур процессоров, и отдельные встроенные процессоры, которые сильно отличаются друг от друга.
Этот раздел описывает детали, специфичные для определенных чистых конфигураций.
В системах HP-UX, если вы ссылаетесь на функцию или переменную, имя которой начинается со знака доллара, GDB сперва ищет имя пользователя или системы, до поиска вспомогательной переменной.
Многие версии SVR4 предоставляют возможность, называемую `/proc', которая может быть использована для исследования образа выполняемого процесса, используя подпрограммы файловой системы. Если GDB сконфигурирован для операционной системы, поддерживающей эту возможность, команда info proc доступна для получения отчета по некоторым видам информации о процессе, выполняющем вашу программу. info proc работает только на системах SVR4, которые включают код procfs. Среди этих систем: OSF/1 (Digital Unix), Solaris, Irix и Unixware, но не HP-UX или Linux, к примеру.
Этот раздел описывает конфигурации, задействующие отладку встроенных операционных систем, которые доступны для нескольких различных архитектур.
GDB включает возможность отлаживать программы, выполняющиеся в различных операционных системах реального времени.
На VxWorks, load компонует имя-файла динамически на текущей целевой системе, и добавляет ее символьную информацию в GDB.
GDB позволяет разработчикам запускать и отлаживать с Unix-машин задачи, выполняющиеся на сетевых целях VxWorks. Уже выполняющиеся задачи, запущенные из оболочки VxWorks, также могут быть отлажены. GDB использует код, который может выполняться как на машине Unix, так и на целевой машине VxWorks. Программа gdb устанавливается и выполняется на Unix-машине. (Она может быть установлена под именем vxgdb, чтобы отличать ее от GDB для отладки программ на рабочей машине.)
Следующая информация о соединении к 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 находит эти файлы путем поиска в каталогах, перечисленных в путях поиска команд (see section Рабочая среда вашей программы); если ему не удается найти объектный файл, он выводит подобное сообщение:
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 "<VAR>vxpath</VAR>/vw/demo/rdb"
Затем, в GDB, введите:
(vxgdb) cd <VAR>hostpath</VAR>/vw/demo/rdb (vxgdb) load prog.o
GDB отобразит ответ, аналогичный этому:
Reading symbol data from wherever/vw/demo/rdb/prog.o... done.
Вы также можете использовать команду load, чтобы заново загрузить объектный модуль, после редактирования и повторной компиляции соответствующего исходного файла. Заметьте, что при этом GDB удаляет все определенные точки останова, автоматические отображения, вспомогательные переменные, и очищает историю значений. (Это необходимо для того, чтобы сохранить целостность структур данных отладчика, которые ссылаются на таблицу символов целевой системы.)
Вы также можете присоединиться к существующей задаче, используя команду attach следующим образом:
(vxgdb) attach <VAR>задача</VAR>
где задача является шестнадцатеричным идентификатором задачи VxWorks. Когда вы присоединяетесь к задаче, она может выполняться либо быть приостановленной. Выполняющаяся задача приостанавливается в момент присоединения.
Этот раздел описывает детали, специфичные для определенных встроенных конфигураций.
Для отладки процессоров семейства a29k, GDB поддерживает протокол AMD UDI ("Universal Debugger Interface"(16)). Для использования этой конфигурации с целями AMD, на которых выполняется монитор MiniMON, вам нужна программа MONTIP, доступная бесплатно у AMD. Вы можете также использовать GDB с программой ISSTIP, UDI-совместимым эмулятором a29k, также доступным у AMD.
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, или неожиданные события на стороне ПК.
Когда вы выбираете удаленную отладку для платы 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, см. section Команды для задания файлов.)
(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:
Некоторые команды GDB доступны только для H8/300:
Nindy---это программа ROM Monitor для целевых систем Intel 960. Когда GDB сконфигурирован для управления удаленным Intel 960 с использованием Nindy, вы можете указать ему, как присоединиться к 960 несколькими способами:
С интерфейсом Nindy к плате Intel 960, команда load загружает имя-файла на 960, а также добавляет его символьные данные в GDB.
Если вы просто запустите gdb без использования ключей командной строки, у вас запросят, какой последовательный порт использовать, до того, как вы получите обычное приглашение GDB:
Attach /dev/ttyNN -- specify NN, or "quit" to quit:
Ответьте на запрос с любым суффиксом (после `/dev/tty'), определяющим последовательный порт, который вы хотите использовать. Вы можете, по своему выбору, просто начать работу без соединения с Nindy, ответив на приглашение пустой строкой. Если вы сделаете это и позже захотите присоединиться к Nindy, используйте target (see section Команды для управления целями).
Вот параметры вызова для начала вашего сеанса GDB с подключенной платой Nindy-960:
Предупреждение: если вы определите `-O', но в действительности попытаетесь связаться с системой, которая ожидает более нового протокола, соединение не будет установлено, как будто не соответствуют скорости. GDB неоднократно пытается соединиться снова на нескольких различных скоростях линии. Вы можете остановить этот процесс посредством прерывания.
Предупреждение: Многие целевые системы не имеют требуемых для этого аппаратных средств; это работает только на немногих платах.
Стандартный ключ `-b' управляет скоростью линии, используемой на последовательном порту.
Конфигурация Motorola m68k включает поддержку ColdFire, и команду target для следующих мониторов ROM.
Если GDB сконфигурирован с m68*-ericsson-*, то вместо этого у него будет только одна специальная команда target:
GDB может использовать удаленный отладочный протокол MIPS для взаимодействия с платой MIPS, присоединенной к последовательной линии. Эта возможность доступна, если вы сконфигурировали GDB с `--target=mips-idt-ecoff'.
Используйте эти команды GDB для определения соединения с вашей целевой платой:
host$ gdb <VAR>prog</VAR> GDB is free software and ... (gdb) target mips /dev/ttyb (gdb) load <VAR>prog</VAR> (gdb) run
GDB также поддерживает следующие специальные команды для целей MIPS:
GDB позволяет разработчикам отлаживать с Unix-машины задачи, выполняющиеся на целевых системах Sparclet. GDB использует код, который выполняется как Unix-машине, так и на цели Sparclet. Программа gdb устанавливается и работает на Unix-машине.
При компиляции для отладки, используйте ключи `-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 находит исходные файлы, производя поиск в каталогах, перечисленных в пути поиска каталогов (see section Рабочая среда вашей программы). Если ему не удается найти файл, он выводит сообщение, подобное этому:
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 (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)
GDB может быть использован с телефонным коммутатором Tandem ST2000, поддерживающим протокол Tandem STDBUG.
Для соединения вашего ST2000 с рабочей машиной, смотрите руководство производителя. После того, как ST2000 физически подключен, вы можете выполнить:
target st2000 <VAR>устр</VAR> <VAR>скорость</VAR>
чтобы установить его как вашу отладочную среду. Устр---это обычно имя последовательного устройства, такое как `/dev/ttya', соединенного с ST2000 через последовательную линию. Вместо этого, вы можете указать устр как TCP-соединение (например, к последовательной линии, присоединенной через терминальный концентратор), используя синтаксис имя-машины:номер-порта.
Команды load и attach не определены для этой цели; вы должны загрузить вашу программу на ST2000 также, как вы это обычно делаете для автономных действий. GDB читает отладочную информацию (например, символы) из отдельной, отладочной версии программы, которая доступна на вашем рабочем компьютере.
Следующие вспомогательные команды GDB доступны для облегчения работы в среде ST2000:
Будучи сконфигурированным для отладки целей Zilog Z8000, GDB включает имитатор Z8000.
Для семейства Z8000, `target sim' имитирует либо Z8002 (не сегментированный вариант архитектуры Z8000), либо Z8001 (сегментированный вариант). Имитатор распознает подходящую архитектуру изучая объектный код.
После определения этой цели, вы можете отлаживать программы для имитированного ЦП таким же образом, как программы для вашего рабочего компьютера; используйте команду file для загрузки образа новой программы, команду run для запуска вашей программы, и так далее.
Помимо того, что доступны все обычные машинные регистры (see section Регистры), имитатор Z8000 предоставляет три специально названных регистра с дополнительной информацией:
Вы можете ссылаться на эти значения в выражениях GDB с помощью обычных соглашений; например, `b fputc if $cycles>5000' устанавливает условную точку останова, которая срабатывает только после как минимум 5000 имитированных тактовых импульсов.
Этот раздел описывает свойства архитектур, которые воздействуют на все применения GDB с данной архитектурой, как при чистой отладке, так и при кросс-отладке.
Смотрите следующий раздел.
Компьютеры, базирующиеся на архитектурах Alpha и MIPS, используют необычный кадр стека, который иногда требует от GDB поиска в объектном коде в обратном направлении, чтобы найти начало функции.
Чтобы сократить время ответа (особенно для встроенных приложений, где GDB может быть ограничен медленной последовательной линией для этого поиска), вы можете захотеть ограничить область поиска, используя одну из этих команд:
Эти команды доступны только когда GDB сконфигурирован для отладки программ на процессорах Alpha или MIPS.