At 03/09/2012 06:05 PM, Jan Kiszka Wrote: > 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.
I donot have any knowledge about gdb python scripts. But is it OK to work without virtual address in PT_LOAD? Thanks Wen Congyang > > Jan >
