Как определить, где загружена общая библиотека в адресное пространство процесса?

Question

Я пытаюсь отлаживать общую библиотеку, к которой у меня есть исходный код и отладка символов для использования gdb.
У меня нет отладочных символов или кода для процесса, который фактически использует эту общую библиотеку (я сам ее компилирую, поэтому могу иметь все, но результирующий двоичный файл лишен, чтобы имитировать ситуацию, когда у меня нет кода).
Процесс печатает адрес целевой функции foo Я пытаюсь отлаживать, чтобы проверить, что gdb знает правильное местоположение для символов из разделяемой библиотеки. foo существует моя общая библиотека. Мой метод печати это добавляет следующую строку в двоичный файл, который использует свою библиотеку:

printf("%p\n", foo) 

... и добавить сложность, это Android системы я отладки удаленно.

Сценарий Пытаюсь следующим образом:
На цели:

root@phone:/proc/23806 # gdbserver --attach :5555 23806       
Attached; pid = 23806 
Listening on port 5555 
Remote debugging from host 127.0.0.1 

На хосте:

[build@build-machine shared]$ /home/build/shared/prebuilts/gcc/linux-x86/arm/arm-eabi-4.7/bin/arm-eabi-gdb 
GNU gdb (GDB) 7.3.1-gg2 
Copyright (C) 2011 Free Software Foundation, Inc. 
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> 
This is free software: you are free to change and redistribute it. 
There is NO WARRANTY, to the extent permitted by law. Type "show copying" 
and "show warranty" for details. 
This GDB was configured as "--host=x86_64-linux-gnu --target=arm-linux-android". 
For bug reporting instructions, please see: 
(gdb) target remote :5555 
Remote debugging using :5555 
0xb6f17fa0 in ??() 
(gdb) add-symbol-file out/target/product/armv7-a-neon/symbols/system/lib/libShared.so 
The address where out/target/product/armv7-a-neon/symbols/system/lib/libShared.so has been loaded is missing 

Теперь я знаю, что мне нужно - перемещенный .text раздел этой общей библиотеки в адресном пространстве процесса, но я понятия не имею, как его найти. Я попытался/Proc/23806/smaps:

root@phone:/proc/23806 # cat maps | grep Shared         
b6ea0000-b6edb000 r-xp 00000000 b3:10 3337  /system/lib/libShared.so 
b6edc000-b6ede000 r--p 0003b000 b3:10 3337  /system/lib/libShared.so 
b6ede000-b6edf000 rw-p 0003d000 b3:10 3337  /system/lib/libShared.so 

а также .text участок расположен в 0x0003ff00 в .so файл:

[build@build-machine shared]$ objdump -h out/target/product/armv7-a-neon/symbols/system/lib/libShared.so | grep text 
    7 .text   0002835c 00003ff0 00003ff0 00003ff0 2**3 

Так что теперь я должен иметь адрес, где моя общая библиотека находится: 0xb6ea0000 + 0x00003ff0 = 0xb6ea3ff0 (где библиотека загружена + .text смещение от начала) Так что я сделал:

(gdb) add-symbol-file out/target/product/armv7-a-neon/symbols/system/lib/libShared.so 0xb6ea3ff0 
add symbol table from file "out/target/product/armv7-a-neon/symbols/system/lib/libShared.so" at 
.text_addr = 0xb6ea3ff0 
(y or n) y 

Теперь я попытался установить контрольную точку для функции Foo из моей общей библиотеки:

(gdb) b F10 
Breakpoint 1 at 0xb6ea41de: file frameworks/native/test/shared/src/shared, line 122. 

И это не совпадает со значением из моего двоичном, который был 0xb6ea4217 (печатается на экране).

Похоже, что я не предоставил правильную ячейку памяти для общей библиотеки, но я не знаю, почему.

Любая помощь приветствуется!

Answer 1

Хорошо, поэтому, после того, как я поцарапал свою голову на этом, включил и выключил какое-то время, я наконец обнаружил, что пошло не так.

Решение возникло под другим углом, мне недавно пришлось отлаживать некоторый код, для которого у меня были частичные источники, поэтому я сделал гибридную отладку исходного кода/сборки и заметил, что при отладке источника все начинает искажаться - я не могу используйте следующую инструкцию, так как она сработает - но когда я отлаживаю инструкции, все отлично работает!

Затем я добавил и составил следующий короткий код в AOSP дерева:

int main(int argc, char** argv) 
{ 
    int first,second; 
    first=1; 
    second=2; 
    return first+second; 
} 

И, как и ожидалось, было бы не правильно отладить (сборка отладочные работы, отладка источник не делает).

Тогда я заметил, что argc был ОПТИМИЗАЦИЯ!

Итак, что действительно произошло здесь, была оптимизация компилятора, которая предотвращает отладку исходного кода, поскольку между генерируемыми инструкциями и фактическим источником не существует отношений 1: 1. Поскольку я оставил флаги сборки по умолчанию в руках скрипта сборки AOSP, я получил эти странные проблемы отладки ...

Спасибо @EmpyloyedRussian за помощь!

Answer 2

Ваш лучший выбор - запустить (gdb) x/10i 0xb6ea41de и (gdb) x/10i 0xb6ea4217.

Я предполагаю, что либо GDB, либо ваша программа печатает адрес PLT, а не реальный адрес foo.

P.S. Ваш метод вызова add-symbol-file представляется правильным.