Конечно есть. В цикле вызываются функции pthread_* сторонней библиотеке. Компилятор не знает что они делают, а значит должен предполагать что любая переменная (ну, кроме тех, на которые заведомо никто не может иметь ссылки) может быть еми изменена.
На последних кадрах видна плата крупным планом, и надпись QH-09BCE. Гугл говорит что это плата от китайского беспроводного дверного звонка. Есть у меня подозрение, что реагирует она не на мобильник, а на кнопку от этого самого звонка в кармане изобретателя.
в своем коде — переменные на стеке и статически аллоцированные. для общения с системой — open()/read()/write() и другие API которые заведомо не используют динамическую память
fopen, насколько я помню, работает с динамической памятью. Я бы не стал такое использовать в обработчике SIGSEGV — ведь сам краш мог произойти из-за расстрела или нехватки памяти.
А может это в инструкции было? Например в линуксе ядро не сохраняет fpu контекст, и код ядра должен оборачивать вычисления с плавающей точкой в kernel_fpu_begin()/kernel_fpu_end().
Добавлю ещё, что засчёт использования PIC-кода, код одной и той же библиотеки будет загружен в память только в одном экземпляре для всех её пользователей (название «shared library» как раз отсюда). Так как PIC-код не требует релокаций, для процесса не будет создаваться индивидуальных экземпляров страниц, они будут пользоваться одними и теми же. Свои копии будут только для относительно небольших секций GOT и PLT. Ради этого, собственно, все эти пляски с -fPIC и затеяны.
И поэтому же, кстати, адреса загрузки секций, как и их физические адреса в файле всегда выровнены на границу страницы.
В винде, кажется, пошли другим путем — там одна библиотека будет всем потребителям загружена на одни и те же виртуальные адреса.
И поэтому же, кстати, адреса загрузки секций, как и их физические адреса в файле всегда выровнены на границу страницы.
В винде, кажется, пошли другим путем — там одна библиотека будет всем потребителям загружена на одни и те же виртуальные адреса.
В случае libc это будут _start и __libc_start_main
Платформенно-зависимая _start:
x86_64
i386
и т.п. для других платформ
и независимая часть в __libc_start_main:
libc-start.c
Возможно и gdb покажет больше с отладочной версией libc