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(a)redhat.com>
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(a)redhat.com
>
https://www.redhat.com/mailman/listinfo/libvirt-users
>