Написание эффективной функции возврата - PullRequest
Новая
       54

Написание эффективной функции возврата

0 голосов
/ 12 марта 2020

Я наткнулся на приведенный ниже код для ходьбы назад 

struct stack_frame {
  struct stack_frame *prev;
    void *return_addr;
} __attribute__((packed));
typedef struct stack_frame stack_frame;

__attribute__((noinline, noclone))
void backtrace_from_fp(void **buf, int size)
{
    int i;
    stack_frame *fp;

    __asm__("movl %%ebp, %[fp]" :  /* output */ [fp] "=r" (fp));

    for(i = 0; i < size && fp != NULL; fp = fp->prev, i++)
        buf[i] = fp->return_addr;
}

причина поиска этого кода в том, что мы используем сторонний хакер mallo c, поэтому не хотим использовать backtrace, который снова выделяет Память. Выше не работает для x86_64, и я изменил оператор asm на 

    __asm__("movl %%rbp, %[fp]" :  /* output */ [fp] "=r" (fp));

Я получаю cra sh

(gdb) bt
#0  backtrace_from_fp (size=10, buf=<optimized out>) at src/tcmalloc.cc:1910
#1  tc_malloc (size=<optimized out>) at src/tcmalloc.cc:1920
#2  0x00007f5023ade58d in __fopen_internal () from /lib64/libc.so.6
#3  0x00007f501e687956 in selinuxfs_exists () from /lib64/libselinux.so.1
#4  0x00007f501e67fc28 in init_lib () from /lib64/libselinux.so.1
#5  0x00007f5029a32503 in _dl_init_internal () from /lib64/ld-linux-x86-64.so.2
#6  0x00007f5029a241aa in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
#7  0x0000000000000001 in ?? ()
#8  0x00007fff22cb8e24 in ?? ()
#9  0x0000000000000000 in ?? ()
(gdb)
(gdb) p $rbp
$2 = (void *) 0x7f501e695f37
(gdb) p (stack_frame *)$rbp
$3 = (stack_frame *) 0x7f501e695f37
(gdb) p *$3
$4 = {prev = 0x69662f636f72702f, return_addr = 0x6d6574737973656c}
(gdb) x /1xw 0x69662f636f72702f
0x69662f636f72702f:     Cannot access memory at address 0x69662f636f72702f
(gdb) fr
#0  backtrace_from_fp (size=10, buf=<optimized out>) at src/tcmalloc.cc:1910
1910    in src/tcmalloc.cc
(gdb)

Я что-то упустил? Любая помощь о том, как я могу восстановить то же самое с помощью кода?.

1 Ответ

2 голосов
/ 13 марта 2020

Я что-то упустил?

Код, на который вы ссылались , предполагает скомпилированный код использует цепочку регистров указателя кадра.

Это был по умолчанию включено (32-разрядное) i*86 до 5-7 лет go и не используется по умолчанию для x86_64 с момента ~ навсегда.

Код, скорее всего, будет работать нормально в неоптимизированные сборки, но с треском проваливаются с оптимизацией как на 32-битных, так и на 64-битных платформах x86 с использованием не древних версий компилятора.

Если вы можете перестроить весь код ( включая libc) с -fno-omit-frame-pointer, тогда этот код будет работать большую часть времени (но не все времени, поскольку libc может иметь сборку с ручным кодированием, а эта сборка не будет иметь фрейма цепочка указателей).

Одним из решений является использование libunwind . К сожалению, использование его изнутри malloc все еще может столкнуться с проблемой , если вы (или любые библиотеки, которые вы используете) также используете dlopen.

...