怎样才能计算出核心节点的预期大小?
我有一个来自arm64目标的截断核心文件(Coredump)。我可以从gdb-multiarch的输出中找到核心文件(Coredump)的预期大小。
BFD: warning: /home/.../core-m is truncated: expected core file size >= 748728320, found: 518127616从上面,我可以找到一个核心泵的预期大小是748728320,它的实际大小是518127616。
现在,我想知道gdb-multiarch是如何计算核心节点的预期大小的。
我可以使用readelf -e找到每个部分的大小,我认为每个部分的大小之和与一个核心文件的预期大小是相同的。所以我得到了和,但是它并不等于核的预期大小。
the sum: 748680864
expected size by `gdb-multiarch`: 748728320我怎么才能正确地计算这个呢?
更新
我只是想知道,我可以从readelf -e的输出中找到一个核的预期大小。readelf -e显示每个段的偏移量和大小。我从截短的核心箱中得到了结果。
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可用时,才能使用此方法。我仍然无法解释如何计算转储的预期大小。我希望有人能给我解释。
发布于 2019-03-26 15:01:38
我使用了下面的脚本,似乎运行得很好。正如注释所解释的,我们只是在文件中找到最大的加载部分结束偏移量。(请注意,它解释了稀疏文件。)
如果我没记错的话,我从GDB的核心文件加载代码(或类似的警告核心文件截断的标准工具)中删除了该技术。
#!/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
fihttps://stackoverflow.com/questions/55342197
复制相似问题