How to calculate expected core file size - c++

Question

How can I calculate the expected size of a coredump?
I have a truncated core file(coredump) from arm64 target. And I can find expected size of a core file(coredump), from output of gdb-multiarch.
BFD: warning: /home/.../core-m is truncated: expected core file size >= 748728320, found: 518127616
From above, I can find expected size of a coredump is 748728320 and its actual size is 518127616.
Now, I wonder how gdb-multiarch calculates the expected size of a coredump.
I can find size of each section, using readelf -e and I thought the sum of each section's size will be same with expected size of a core file. So I get the sum, but it is not equal to expected size of the coredump.
the sum: 748680864
expected size by `gdb-multiarch`: 748728320
How can I calculate this, correctly?
UPDATE
I've just got to know I can find the expected size of a coredump, from output of readelf -e. readelf -e shows offset and size of each segment. I got the result from my truncated 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
From above, I can find offset and size of last segment. Offset is 0x2c831000, and size if 0x1da000. And expected size of dump will be 0x2c831000 + 0x1da000 = 0x2CA0B000(748728320). This is same with one from gdb-multiarch.
This approach can be used only if readelf is available. And I can't explain how the expected size of dump is calculated, still. I hope someone give me the explanation.

Answer 1

I use the following script, seems to work quite well. As the comment explains, we simply find the largest LOAD section end offset in the file. (Note that it accounts for sparse files.)
If I remember correctly, I lifted the technique from GDB's corefile loading code (or some similar standard tool that warns about corefile truncation).
#!/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