Re: [Kgdb-bugreport] Re: Handling a fault (due to access by us) gracefully

[Tom R. <tr...@ke...>]

On Fri, Dec 17, 2004 at 05:00:10PM -0800, George Anzinger wrote:
> Tom Rini wrote:
> >On Mon, Nov 29, 2004 at 12:18:50PM -0800, George Anzinger wrote:
> >
> >
> >>The real issue here is that there are cases where the kernel faults due 
> >>to access of memory that is "not there".  The case may be that it is 
> >>NEVER there or for some other reason (such as user space).  The clasic 
> >>case is a =*(0) or *(0)=0, which is sometimes an intended fault on some 
> >>archs (see BUG() on the ARM processor).  What is needed is a way for kgdb 
> >>to detect this and respond accordingly.  In the x86 kgdb (that was) the 
> >>trick was to reenter kgdb on the page fault, see a flag that indicated 
> >>that a fault was expected, and then change the two possible registers 
> >>that CC would use to access that memory.  This, of course, has real 
> >>problems on arch with large register sets and so the ppc kgdb used a 
> >>set_jmp, long_jmp to address the same issue.  This is a more portable 
> >>solution (assuming the existance of set/long jmp) but also needs a lot of 
> >>care in implementation to avoid long jumping over taken spin locks (or 
> >>other such constructs).
> >>
> >>IMHO, we NEED a solution for this before asking Andrew to look at it.  As 
> >>it stands, the gdb "bt" command will usually hang the kernel due to 
> >>unclean bottom of stack issues.  Even it this this fixed, kgdb MUST be 
> >>able to survive these attempted accesses.
> >
> >
> >So, I would like to figure out a good way to fix this, but I don't quite
> >see it.  As I read how this is done in your patch, there's more to it
> >than just passing a flag around.  The other half is knowing that when we
> >get back into KGDB and the execption code is a page fault and we've set
> >the may fault flag, that we figure out this is a bad access we were
> >trying to do.  But what exactly do we do?  Just return an empty packet
> >to GDB ?
> 
> An error.   Here is an example:

So here's part of the problem.  gdb-6.1 at least doesn't listen to
errors from an 'm' packet (none of an empty reply, -EINVAL (converted)
and E03).  6.0 does, and I'm looking at 6.2/6.3 now (and 6.1 to see what
it may listen to).

-- 
Tom Rini
http://gate.crashing.org/~trini/