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 <[email protected]> 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 >> [email protected] >> https://www.redhat.com/mailman/listinfo/libvirt-users >> >
_______________________________________________ libvirt-users mailing list [email protected] https://www.redhat.com/mailman/listinfo/libvirt-users
