Глобально переопределите malloc в Visual C++

Вы можете использовать Detours от Microsoft (платите за коммерческие услуги) или переписать таблицы импорта для используемых вами dll.

Следующее верно для Linux, но может быть применимо и к Visual C ++ Win.

1. Функция Malloc предоставляется системной библиотекой glibc. Исполняемый файл по умолчанию связан с ним.

2. Когда программа запускается, динамический загрузчик замечает, что исполняемый файл нуждается в функции malloc, и ищет первую библиотеку, которая ее предоставляет.

3. Поскольку glibc (по умолчанию) является последней в В этом списке найденная библиотека может не быть glibc.

Если вы не связали glibc статически с исполняемым файлом, очевидным решением будет связать исполняемый файл с библиотекой, которая предоставляет ваш собственный malloc,

К сожалению, я недостаточно знаю о компоновщике Microsoft . Но ld имеет '--wrap', который вы можете использовать для чего-нибудь вроде malloc, free или чего-нибудь еще (я делаю это).

все вызовы malloc будут перенаправлены на функцию с именем __wrap_malloc, которую вы реализовали, вы можете затем вызовите real malloc с помощью __real_malloc. Это дает то преимущество, что также фиксируются любые маллоки, используемые во внешних библиотеках. Я уверен, что компоновщик Microsoft может иметь аналогичную функцию.

Эти файлы .obj можно удалить с помощью lib.exe из библиотеки lib. Я не могу быть более конкретным, но я помню, как делал это, когда собирал Chromium из исходников.

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

На стороне Windows мы отменяем вызовы malloc, но затем используем / FORCE: MULTIPLE для решения ошибки компоновщика. Он работает, вызываются функции памяти и все отслеживается, но это похоже на взлом.

Из MSDN:

Файл, созданный с помощью этой опции, может не работать должным образом. Компоновщик не будет устанавливать инкрементное связывание, если указан параметр / FORCE.

Это не только похоже на взлом, он убивает редактирование и продолжение процесса.

Параметр / FORCE: MULTIPLE может решить твои проблемы, но я

Удалите все файлы .obj, содержащие функции управления памятью, из среды выполнения. библиотеки с помощью инструмента LIB, затем используйте параметр «Игнорировать библиотеки по умолчанию» в среде IDE и вместо этого вручную укажите «свою» библиотеку времени выполнения. Затем скомпилируйте; вы должны получить несколько ошибок компоновщика о undefined malloc и free и так далее. Вот где вы входите!

(Вы, вероятно, также захотите сделать что-то похожее на библиотеки C ++, если будете их использовать, хотя я думаю, что по умолчанию оператор new вызывает malloc , так что, возможно, вам стоит сразу уйти. )

Установка Visual Studio поставляется с исходным кодом среды выполнения (см. vc / crt / src в папке установки Visual Studio), поэтому найти полный набор функций управления памятью довольно просто. У меня нет точных данных (предыдущий работодатель ...), но, насколько я помню, на разбор потребовалось всего полдня, хотя функций распределения памяти было гораздо больше, чем я ожидал.

Решение, которое я использовал, - это перестроить библиотеку времени выполнения Visual C ++ C (crt) из исходного кода.

Его можно найти здесь, в этой папке:

C: \ Program Files \ Microsoft Visual Studio 9.0 \ VC \ crt

Убедитесь, что вы запустили командную строку Visual Studio, чтобы создать его. Запуска nmake достаточно, чтобы начать сборку, хотя вы можете решить, какую цель собирать, а это значит, что вам нужно понять make-файл.

Может потребоваться усилие, чтобы понять, как построить crt, но как только вы его построите, вы можете добавить свой собственный код в malloc, free, realloc и т. Д.

К сожалению, я слышал слух, что мы победили ' t иметь возможность собрать crt из исходного кода, начиная с Visual Studio 2010.