如何计算核心转储的预期大小?
我有一个来自arm64目标的截断的核心文件(coredump)。而且我可以从gdb-multiarch
的输出中找到核心文件(coredump)的预期大小。
BFD: warning: /home/.../core-m is truncated: expected core file size >= 748728320, found: 518127616
从上面,我可以找到一个coredump的预期大小为748728320,其实际大小为518127616。
现在,我不知道gdb-multiarch
如何计算核心转储的预期大小。
我可以使用readelf -e
找到每个部分的大小,并且我认为每个部分的大小总和将与核心文件的预期大小相同。所以我得到了总和,但它不等于核心转储的预期大小。
the sum: 748680864
expected size by `gdb-multiarch`: 748728320
我该如何正确计算?
更新
我刚刚知道我可以从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
可用时,才可以使用此方法。而且,我仍然无法解释转储的预期大小是如何计算的。我希望有人给我解释。
答案 0 :(得分:1)
我使用以下脚本,似乎运行良好。正如评论所解释的,我们只是在文件中找到最大的LOAD节末尾偏移量。 (请注意,它占稀疏文件。)
如果我没记错的话,我从GDB的corefile加载代码(或一些警告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