Hi Martin,
Thanks for your answer! I had 7 PT_LOAD segments -- each of which are being shown above in my formatted readelf output. All of the 7 PT_LOAD segments had a virtual address of 0 and some 4 KB aligned physical address.
Anyway I will try to ask the same query in the QEMU mailing list.
On Wed, Aug 2, 2017 at 7:55 AM, Martin Kletzander <mkletzan@xxxxxxxxxx> wrote:
On Tue, Aug 01, 2017 at 10:22:43PM -0400, Arnabjyoti Kalita wrote:
Hello,
I was trying to understand the ELF file generated by the virsh dump
(--memory-only) command. I have successfully generated a dump of the VM
memory using this command.
You are running a QEMU machine and the dump is generated by qemu, so
they would be able to explain to much further detail, I'm sure. Anyway,
here goes my try.
I specifically am trying to understand the loadable segments of this ELF
file.
I ran readelf -a <filename> to get the information that I need. Below shows
the details of the loadable segments in a much better format :-
Loading ELF header #1. offset: 1320 filesize: 655360 memsize: 655360 vaddr:
0 paddr: 0 align: 0 flags: 0
Loading ELF header #2. offset: 656680 filesize: 65536 memsize: 65536 vaddr:
0 paddr: a0000 align: 0 flags: 0
Loading ELF header #3. offset: 722216 filesize: 1072955392 memsize:
1072955392 vaddr: 0 paddr: c0000 align: 0 flags: 0
Loading ELF header #4. offset: 1073677608 filesize: 67108864 memsize:
67108864 vaddr: 0 paddr: f4000000 align: 0 flags: 0
Loading ELF header #5. offset: 1140786472 filesize: 67108864 memsize:
67108864 vaddr: 0 paddr: f8000000 align: 0 flags: 0
Loading ELF header #6. offset: 1207895336 filesize: 8192 memsize: 8192
vaddr: 0 paddr: fc054000 align: 0 flags: 0
Loading ELF header #7. offset: 1207903528 filesize: 262144 memsize: 262144
vaddr: 0 paddr: fffc0000 align: 0 flags: 0
Just to be clear, this is the memory of the machine with kernel and
several other things loaded. I'm not sure what are all the segments,
but since the dump acts as something you can use to debug the guest OS
using the crash utility, which is somehow enhanced gdb for this purpose,
IIRC, then I guess it's the MMU mapping of everything in the guest OS.
I wanted to know why in this case, is the virtual address (denoted by
vaddr) 0 for each of the loadable segments ? Will it be okay if I load the
elf file taking the values of physical address (denoted by paddr) into
account ?
My guess is that those are the addresses from the MMU. Each segment has
it's own vaddr <-> paddr mapping.
Specifically after loading the file, can I be certain that all of my
contents will have been loaded into memory address starting from 0 ? Will
the loaded contents be present in the exact location as specified (by
paddr) here ?
It depends on what you mean by loading. You wouldn't be starting that
binary as any other program, it's rather a dump as you would have with a
coredump. Physical address is probably just the location in the guest
machine, so the thing with paddr 0 would be seabios or something
BIOS-related, etc.
If you want precise answers and not guesses, I would suggest the qemu
mailing list or any other related list. libvirt is not the best choice
here unless someone from the other communities replies here.
HTH,
Martin
Thanks and Regards.
Arnab
_______________________________________________
libvirt-users mailing list
libvirt-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvirt-users
_______________________________________________ libvirt-users mailing list libvirt-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvirt-users
