Почему у моих основных дампов отсутствует примечание NT_FILE?

Я установил «ulimit -c unlimited» в моей системе Fedora, поэтому segfaults генерируют файлы дампа ядра. Это работает.Почему у моих основных дампов отсутствует примечание NT_FILE?

Я видел NT_FILE записку, упомянутый в этих URL-адресов:

ELF core file format

Anatomy of an ELF core file

Но мои основные файлы только содержат эти примечания:

$ readelf --notes core.simple.11 

Notes at offset 0x000003f8 with length 0x00000558: 
    Owner  Data size Description 
    CORE  0x00000150 NT_PRSTATUS (prstatus structure) 
    CORE  0x00000088 NT_PRPSINFO (prpsinfo structure) 
    CORE  0x00000130 NT_AUXV (auxiliary vector) 
    CORE  0x00000200 NT_FPREGSET (floating point registers)

Почему существует no NT_FILE отметить? Как я могу определить различные объектные файлы, которые могут быть основаны на главном файле, а главное, на виртуальных адресах, где эти файлы были сопоставлены с основным изображением?

Без информации о сопоставлении адресов из примечания NT_FILE, я не знаю, как я могу выполнять поиск кода в информации об отладке DWARF из объектных файлов.

заголовки программ в основной файл:

$ readelf --segments core.simple.11 

Elf file type is CORE (Core file) 
Entry point 0x0 
There are 17 program headers, starting at offset 64 

Program Headers: 
    Type   Offset    VirtAddr   PhysAddr 
       FileSiz   MemSiz    Flags Align 
    NOTE   0x00000000000003f8 0x0000000000000000 0x0000000000000000 
       0x0000000000000558 0x0000000000000000   0 
    LOAD   0x0000000000001000 0x0000000000400000 0x0000000000000000 
       0x0000000000001000 0x0000000000001000 R E 1000 
    LOAD   0x0000000000002000 0x0000000000600000 0x0000000000000000 
       0x0000000000001000 0x0000000000001000 RW  1000 
    LOAD   0x0000000000003000 0x00000035fe800000 0x0000000000000000 
       0x0000000000001000 0x000000000001e000 R E 1000 
    LOAD   0x0000000000004000 0x00000035fea1d000 0x0000000000000000 
       0x0000000000001000 0x0000000000001000 R  1000 
    LOAD   0x0000000000005000 0x00000035fea1e000 0x0000000000000000 
       0x0000000000001000 0x0000000000001000 RW  1000 
    LOAD   0x0000000000006000 0x00000035fea1f000 0x0000000000000000 
       0x0000000000001000 0x0000000000001000 RW  1000 
    LOAD   0x0000000000007000 0x00000035fec00000 0x0000000000000000 
       0x0000000000001000 0x0000000000173000 R E 1000 
    LOAD   0x0000000000008000 0x00000035fed73000 0x0000000000000000 
       0x0000000000000000 0x00000000001ff000   1000 
    LOAD   0x0000000000008000 0x00000035fef72000 0x0000000000000000 
       0x0000000000004000 0x0000000000004000 R  1000 
    LOAD   0x000000000000c000 0x00000035fef76000 0x0000000000000000 
       0x0000000000001000 0x0000000000001000 RW  1000 
    LOAD   0x000000000000d000 0x00000035fef77000 0x0000000000000000 
       0x0000000000005000 0x0000000000005000 RW  1000 
    LOAD   0x0000000000012000 0x00007fc22db59000 0x0000000000000000 
       0x0000000000003000 0x0000000000003000 RW  1000 
    LOAD   0x0000000000015000 0x00007fc22db6c000 0x0000000000000000 
       0x0000000000001000 0x0000000000001000 RW  1000 
    LOAD   0x0000000000016000 0x00007fff81c40000 0x0000000000000000 
       0x0000000000016000 0x0000000000016000 RW  1000 
    LOAD   0x000000000002c000 0x00007fff81dee000 0x0000000000000000 
       0x0000000000001000 0x0000000000001000 R E 1000 
    LOAD   0x000000000002d000 0xffffffffff600000 0x0000000000000000 
       0x0000000000000000 0x0000000000001000 R E 1000

заголовков программы в исполняемый файл:

$ readelf --segments simple 

Elf file type is EXEC (Executable file) 
Entry point 0x400390 
There are 8 program headers, starting at offset 64 

Program Headers: 
    Type   Offset    VirtAddr   PhysAddr 
       FileSiz   MemSiz    Flags Align 
    PHDR   0x0000000000000040 0x0000000000400040 0x0000000000400040 
       0x00000000000001c0 0x00000000000001c0 R E 8 
    INTERP   0x0000000000000200 0x0000000000400200 0x0000000000400200 
       0x000000000000001c 0x000000000000001c R  1 
     [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2] 
    LOAD   0x0000000000000000 0x0000000000400000 0x0000000000400000 
       0x0000000000000674 0x0000000000000674 R E 200000 
    LOAD   0x0000000000000678 0x0000000000600678 0x0000000000600678 
       0x00000000000001e4 0x00000000000001f8 RW  200000 
    DYNAMIC  0x00000000000006a0 0x00000000006006a0 0x00000000006006a0 
       0x0000000000000190 0x0000000000000190 RW  8 
    NOTE   0x000000000000021c 0x000000000040021c 0x000000000040021c 
       0x0000000000000044 0x0000000000000044 R  4 
    GNU_EH_FRAME 0x00000000000005a8 0x00000000004005a8 0x00000000004005a8 
       0x000000000000002c 0x000000000000002c R  4 
    GNU_STACK  0x0000000000000000 0x0000000000000000 0x0000000000000000 
       0x0000000000000000 0x0000000000000000 RW  8 

Section to Segment mapping: 
    Segment Sections... 
    00 
    01  .interp 
    02  .interp .note.ABI-tag .note.gnu.build-id .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r .rela.dyn .rela.plt .init .plt .text .fini .rodata .eh_frame_hdr .eh_frame 
    03  .ctors .dtors .jcr .dynamic .got .got.plt .data .bss 
    04  .dynamic 
    05  .note.ABI-tag .note.gnu.build-id 
    06  .eh_frame_hdr 
    07

My Linux версия:

$ uname -a 
Linux somehost 2.6.32.23-170.fc12.x86_64 #1 SMP Mon Sep 27 17:23:59 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux

источник

2016-09-29 barryd

Заметка NT_FILE была добавлена в ядро в 2012 году, поэтому ядро, построенное в 2010 году, не будет иметь его. Можете ли вы получить новое ядро? –

Модернизировать ядро на наших производственных системах, где мне нужно, чтобы это работало, не воспринималось легко, я подозреваю. Но я полагаю, что если gdb не нуждается в примечании NT_FILE для связывания регистра rip и других кодовых адресов с записями в таблицах .eh_frame и .debug_line, тогда должен быть другой способ выработать сопоставление объектных файлов с ядром адресное пространство изображения. Мне просто нужно выяснить, что это такое. – barryd

Хотя обновление ядра для наших текущих производственных систем, вероятно, не может быть и речи, мы создаем новые производственные системы, которые, я полагаю, будут основаны на недавнем выпуске CentOS. Как только они будут доказаны, мы переместим наши операции. Поэтому мы не будем застрять с старым ядром навсегда. Просто FYI :) – barryd

Почему там нет NT_FILE заметка?

Как отметил Марк Плотник, это довольно недавнее дополнение ядра.

никоим образом не NT_FILE записки, необходимой для GDB (на самом деле, ток GDB не представляется использовать NT_FILE на всех, кроме случаев, когда писать основной файл с gcore командой).

Как я могу определить различные объектные файлы, которые могут быть основаны на основном файле и, что более важно, виртуальных адресах, где эти файлы были отображены в основной образ?

Это работает для GDB, чтобы посмотреть на PT_DYNAMIC для главного исполняемого файла в core, экстракт DT_DEBUG от той, которая затем дает ему указатель на _r_debug, который включает в себя связанный список r_map из struct link_map, с каждым узел в списке, описывающем загруженный файл ELF.

Команда (gdb) info shared покажет вам расшифрованную версию вышеуказанной информации, но вам необходимо предоставить соответствующие двоичные файлы: только core не содержит достаточной информации.

Теперь ваш вопрос не очень ясен и может быть понят несколькими различными способами.

Это может быть: «У меня есть ядро, приложение которого разбилось?» Используйте file core и надейтесь, что первых 16 символов пути достаточно.Если этого недостаточно, запуск strings core часто показывает, какое приложение оно создало. Вы также должны рассмотреть возможность установки /proc/sys/kernel/core_pattern на что-то, что включает %e или %E, поэтому вопрос будет тривиальным, чтобы ответить в будущем.

Это может быть: «У меня есть несколько версий приложения foo, и вы хотите знать, какая версия foo создала это конкретное ядро». В этом случае вы должны связывать foo с флагом-линкером -Wl,--build-id. Этот флаг создает NT_GNU_BUILD_ID примечание в двоичном формате foo. Эта заметка сохранилась strip и сохраняется в основном файле ядра. Вы можете запустить eu-unstrip -n --core /path/to/core, и что будет производить такой вывод:

eu-unstrip -n --core core 
0x400000+0x208000 [email protected] - - [exe] 
0x7ffe3f7d9000+0x1000 [email protected] . - linux-vdso.so.1 
0x7fb5b6ec3000+0x2241c8 [email protected] /lib64/ld-linux-x86-64.so.2 /usr/lib/debug/lib/x86_64-linux-gnu/ld-2.19.so ld-linux-x86-64.so.2 
0x7fb5b6afe000+0x3c42c0 [email protected] /lib/x86_64-linux-gnu/libc.so.6 /usr/lib/debug/lib/x86_64-linux-gnu/libc-2.19.so libc.so.6

С выше вывода, вы можете знать, как точно, которые были использованы ELF бинарники, и, где в памяти они были загружены.

P.S. Я просто попытался демпинг ядра от a.out построен с -Wl,--build-id=none, а выход в результате eu-unstrip все еще весьма полезно:

eu-unstrip -n --core core 
0x400000+0x202000 - - - [exe] 
0x7fff5e1a0000+0x1000 [email protected] . - linux-vdso.so.1 
0x7fbda432d000+0x2241c8 [email protected] /lib64/ld-linux-x86-64.so.2 /usr/lib/debug/lib/x86_64-linux-gnu/ld-2.19.so ld-linux-x86-64.so.2 
0x7fbda3f68000+0x3c42c0 [email protected] /lib/x86_64-linux-gnu/libc.so.6 /usr/lib/debug/lib/x86_64-linux-gnu/libc-2.19.so libc.so.6

Update:

Там нет PT_DYNAMIC заголовка программы в моем самом основном файле ,

Нет, но PT_DYNAMIC является записываемый segme nt @0x6006a0. Этот сегмент фактически записывается в (динамическим загрузчиком) и поэтому всегда сохраняется в core (как и другие измененные данные).

В вашем случае содержимое находится в PT_LOAD сегменте @0x600000 (т.е. сегмент по смещению 0x2000 в core).

источник

2016-09-30 03:57:05

«посмотрите на PT_DYNAMIC для основного исполняемого файла в ядре» - в моем основном файле нет заголовка программы PT_DYNAMIC, но вы имеете в виду, что я должен найти часть исполняемого файла, встроенного в основной файл, и проанализировать заголовки программ из этого? Я увижу о добавлении дампа заголовка программы из моего основного файла в вопрос. – barryd

@barryd Я обновил ответ. –

Могу ли я предположить, что он всегда будет загружен в vaddr, указанном в исполняемом файле? то есть. Нет ли возможности для переноса этих данных? Как я могу найти его, если еще не определил исполняемый файл? – barryd

Почему у моих основных дампов отсутствует примечание NT_FILE?

ответ

Смежные вопросы