On Tue, Mar 13, 2007 at 03:04:46PM -0600, Bob Montgomery wrote: > On Wed, 2007-03-07 at 10:43 +0900, Ken'ichi Ohmichi wrote: > > > I want to use the feature of excluding zero-pages, because our systems > > (x86_64) have many zero-pages immediately after system booting. > > Bob is researching for the behavior of crash on ELF format dumpfiles. > > I would like to wait for his report. > > Sorry you had to wait so long. > > Bob Montgomery > > Excellent summary Bob. > Here's what I know about how crash deals with ELF (netdump) dump files > compared to how it deals with kdump (diskdump) dump files. > > ======================================== > Intro to ELF dumpfiles and zero filling: > ======================================== > > ELF format dumpfiles do not contain a page-by-page bitmap of included > and excluded pages. Instead, a program header table describes > groups of contiguous pages that are present in the dumpfile. In its > simplest form, this allows a debugger to locate groups of pages that > are present in the file, and conversely to identify pages that are > missing by failing to find a program header entry that encloses the > address of a missing page. > > At some point between the 3.4 and 3.19 versions of crash, code was > added to netdump.c:netdump_read to handle a zero_fill feature in > the ELF files. In a program header entry where p_memsz (MemSiz) is > bigger than p_filsiz (FileSiz), the zone between them is considered > to be filled with zero upon access. > The same is used for handling bss where file image does not occupy space but program image does. So it makes sense. [..] > ========================== > Philosophical Meandering > ========================== > > The zero-fill feature gives an ELF dump file *three* ways to represent > pages: > > 1) Not In The Address Space: There is no program header LOAD entry > that contains the requested address. > > 2) Not In The File, Zero Fill: A program header LOAD entry contains > the address, but the offset in the segment is between FileSiz > and MemSiz. > > 3) In The File: A program header LOAD entry contains the address, > and the offset in the segment is smaller than FileSiz. > > Unfortunately, makedumpfile recognizes *four* types of pages: > > A) Not In The Address Space: physical holes in memory, undumpable zones > B) Excluded Type: Excluded based on page type (user memory, cached page) > C) Zero Content: Excluded based on page content being all 0x0 > D) In The File > > The problem at hand is that makedumpfile's current mapping of the four > types of pages onto ELF's three types of representation puts both > "B) Excluded Type" and "C) Zero Content" into ELF's "2) Not In The > File, Zero Fill" representation. This results in crash reporting > the contents of all addresses in excluded pages as 0x0, regardless > of their original value. > I think this is wrong. We should not be mapping excluded pages into "Not in the File, Zero Fill". I think excluded pages should just not appear in the program headers at all. Returning zero for an excluded page content is not right. > ===================================== > Can ELF Dumpfiles Solve This Problem? > ===================================== > > To achieve correctness with ELF dumpfiles, one could perhaps remap the > four types of pages to the three types of ELF representations so that > "A) Not In The Address Space" and "B) Excluded Type" were both mapped > to "1) Not In The Address Space". Then "C) Zero Content" would map > to "2) Not In The File, Zero Fill". You would lose the ability to > know if a page were missing because it was never in the address space > in the first place, or because it was excluded because of its type. > But if you read a zero, you'd know it really was a zero. > I think this is the way to go. Why would I like to know if a page was never present or mkdumpfile filtered it out? I think we can live with that and lets just not create any sort of mapping for excluded pages in finally generated ELF headers. Thanks Vivek -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility