|
Re: DIE_GPF vs. DIE_PAGE_FAULT/DIE_TRAP: msg#00138linux.ports.x86-64.general
On Wednesday 26 October 2005 17:21, Jan Beulich wrote: > Hmm, then this isn't really useful for a debugger. There ought to be a > chance to filter exceptions early (i.e. debugger accesses to non-mapped > memory or non-existing MSRs) and a chance to detect bad faults (note > that the kernel normal exception recovery mechanism may not be usable > here because for example page faults first try to service the fault > before scanning the fixup tables, but a debugger will normally not want > a page-in to happen behind its back). I thought the latter was what gets > reported as DIE_OOPS, while the former would be the filtering occasions > (and I actually took the "grossly misnamed" comment in asm/kdebug.h as > additional indication for that). All you want is a hook early in GPF, right? I guess that should be ok. I can see that it's useful on x86-64 due to the non canonical address fault resulting in GPFs mess. Just send a patch. -Andi |
|
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| Previous by Date: | Re: DIE_GPF vs. DIE_PAGE_FAULT/DIE_TRAP: 00138, Jan Beulich |
|---|---|
| Next by Date: | Re: DIE_GPF vs. DIE_PAGE_FAULT/DIE_TRAP: 00138, Jan Beulich |
| Previous by Thread: | Re: DIE_GPF vs. DIE_PAGE_FAULT/DIE_TRAPi: 00138, Jan Beulich |
| Next by Thread: | Re: DIE_GPF vs. DIE_PAGE_FAULT/DIE_TRAP: 00138, Jan Beulich |
| Indexes: | [Date] [Thread] [Top] [All Lists] |
| News | FAQ | advertise |