Re: kgdb support in vanilla 2.6.2

[George Anzinger <george@mvista.com>]

Tom Rini wrote:
> On Thu, Mar 04, 2004 at 12:54:12PM -0800, George Anzinger wrote:
> 
>>Amit S. Kale wrote:
>>
>>>On Thursday 04 Mar 2004 10:48 am, Andrew Morton wrote:
>>>
>>>
>>>>"Amit S. Kale" <amitkale@emsyssoft.com> wrote:
>>>>
>>>>
>>>>>Flashing keyboard lights is easy on x86 and x86_64 platforms.
>>>>
>>>>Please, no keyboards.  Some people want to be able to use kgdboe
>>>>to find out why machine number 324 down the corridor just died.
>>>>
>>>>How about just doing
>>>>
>>>>
>>>>char *why_i_crashed;
>>>>
>>>>
>>>>{
>>>>	...
>>>>	if (expr1)
>>>>		why_i_crashed = "hit a BUG";
>>>>	else if (expr2)
>>>>		why_i_crashed = "divide by zero";
>>>>	else ...
>>>>}
>>>>
>>>>then provide a gdb macro which prints out the string at *why_i_crashed?
>>>
>>>
>>>If we can afford to do this (in terms of actions that can be done with the 
>>>machine being unstable) we can certainly print a console message through 
>>>gdb.
>>
>>Not once you are connected to gdb.  The "O" packet can only be sent if the 
>>program (i.e. kernel) is running as far as gdb knows.  So you could preceed 
>>a connection with this, but could not used it after gdb knows the kernel is 
>>stopped.
> 
> 
> If GDB is already connected and sitting by waiting, you can send the O
> packet.  If it is not, you could delay sending the O packet until you
> know that GDB has now connected.
> 
> This isn't an unworkable idea, but it's probably better to just set
> *why_i_crashed (think work work work, oh wait, what caused this again?)
> and provide some handy macros (which we should be in the docs anyhow).

Well, I did provide a "come_from" macro, but more definition could be had...

On the subject of macros, I am being convinced by the gdb folks that the way to 
do the info threads thing is with macros.  We get almost all we want this way 
without messing with gdb or lying to it the way the -mm kgdb does.
> 

-- 
George Anzinger   george@mvista.com
High-res-timers:  http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml