Hi All,
Sorry Laszlo for flooding your mailbox, I missed the 'reply to all' so
I redo the post here.
And I added some more comment at the end to answer your questions.
Phi
==========================================================
CU82$ /usr/bin/readelf -a vmcore
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: CORE (Core file)
Machine: ARM
Version: 0x1
Entry point address: 0x0
Start of program headers: 52 (bytes into file)
Start of section headers: 0 (bytes into file)
Flags: 0x0
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 2
Size of section headers: 0 (bytes)
Number of section headers: 0
Section header string table index: 0
There are no sections in this file.
There are no sections to group in this file.
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
NOTE 0x000074 0x00000000 0x00000000 0x000a0 0x000a0 0
LOAD 0x000114 0x60000000 0x60000000 0x40000000 0x40000000 0
There is no dynamic section in this file.
There are no relocations in this file.
No version information found in this file.
Notes at offset 0x00000074 with length 0x000000a0:
Owner Data size Description
CORE 0x0000008c NT_PRSTATUS (prstatus structure)
========================================================
The Align fot the PT_LOAD is ZERO, then the offset is 0x114, having an
Align set to TARGET_PAGE_BITS, (or at least 4Kb) would provide a
chance for any debugger to do page align copy (either lseek/read, or
mmap) as they trip on the core, marginal detail, but may help.
As an example, a userland main(){abort();} kind of prog would produce
a core file like this.
CM01$ readelf -a core.2000
...
LOAD off 0x0000000000001000 vaddr 0x0000000000400000 paddr
0x0000000000000000 align 2**12
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
NOTE 0x0001d4 0x00000000 0x00000000 0x001d8 0x00000 0
LOAD 0x001000 0x00a42000 0x00000000 0x00000 0x1b000 R E 0x1000
LOAD 0x002000 0x00a5e000 0x00000000 0x01000 0x01000 RW 0x1000
The align for LOAD's is 0x1000 thus the file offset is 0x01000, 0x2000 etc...
==========================================================
I guess dump-guest-memory is of a marginal use, yet it can be usefull
when kexec/kdump is broken or non existant on some new architecture
(os/arch bring up).
So to answer your question, the content of the PT_LOAD is ok, only its
offset is non aligned.
I got to precise I obtained this vmcore by implementing the arc_arm
part of the qemu dump-guest-memory, and planing to do the same for
arm64, I may have mis-used the QEMU API's, but for what I can read,
the align member is left non initialised after a memset(zero) of the
phdr/shdr i.e it is left at zero, and I got the impression that the
wayt the elf is produced, section/progs alignment was not in mind. So
I guess other arch are not aligned either, I did not test that.
Cheers,
Phi
