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