Как переименовать отладочную информацию? - PullRequest
0 голосов
/ 13 января 2012

РЕДАКТИРОВАТЬ: я перефразирую полностью мой первоначальный вопрос, поскольку он был далеко не ясен (его неясность можно увидеть внизу!).

Я разрабатываю ОСРВ, где и ядро, и приложениядолжны быть сопоставлены с очень конкретными местами в памяти.Например:

0x00000000:0x0000ffff: application #1
0x00010000:0x0000ffff: application #2
...
0xffff0000:0xffffffff: kernel

Приложения (и ядро) разрабатываются (и компилируются) отдельно.Чтобы объединить все в один исполняемый файл, используется следующий процесс:

  1. (отдельно) Компилировать ядро ​​и приложения (без каких-либо символов).
  2. (через скрипт)Сгенерируйте скрипт компоновщика, чтобы переместить ядро ​​и приложения в нужные места.Чтобы предотвратить конфликты между именами разделов, сгенерированный скрипт компоновщика «переименовывает» все разделы всех приложений (например, .app1.text, .app1.data, .app1.bss, ...).
  3. Ссылкаиспользуя ранее сгенерированный скрипт компоновщика (т.е. объединяем все).

Вопрос 1) Можно ли заменить шаги # 2 и # 3 чем-то вроде следующего процесса?

  1. Переместите объектные файлы ядра и приложений в нужную позицию.
  2. Переименуйте все символы в объектных файлах приложений (чтобы предотвратить конфликт имен).
  3. Объедините все.

Я пытаюсь заменить генерацию сценария компоновщика некоторыми уже доступными инструментами.

Шаг # 1 должен быть возможен благодаря созданию независимого от позиции исполняемого файла (мне все еще нужно исследоватьthis).

Шаг № 2 возможен через GNU objcopy .

Для шага № 3 у меня пока нет возможных решений.Если используется GNU ld , он использует некоторый скрипт компоновщика по умолчанию, и предыдущее перемещение теряется.Если бы GNU gdb принял архивы, сгенерированные из GNU ar , проблема была бы решена (я думаю!).

Вопрос 2) Если описанный выше процесс возможен, может ли онбыть применены и к отладочной информации?

Шаг № 1 должен остаться без изменений.

Для шага № 2 я не уверен, переименовывается ли отладочная информация.

проблема с шагом № 3. остается.

Исходный вопрос следующий:

У меня есть собственное ядро ​​и одно или несколько приложений, и я хочу использовать GDB для отладки всей системы.Чтобы избежать любых конфликтов имен во время связывания, я использую objcopy для переименования всех разделов и имен символов (начальные адреса приложений жестко запрограммированы в ядре).Тем не менее, отладочная информация жестко запрограммирована в этих разделах .debug. * И не переименовывается.

Есть ли способ переименовать отладочную информацию?И после этого объединить эту информацию с другим набором уже существующей отладочной информации?

Я искал руководство GCC, чтобы выяснить, могу ли я найти опцию префикса (например, глобального пространства имен) ко всем символам во время компиляции, ноЯ не нашел ни одного.

Я предполагаю, что существует формат отладки, который отображает информацию в таблице символов объектов (которую можно переименовать).

1 Ответ

0 голосов
/ 27 января 2012

Ответ на вопрос 1)

Шаг № 1 должен быть возможен благодаря созданию независимого от позиции исполняемого файла (мне еще предстоит изучить это).

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

Для шага № 3 у меня пока нет возможных решений.Если используется GNU ld, он использует некоторый скрипт компоновщика по умолчанию, и предыдущее перемещение теряется.Если бы GNU gdb принимал архивы, сгенерированные из GNU, то проблема была бы решена (я думаю!).

Кажется, что нет никакого обходного пути.Таким образом, скрипт компоновщика является обязательным.

Ответ на вопрос 2)

Для шага № 2 я не уверен, переименована ли отладочная информация.

На самом деле отладочная информация не переименовывается.Вы можете использовать objdump -s и проверить, что информация об отладке встроена в эти .debug. * секции.

Обходной путь)

Даже без отладкиинформацию вы можете использовать таблицу символов объектного файла для установки точек останова.Однако вместо b main вы должны использовать b * main , поскольку символы в symtable интерпретируются как адрес.Это немного, но это, безусловно, помогает.

...