Followups on my own message of last night.
> I had exactly the same problem with earlier versions of gdb (4.18
> if I recall), though for me the problem was invariably provoked by my
> asking "where" on a deeply nested set of stack frames. I had always
> believed that the problem stemmed from the fact that the compiler,
> when invoked with the options used to build the Linux kernel in any
> case, is under no obligation to preserve the values of its incoming
> arguments past their useful life within the called function. If the
> arguments are consumed before the next use of the register,
> they are never saved. So sooner or later, the back trace comes to
> a function for which the argument storage on the stack frame is
> uninitialized garbage.
>
> That problem should, in theory, be fixable by compiling with
> a set of options that force the arguments to be stored in the
> stack frame.
I've experimented around a bit, and so far, the only way
I can find that ensures that the argument values are preserved
all the way back down a calling chain is to use no "-O" optimisation
whatsoever. The code us huge and grotesque, but arguments
are systematically saved in the stack frame in their allotted,
caller-allocated slots. Even then I also need to compile with -g
if I want gdb (native 4.17) to be able to do a correct backtrace
even of user-mode code.
> 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.
> > Does this problem exist in native debugging?
>
> Yes, but in most cases all you get is a bogus reported argument.
Or a truncated back trace. In the worst case, you do get a gdb
crash/core dump.
> The problem is that the kgdb "agent" in the kernel is being passed
> a bogus pointer, and is dereferencing it mindlessly (and fatally).
>
> > I assume we can disable gdb to display char strings by default.
> > Does someone know how to do it?
>
> I tried fixing it with a hack to the exception handling code,
> inspired by the old Cobalt MIPS kernel code, such that the
> kgdb agent's proxy references could fail in a non-fatal manner.
> I never did get it to work. It probably would be easy to cripple
> gdb to not automatically dereference pointer arguments, perhaps
> only in remote mode and perhaps only if some magic flag is set.
> But it *is* nice to see the string arguments when they are sane.
> A cleaner approach might be to have the proxy use a high level
> VM routine to check the validity of each address before
> dereferencing, but it's not clear that it's actually safe to invoke
> such routines from the level at which the kgdb proxy is executing.
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!).
Regards,
Kevin K.
