1. Feature Name: crash's support for multiple PT_LOAD segments. The current crash does not support vmcore which has multiple PT_LOAD segments. 2. Description: Architectures (mark all that apply) x 32-bit x86 x 64-bit Itanium2 x 64-bit AMD64/Intel EM64T x 64-bit IBM POWER 31-bit IBM S/390 64-bit IBM zSeries Dependencies: Diskdump External links: None Priority (H,M,L): H Target Releases: RHEL4-U2 Beta Target Release Date: Drivers or hardware dependency: None Target Kernel: RHEL4-U2 Beta
Preliminary work on the crash utility has been completed and tested successfully on an ia64 vmcore (RHEL4) created with multiple PT_LOAD segments. However, in the description above, "32-bit x86" is marked with an "x", which I believe is a mistake. I have discussed this with Akira Imamura, and under the specification of ELF header, there is no standard manner in which multiple PT_LOAD segments can be created for 32-bit machines. This is because the 32-bit ELF header has 32-bit fields for the p_paddr (starting physical address of a segment), and 32-bit fields for the p_filesz and p_memsz: typedef struct { Elf32_Word p_type; /* Segment type */ Elf32_Off p_offset; /* Segment file offset */ Elf32_Addr p_vaddr; /* Segment virtual address */ Elf32_Addr p_paddr; /* Segment physical address */ Elf32_Word p_filesz; /* Segment size in file */ Elf32_Word p_memsz; /* Segment size in memory */ Elf32_Word p_flags; /* Segment flags */ Elf32_Word p_align; /* Segment alignment */ } Elf32_Phdr; That being the case, if a segment starts at a phyical address greater than 4GB, it cannot be described in the p_paddr field. Furthermore, if any segment contains greater than 4GB in memory, it cannot be defined in the p_filesz and/or p_memsz segments. For this reason, the crash utility changes that I have made to support multiple PT_LOAD segments restrict this capability to 64-bit machine types, whose Elf64_Phdr structures do not have this restriction. Please change this requirement to only support 64-bit machines. (Or explain how it can be accomplished in a 32-bit system, since it is currently impossible).
As you said, I made a mistake in the description above. I rewrite those again as follows. Architectures (mark all that apply) 32-bit x86 x 64-bit Itanium2 x 64-bit AMD64/Intel EM64T 64-bit IBM POWER 31-bit IBM S/390 64-bit IBM zSeries Regards, Akira
PM ACK for U2.
The upstream version of crash has support for multiple PT_LOAD segments, and has been tested in conjunction with the in-house Fujitsu team. It will require a crash utility package errata for RHEL4-U2. I would suggest that the easiest test plan would be for the Fujitsu team to create and provide x86_64 and ia64 vmcore files that have multiple PT_LOAD segments (with their associated debuginfo kernels) for testing purposes.
Created attachment 115785 [details] RHEL4-U2 test plan by Fujitsu
Our test plan is here: Arch Subtotal i386 27 ia64 24 x86_64 22 Total 73 The above plan is summary of the test plan which was attached. Please see the attachment if you need further information. We believe that crash can be verified by this test plan.
This fix has been available in the upstream version of crash since 4/26/05, and is required for the RHEL4-U2 version of diskdumputils. See errata: RHBA-2005:578 (RHEL4-U2) diskdumputils enhancement update I would like to get the errata procedure underway for this FZ ASAP.
Can I get pm_ack and qa_ack on this one please?
The component of this bugzilla was incorrectly set to "kernel". I have changed it to "crash", because it belongs to the user-space crash utility.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHEA-2005-600.html