Hi. 2006/11/27 10:58:21 -0500, Dave Anderson <[EMAIL PROTECTED]> wrote: >If the diskdump is *not* compressed, diskdump creates an ELF >vmcore that is indistinguishable from a netdump ELF vmcore -- which >does not create a zero-filled page as done above. > >Anyway, it sounds like you have run into the same issue. No, this issue is not same. This issue is that the crash utility can not read the difference from p_filesz to p_memsz.
makedumpfile modifies the ELF header so that the excluded pages are represented by the difference from p_filesz to p_memsz like the bss section. gdb can read this area as zero pages, but the crash utility can not read it. As the result, if makedumpfile changes necessary zero pages into the difference from p_filesz to p_memsz, the crash utility can not read them. When diskdump creates the ELF dumpfile, the excluded pages are holes by lseek(). This way, the crash utility can read the excluded pages as zero pages and the file size is reduced on local disk. But if the dumpfile is transported, the dumpfile size swells to the original (memory size). To transport the dumpfile easily, makedumpfile creates the ELF dumpfile by modifying the ELF header (the excluded pages are represented by the bss segments). This discussion is the following site: http://lists.osdl.org/pipermail/fastboot/2006-February/002520.html >So it would be very helpful to explain exactly what types of >page(s) are not being saved, and exactly where in the crash >utility the fatal error occurs. > >Preferably we should make crash be able to handle it >if possible, rather than stating "please do not select the >ELF dumpfile format". I think that the crash utility should be able to read the difference from p_filesz to p_memsz as zero pages, and I created the attached patch for it. What do you think this patch? Example of excluding zero pages: makedumpfile created the ELF dumpfile with excluding zero pages. * Result of "readelf -a" The zero pages of some LOAD segments are excluded, and the LOAD segments are separated. The excluded pages are: 0xffff81000072d000 - 0xffff810001000000 0xffff81000ad05000 - 0xffff81000ed05000 0xffff81000ed6f000 - 0xffff810037e6e000 0xffff810037ff0000 - 0xffff8100cff60000 0xffff8100cff69000 - 0xffff8100cff70000 0xffff810100000000 - 0xffff810129c00000 0xffff810129c46000 - 0xffff81012a000000 0xffff8101659b9000 - 0xffff810165b6c000 0xffff81016ff00000 - 0xffff810170000000 - vmcore Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align NOTE 0x0000000000000190 0x0000000000000000 0x0000000000000000 0x0000000000000590 0x0000000000000590 0 LOAD 0x0000000000000720 0xffffffff80000000 0x0000000000200000 0x000000000052d000 0x000000000052d000 RWE 0 LOAD 0x000000000052d720 0xffff810000000000 0x0000000000000000 0x00000000000a0000 0x00000000000a0000 RWE 0 LOAD 0x00000000005cd720 0xffff810000100000 0x0000000000100000 0x0000000000f00000 0x0000000000f00000 RWE 0 LOAD 0x00000000014cd720 0xffff810005000000 0x0000000005000000 0x00000000caf70000 0x00000000caf70000 RWE 0 LOAD 0x00000000cc43d720 0xffff810100000000 0x0000000100000000 0x0000000070000000 0x0000000070000000 RWE 0 - The ELF dumpfile(excluding zero pages) Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align NOTE 0x00000000000002e0 0x0000000000000000 0x0000000000000000 0x0000000000000590 0x0000000000000590 0 LOAD 0x0000000000000870 0xffffffff80000000 0x0000000000200000 0x000000000052d000 0x000000000052d000 RWE 0 LOAD 0x000000000052d870 0xffff810000000000 0x0000000000000000 0x000000000009f000 0x00000000000a0000 RWE 0 LOAD 0x00000000005cc870 0xffff810000100000 0x0000000000100000 0x000000000062d000 0x0000000000f00000 RWE 0 LOAD 0x0000000000bf9870 0xffff810005000000 0x0000000005000000 0x0000000005d05000 0x0000000009d05000 RWE 0 LOAD 0x00000000068fe870 0xffff81000ed05000 0x000000000ed05000 0x000000000006a000 0x0000000029169000 RWE 0 LOAD 0x0000000006968870 0xffff810037e6e000 0x0000000037e6e000 0x0000000000182000 0x00000000980f2000 RWE 0 LOAD 0x0000000006aea870 0xffff8100cff60000 0x00000000cff60000 0x0000000000009000 0x0000000000010000 RWE 0 LOAD 0x0000000006af3870 0xffff810100000000 0x0000000100000000 0x0000000000000000 0x0000000029c00000 RWE 0 LOAD 0x0000000006af3870 0xffff810129c00000 0x0000000129c00000 0x0000000000046000 0x0000000000400000 RWE 0 LOAD 0x0000000006b39870 0xffff81012a000000 0x000000012a000000 0x000000003b9b9000 0x000000003bb6c000 RWE 0 LOAD 0x00000000424f2870 0xffff810165b6c000 0x0000000165b6c000 0x000000000a394000 0x000000000a494000 RWE 0 * Result of gdb/crash gdb can read the excluded page of virtual-address 0xffff81000072d000, but the crash utility can not read this page. - vmcore (gdb) x/8 0xffff81000072d000 0xffff81000072d000: 0x00000000 0x00000000 0x00000000 0x00000000 0xffff81000072d010: 0x00000000 0x00000000 0x00000000 0x00000000 (gdb) crash> rd 0xffff81000072d000 4 ffff81000072d000: 0000000000000000 0000000000000000 ................ ffff81000072d010: 0000000000000000 0000000000000000 ................ crash> - The ELF dumpfile(excluding zero pages) (gdb) x/8 0xffff81000072d000 0xffff81000072d000: 0x00000000 0x00000000 0x00000000 0x00000000 0xffff81000072d010: 0x00000000 0x00000000 0x00000000 0x00000000 (gdb) crash> rd 0xffff81000072d000 4 rd: read error: kernel virtual address: ffff81000072d000 type: "64-bit KVADDR" crash> the crash utility with attached patch: crash> rd 0xffff81000072d000 4 ffff81000072d000: 0000000000000000 0000000000000000 ................ ffff81000072d010: 0000000000000000 0000000000000000 ................ crash> Thanks Ken'ichi Ohmichi
crash-read_bss_segment.patch
Description: Binary data
_______________________________________________ fastboot mailing list [email protected] https://lists.osdl.org/mailman/listinfo/fastboot
