lkml.org 
[lkml]   [2004]   [Mar]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [Kgdb-bugreport] [PATCH][2/3] Update CVS KGDB's have kgdb_{schedule,process}_breakpoint
Amit S. Kale wrote:
> On Wednesday 03 Mar 2004 2:49 am, George Anzinger wrote:
>
>>Amit S. Kale wrote:
>>
>>>On Friday 27 Feb 2004 4:49 am, George Anzinger wrote:
>>>
>>>>Amit S. Kale wrote:
>>>>
>>>>>On Thursday 26 Feb 2004 3:13 am, Tom Rini wrote:
>>>>>
>>>>>>The following adds, and then makes use of kgdb_process_breakpoint /
>>>>>>kgdb_schedule_breakpoint. Using it i kgdb_8250.c isn't strictly
>>>>>>needed, but it isn't wrong either.
>>>>>
>>>>>That makes 8250 response it a _bit_ slower. A user will notice when kgdb
>>>>>doesn't respond within a millisecond of pressing Ctrl+C :-)
>>>>
>>>>Hm... I have been wondering if it might not be a good idea to put some
>>>>comments to the user at or around the breakpoint. Possibly we might want
>>>>to tell the user about where the info files are or some such. This would
>>>>then come up on his screen when the source code at the breakpoint is
>>>>displayed.
>>>
>>>Err, well, I don't seem to understand this.
>>>
>>>Do you mean we print a (gdb) console message that indicates something
>>>about a breakpoint? If we do that, there has to be a way to turn it off.
>>>I have a (rather bad) habit of stepping through kernel code :-)
>>
>>No that is not what I mean. I don't want to try to send messages to the
>>gdb console (it is not supported by gdb at this time). Rather, the hard
>>coded breakpoint instruction that we use to get to the the stub when the
>>user enters a ^C is in a particular bit of source code. Most gdb front
>>ends display this bit of source centered on the breakpoint instruction.
>>What I am asking about is puting something useful here from the user point
>>of view. For example we might have this:
>>
>>/*
>> * This is the KGDB control C break point. For additional info on KGDB
>>options * and suggested macros see .../Documentation/kgdb/* in your kernel
>>tree. * KGDB version XX.YY
>> */
>> BREAKPOINT;
>>
>>--------------------------------------
>
>
> This is definitely a good point.
>
> We may also report the exact location where kernel was running when Ctrl+C
> came in. We have pt_regs available in do_IRQ. We can pass that to process
> breakpoint function. The process breakpoint function can then straight call
> handle_exception passing it pt_regs instead of going through breakpoint. That
> will save some stack also.

Uh, I would think that "bt" should cover this. Why muddy the waters with other
stuff. I think the user should see exactly where he is going to go on the
continue. One really good reason for this is that this is the context any

p fun()

will run in.

~

--
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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:01    [W:0.488 / U:0.256 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site