> "Kevin D. Kissell" wrote:
> >
> > > Yours may well be slightly different, but fatal for the same reason.
> >
> > Indeed, I wonder if your gdb isn't looking on the stack frame
> > for an argument that isn't there - and which may never be
> > there - and finding the value that also happens to be in s4.
> >
>
> I think I figured out the reason. If you take a look of the code segment
I
> attached in my first posting, you will see that s4 register indeed holds
the
> value of a1, and presummably remains so for the rest of the function.
> However, the actual assignment of a1 to s4 does not happen until a couple
of
> instructions later into the function. So if the breakpoint is set at the
> first instruction of the function, gdb would still think (wrongly) s4
holds
> the 2nd argument and, even worse, try to dereference it if it is a char*
> pointer.
It's not unusual to need to step one line to "see" arguments
correctly. A pity about the pointer dereference. ;-)
> > Another reason to fix things in the gdb proxy/exception code
> > rather than cripple gdb backtrace is that, even with the backtrace
> > fixed, the current kgdb situation is such that the slightest typo
> > at the debugger operator interface can generate a bad address
> > and blow the system sky high. It's happened to me on more than
> > one occasion. Fortunately, what I was debugging at the time
> > was readily reproduceable (if not, I would have fixed the kgdb
> > problem then and there!).
> >
>
> This sounds pretty cool, but I don't see a clean algorithm. So in the
> exception code you would decide not to crash if 1)kgdb is configured, and
2)
> the exception is caused by kgdb code (how?). Also if you decide not to
crash,
> what should be reasonable return values?
There are a number of possible ways of going about it. One is
to set some kind of flag during the kgdb proxy access, which
is tested by the page fault code. That's the stuff that's derived
from Cobalt code and that is partly in place in some existing
kernel gdb support ("debugmem_got_flt", etc.). I have not seen
it work correcly, and isn't SMP safe. Another scheme, which is
actually a bit cleaner, would be to check explicitly for the faulting
address to be that of the kgdb proxy load. In any case, once the
case has been identified, one tweaks the EPC value to return to
something other than a repeat of the bad dereference, and returns
zero or an error value to gdb - the protocol and message formats
are described in comments in gdb-stub.c.
> Disable automatic char * dereferencing is not that bad. You always have
the
> option to manually dereference it. However, I could not find such an
option.
> Maybe gdb does not provide that yet.
And even if it did, accidentally trying to dump "0x8021f34" would
blow you out of the water. It's the kernel proxy code that really needs
to be fixed.
Kevin K.
