Как рассчитать ожидаемый размер файла ядра - PullRequest
Новая
       26

Как рассчитать ожидаемый размер файла ядра

0 голосов
/ 25 марта 2019

Как рассчитать ожидаемый размер coredump?

У меня есть усеченный файл core (coredump) из arm64 target. И я могу найти ожидаемый размер файла ядра (coredump), из вывода gdb-multiarch. 

BFD: warning: /home/.../core-m is truncated: expected core file size >= 748728320, found: 518127616

Сверху я могу найти ожидаемый размер coredump 748728320 и его фактический размер 518127616.

Теперь мне интересно, как gdb-multiarch вычисляет ожидаемый размер coredump.

Я могу найти размер каждого раздела, используя readelf -e, и я подумал, что сумма размера каждого раздела будет такой же, как и ожидаемый размер основного файла. Таким образом, я получаю сумму, но она не равна ожидаемому размеру coredump. 

the sum: 748680864
expected size by `gdb-multiarch`: 748728320

Как я могу правильно рассчитать это?

UPDATE

Я только что узнал, что могу найти ожидаемый размер coredump из вывода readelf -e. readelf -e показывает смещение и размер каждого сегмента. Я получил результат от моего усеченного coredump. 

Program Headers:
Type           Offset             VirtAddr           PhysAddr
               FileSiz            MemSiz              Flags  Align
NOTE           0x000000000000b2f8 0x0000000000000000 0x0000000000000000
               0x000000000002b6a0 0x0000000000000000         0x0
LOAD           0x0000000000037000 0x000000556af44000 0x0000000000000000
               0x0000000000001000 0x00000000008cc000  R E    0x1000
...
LOAD           0x000000002c831000 0x0000007fca9c5000 0x0000000000000000
               0x00000000001da000 0x00000000001da000  RW     0x1000

Сверху я могу найти смещение и размер последнего сегмента. Смещение - 0x2c831000, а размер - 0x1da000. Ожидаемый размер дампа будет 0x2c831000 + 0x1da000 = 0x2CA0B000 (748728320). То же самое с одним из gdb-multiarch.

Этот подход можно использовать только при наличии readelf. И я до сих пор не могу объяснить, как рассчитывается ожидаемый размер дампа. Я надеюсь, что кто-нибудь даст мне объяснение.

1 Ответ

1 голос
/ 26 марта 2019

Я использую следующий скрипт, кажется, работает довольно хорошо.Как поясняется в комментарии, мы просто находим наибольшее смещение конца секции LOAD в файле.(Обратите внимание, что он учитывает разреженные файлы.)

Если я правильно помню, я поднял технику из кода загрузки core-файла GDB (или некоторого аналогичного стандартного инструмента, который предупреждает об усечении corefile). 

#!/bin/bash
trap 'exit 1' ERR  # Abort script on error.

if [[ $# != 1 ]] ; then
    echo "$( basename $0 ) <coreFile>"
    exit 1
fi

coreFile=$1

# Examine all LOAD sections in the corefile, calculate the file offset of each section's end,
# and find the largest offset.
expectedSize=$( readelf -l ${coreFile} | grep -A 1 LOAD |
    while read type offset etc && read fsize etc ; do
        echo $(( $offset + $fsize ))
    done | sort -n | tail -n 1 )

actualSize=$( du --block-size=1 --apparent-size ${coreFile} | cut -f1 )

physicalSize=$( du --block-size=1 ${coreFile} | cut -f1 )

if [[ ${actualSize} < ${expectedSize} ]] ; then
    echo "Physical size ${physicalSize}"
    echo "Expected logical size ${expectedSize}"
    echo "Actual logical size ${actualSize}"
    exit 2
fi
...