Альтернатива устаревшей функциональности __malloc_hook glibc

Ответ 1

После некоторых попыток мне удалось выяснить, как это сделать.

Прежде всего, в glibc, malloc определяется как слабый символ, а это означает, что он может быть перезаписан приложением или разделяемой библиотекой. Следовательно, LD_PRELOAD необязательно необходимо. Вместо этого я реализовал следующую функцию в общей библиотеке:

void*
malloc (size_t size)
{
  [ ... ]
}

который вызывается приложением вместо glibc malloc.

Теперь, чтобы быть эквивалентным функциональности __malloc_hook, осталось несколько вещей.

1.) адрес вызывающего абонента

В дополнение к исходным параметрам malloc, glibc __malloc_hook также предоставляет адрес вызывающей функции, которая на самом деле является обратным адресом, в который будет возвращаться malloc. Для достижения такой же цели мы можем использовать функцию __builtin_return_address, доступную в gcc. Я не рассматривал другие компиляторы, потому что я ограничен gcc, но если вы случайно знаете, как это сделать, переносите мне комментарий:)

Наша функция malloc теперь выглядит следующим образом:

void*
malloc (size_t size)
{
  void *caller = __builtin_return_address(0);
  [ ... ]
}

2.) доступ к glibc malloc из вашего крюка

Поскольку я ограничен glibc в своем приложении, я решил использовать __libc_malloc для доступа к исходной реализации malloc. В качестве альтернативы можно использовать dlsym(RTLD_NEXT, "malloc"), но при возможной ловушке эта функция использует calloc при первом вызове, что может привести к бесконечному циклу, ведущему к segfault.

полный крюк malloc

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

extern void *__libc_malloc(size_t size);

int malloc_hook_active = 0;

void*
malloc (size_t size)
{
  void *caller = __builtin_return_address(0);
  if (malloc_hook_active)
    return my_malloc_hook(size, caller);
  return __libc_malloc(size);
}

где my_malloc_hook выглядит следующим образом:

void*
my_malloc_hook (size_t size, void *caller)
{
  void *result;

  // deactivate hooks for logging
  malloc_hook_active = 0;

  result = malloc(size);

  // do logging
  [ ... ]

  // reactivate hooks
  malloc_hook_active = 1;

  return result;
}

Конечно, крючки для calloc, realloc и free работают аналогично.

динамическое и статическое связывание

С помощью этих функций динамическая компоновка работает из коробки. Связывание файла .so, содержащего реализацию malloc hook, будет вызвано всеми вызовами malloc из приложения, а также всеми вызовами библиотеки, которые будут маршрутизироваться через мой крючок. Однако статическая связь является проблематичной. Я еще не обернул вокруг себя полностью, но в статической привязке malloc не является слабым символом, что приводит к ошибке множественного определения во время соединения.

Если вам нужна статическая привязка по какой-либо причине, например, перевод адресов функций в сторонних библиотеках на строки кода через символы отладки, то вы можете связать эти сторонние библиотеки статически, сохраняя связь между динамиками malloc динамически, избегая проблемы с множественным определением, Я еще не нашел лучшего обходного пути для этого, если вы его знаете, не стесняйтесь оставлять мне комментарий.

Вот краткий пример:

gcc -o test test.c -lmalloc_hook_library -Wl,-Bstatic -l3rdparty -Wl,-Bdynamic

3rdparty будет связан статически, а malloc_hook_library будет динамически связываться, что приведет к ожидаемому поведению, а адреса функций в 3rdparty будут переводиться через символы отладки в test. Довольно аккуратно, да?

Conlusion

описанные выше методы описывают не-устаревший, довольно эквивалентный подход к __malloc_hook s, но с несколькими средними ограничениями:

__builtin_caller_address работает только с gcc

__libc_malloc работает только с glibc

dlsym(RTLD_NEXT, [...]) является расширением GNU в glibc

флаги компоновщика -Wl,-Bstatic и -Wl,-Bdynamic относятся к GNU binutils.

Ответ 2

Вы можете использовать LD_PRELOAD и dlsym См. "Советы для malloc и free" в http://www.slideshare.net/tetsu.koba/presentations