#linux #signals #signal-handling
#linux #сигналы #обработка сигналов
Вопрос:
Я работаю над «Созданием регистратора данных Postmortem на платформе Linux». Ранее я также публиковал вопрос, касающийся этого проекта. Там я получил механизм потока вызовов для создания файла дампа ядра в версии RHEL: 2.6.18.128-el5.
Это следует как:
File Function called
1.source/ arch/i386/kernel/signal.c -----> do_signal( )
2.source/kernel/signal.c ----------> get_signal_to_deliver( )
3.source/fs/exec.c -------------> do_coredump( )
4.source/fs/binfmt_elf.c -------------> elf_core_dump( )
Теперь, в соответствии с требованиями проекта, мне нужно изменить определения обработчика сигналов по умолчанию с помощью моего собственного пользовательского обработчика сигналов, который обрабатывает различные исключения ( SIGSEGV , SIGFPE SIGABRT и т.д.), вызывающие coredump. Кроме того, мне нужно собрать ядро для сохранения изменений в ядре с моим обработчиком, заменяющим обработчик по умолчанию.
Кто-нибудь, пожалуйста, может поделиться процедурой выполнения этих операций?
Заранее спасибо всем репликаторам 🙂
Спасибо vlc
Комментарии:
1. Вы хотите изменить способ работы ядра или вы хотите установить обработчики сигналов в своем коде пользовательского режима?
2. да … я хочу знать, как именно ядро работает при генерации coredump. Исходя из этого, я хочу изменить обработчики по умолчанию с помощью моего собственного обработчика и собрать ядро. Таким образом, я хочу работать с этим новым ядром.
Ответ №1:
SIGFPE, SIGABRT, SIGSEGV и некоторые другие уже генерируют дамп ядра по умолчанию, см. Сигнал(7). Однако многие дистрибутивы устанавливают ограничение на размер ресурса основного файла равным 0, отключая генерацию дампа ядра. Вы можете повторно включить его с помощью:
ulimit -c unlimited
Вместо unlimited вы можете передать максимальное количество блоков файловой системы, которые должны занимать дампы ядра.