On 2012-03-09 10:57, Wen Congyang wrote: > At 03/09/2012 05:41 PM, Jan Kiszka Wrote: >> On 2012-03-09 03:53, HATAYAMA Daisuke wrote: >>> From: Wen Congyang <we...@cn.fujitsu.com> >>> Subject: Re: [RFC][PATCH 05/16 v8] Add API to get memory mapping >>> Date: Fri, 09 Mar 2012 10:26:56 +0800 >>> >>>> At 03/09/2012 10:05 AM, HATAYAMA Daisuke Wrote: >>>>> From: Wen Congyang <we...@cn.fujitsu.com> >>>>> Subject: Re: [RFC][PATCH 05/16 v8] Add API to get memory mapping >>>>> Date: Fri, 09 Mar 2012 09:46:31 +0800 >>>>> >>>>>> At 03/09/2012 08:40 AM, HATAYAMA Daisuke Wrote: >>>>>>> From: Wen Congyang <we...@cn.fujitsu.com> >>>>>>> Subject: Re: [RFC][PATCH 05/16 v8] Add API to get memory mapping >>>>>>> Date: Thu, 08 Mar 2012 16:52:29 +0800 >>>>>>> >>>>>>>> At 03/07/2012 11:27 PM, HATAYAMA Daisuke Wrote: >>>>>>>>> From: Wen Congyang <we...@cn.fujitsu.com> >>>>>>>>> Subject: [RFC][PATCH 05/16 v8] Add API to get memory mapping >>>>>>>>> Date: Fri, 02 Mar 2012 18:18:23 +0800 >>>>>>>>> >>>>>>>>> >>>>> >>>>>>>>> How does the memory portion referenced by PT_LOAD program headers with >>>>>>>>> p_vaddr == 0 looks through gdb? If we cannot access such portions, >>>>>>>>> part not referenced by the page table CR3 has is unnecessary, isn't >>>>>>>>> it? >>>>>>>> >>>>>>>> The part is unnecessary if you use gdb. But it is necessary if you use >>>>>>>> crash. >>>>>>>> >>>>>>> >>>>>>> crash users would not use paging option because even if without using >>>>>>> it, we can see all memory well, so the paging option is only for gdb >>>>>>> users. >>>>>> >>>>>> Yes, the paging option is only for gdb users. The default value if off. >>>>>> >>>>>>> >>>>>>> It looks to me that the latter part only complicates the logic. If >>>>>>> instead, collecting virtual addresses only, way of handling PT_LOAD >>>>>>> entries become simpler, for example, they no longer need to be >>>>>>> physically contiguous in a single entry, and reviewing and maintaince >>>>>>> becomes easy. >>>>>> >>>>>> Sorry, I donot understand what do you want to say. >>>>>> >>>>> >>>>> The processing that adds part not referenced by page table to vmcore >>>>> is meaningless for gdb. crash doesn't require it. So, it only >>>>> complicates the current logic. >>>> >>>> If the paging mode is on, we can also use crash to analyze the vmcore. >>>> As the comment methioned, the memory used by the 1st kernel may be not >>>> referenced by the page table, so we neet this logic. >>>> >>> >>> As I said several times, crash users don't use paging mode. Users of >>> the paging mode is gdb only just as you say. So, the paging path needs >>> to collect part referenced by page table only since the other part is >>> invisible to gdb. >> >> If crash can work both with and without paging, it should be default >> *on* to avoid writing cores that can later on only be analyzed with that >> tool. Still not sure, though, if that changes the requirement on what >> memory regions should be written in that mode. > > If this logic is not remvoed, crash can work both with and without paging. > But the default value is 'off' now, because the option is '-p'.
And this would be unfortunate if you do not want to use crash for analyzing (I'm working on gdb python scripts which will make gdb - one day - at least as powerful as crash). If paging mode has the same information that non-paging mode has, I would even suggest to drop it. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux