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 :-)
What are info files?
-Amit
>
> comments...
>
> -g
>
> > OK to checkin.
> > -Amit
> >
> >># This is a BitKeeper generated patch for the following project:
> >># Project Name: Linux kernel tree
> >># This patch format is intended for GNU patch command version 2.5 or
> >>higher. # This patch includes the following deltas:
> >># ChangeSet 1.1663 -> 1.1664
> >># arch/i386/kernel/irq.c 1.48 -> 1.49
> >># drivers/net/kgdb_eth.c 1.2 -> 1.3
> >># arch/x86_64/kernel/irq.c 1.21 -> 1.22
> >># drivers/serial/kgdb_8250.c 1.3 -> 1.4
> >># kernel/kgdb.c 1.3 -> 1.4
> >># arch/ppc/kernel/irq.c 1.36 -> 1.37
> >># include/linux/kgdb.h 1.3 -> 1.4
> >>#
> >># The following is the BitKeeper ChangeSet Log
> >># --------------------------------------------
> >># 04/02/25 [email protected] 1.1664
> >># process_breakpoint/schedule_breakpoint.
> >># --------------------------------------------
> >>#
> >>diff -Nru a/arch/i386/kernel/irq.c b/arch/i386/kernel/irq.c
> >>--- a/arch/i386/kernel/irq.c Wed Feb 25 14:21:32 2004
> >>+++ b/arch/i386/kernel/irq.c Wed Feb 25 14:21:32 2004
> >>@@ -34,6 +34,7 @@
> >> #include <linux/proc_fs.h>
> >> #include <linux/seq_file.h>
> >> #include <linux/kallsyms.h>
> >>+#include <linux/kgdb.h>
> >>
> >> #include <asm/atomic.h>
> >> #include <asm/io.h>
> >>@@ -507,6 +508,8 @@
> >> spin_unlock(&desc->lock);
> >>
> >> irq_exit();
> >>+
> >>+ kgdb_process_breakpoint();
> >>
> >> return 1;
> >> }
> >>diff -Nru a/arch/ppc/kernel/irq.c b/arch/ppc/kernel/irq.c
> >>--- a/arch/ppc/kernel/irq.c Wed Feb 25 14:21:32 2004
> >>+++ b/arch/ppc/kernel/irq.c Wed Feb 25 14:21:32 2004
> >>@@ -46,6 +46,7 @@
> >> #include <linux/random.h>
> >> #include <linux/seq_file.h>
> >> #include <linux/cpumask.h>
> >>+#include <linux/kgdb.h>
> >>
> >> #include <asm/uaccess.h>
> >> #include <asm/bitops.h>
> >>@@ -536,7 +537,9 @@
> >> if (irq != -2 && first)
> >> /* That's not SMP safe ... but who cares ? */
> >> ppc_spurious_interrupts++;
> >>- irq_exit();
> >>+ irq_exit();
> >>+
> >>+ kgdb_process_breakpoint();
> >> }
> >>
> >> unsigned long probe_irq_on (void)
> >>diff -Nru a/arch/x86_64/kernel/irq.c b/arch/x86_64/kernel/irq.c
> >>--- a/arch/x86_64/kernel/irq.c Wed Feb 25 14:21:32 2004
> >>+++ b/arch/x86_64/kernel/irq.c Wed Feb 25 14:21:32 2004
> >>@@ -405,6 +405,8 @@
> >> spin_unlock(&desc->lock);
> >>
> >> irq_exit();
> >>+
> >>+ kgdb_process_breakpoint();
> >> return 1;
> >> }
> >>
> >>diff -Nru a/drivers/net/kgdb_eth.c b/drivers/net/kgdb_eth.c
> >>--- a/drivers/net/kgdb_eth.c Wed Feb 25 14:21:32 2004
> >>+++ b/drivers/net/kgdb_eth.c Wed Feb 25 14:21:32 2004
> >>@@ -60,7 +60,6 @@
> >> static atomic_t in_count;
> >> int kgdboe = 0; /* Default to tty mode */
> >>
> >>-extern void breakpoint(void);
> >> static void rx_hook(struct netpoll *np, int port, char *msg, int len);
> >>
> >> static struct netpoll np = {
> >>@@ -106,14 +105,12 @@
> >>
> >> np->remote_port = port;
> >>
> >>- /* Is this gdb trying to attach? */
> >>- if (!netpoll_trap() && len == 8 && !strncmp(msg, "$Hc-1#09", 8))
> >>- breakpoint();
> >>+ /* Is this gdb trying to attach (!kgdb_connected) or break in
> >>+ * (msg[0] == 3) ? */
> >>+ if (!netpoll_trap() && (!kgdb_connected || msg[0] == 3))
> >>+ kgdb_schedule_breakpoint();
> >>
> >> for (i = 0; i < len; i++) {
> >>- if (msg[i] == 3)
> >>- breakpoint();
> >>-
> >> if (atomic_read(&in_count) >= IN_BUF_SIZE) {
> >> /* buffer overflow, clear it */
> >> in_head = in_tail = 0;
> >>diff -Nru a/drivers/serial/kgdb_8250.c b/drivers/serial/kgdb_8250.c
> >>--- a/drivers/serial/kgdb_8250.c Wed Feb 25 14:21:32 2004
> >>+++ b/drivers/serial/kgdb_8250.c Wed Feb 25 14:21:32 2004
> >>@@ -248,7 +248,7 @@
> >>
> >> /* If we get an interrupt, then KGDB is trying to connect. */
> >> if (!kgdb_connected) {
> >>- breakpoint();
> >>+ kgdb_schedule_breakpoint();
> >> return IRQ_HANDLED;
> >> }
> >>
> >>diff -Nru a/include/linux/kgdb.h b/include/linux/kgdb.h
> >>--- a/include/linux/kgdb.h Wed Feb 25 14:21:32 2004
> >>+++ b/include/linux/kgdb.h Wed Feb 25 14:21:32 2004
> >>@@ -11,8 +11,22 @@
> >> #include <asm/atomic.h>
> >> #include <linux/debugger.h>
> >>
> >>+/*
> >>+ * This file should not include ANY others. This makes it usable
> >>+ * most anywhere without the fear of include order or inclusion.
> >>+ * TODO: Make it so!
> >>+ *
> >>+ * This file may be included all the time. It is only active if
> >>+ * CONFIG_KGDB is defined, otherwise it stubs out all the macros
> >>+ * and entry points.
> >>+ */
> >>+
> >>+#if defined(CONFIG_KGDB) && !defined(__ASSEMBLY__)
> >> /* To enter the debugger explicitly. */
> >>-void breakpoint(void);
> >>+extern void breakpoint(void);
> >>+extern void kgdb_schedule_breakpoint(void);
> >>+extern void kgdb_process_breakpoint(void);
> >>+extern volatile int kgdb_connected;
> >>
> >> #ifndef KGDB_MAX_NO_CPUS
> >> #if CONFIG_NR_CPUS > 8
> >>@@ -112,4 +126,7 @@
> >> char *kgdb_hex2mem(char *buf, char *mem, int count);
> >> int kgdb_get_mem(char *addr, unsigned char *buf, int count);
> >>
> >>+#else
> >>+#define kgdb_process_breakpoint() do {} while(0)
> >>+#endif /* KGDB && !__ASSEMBLY__ */
> >> #endif /* _KGDB_H_ */
> >>diff -Nru a/kernel/kgdb.c b/kernel/kgdb.c
> >>--- a/kernel/kgdb.c Wed Feb 25 14:21:32 2004
> >>+++ b/kernel/kgdb.c Wed Feb 25 14:21:32 2004
> >>@@ -1169,6 +1169,29 @@
> >> printk("Connected.\n");
> >> }
> >>
> >>+/*
> >>+ * Sometimes we need to schedule a breakpoint because we can't break
> >>+ * right where we are.
> >>+ */
> >>+static int kgdb_need_breakpoint[NR_CPUS];
> >>+
> >>+void kgdb_schedule_breakpoint(void)
> >>+{
> >>+ kgdb_need_breakpoint[smp_processor_id()] = 1;
> >>+}
> >>+
> >>+void kgdb_process_breakpoint(void)
> >>+{
> >>+ /*
> >>+ * Handle a breakpoint queued from inside network driver code
> >>+ * to avoid reentrancy issues
> >>+ */
> >>+ if (kgdb_need_breakpoint[smp_processor_id()]) {
> >>+ kgdb_need_breakpoint[smp_processor_id()] = 0;
> >>+ breakpoint();
> >>+ }
> >>+}
> >>+
> >> #ifdef CONFIG_KGDB_CONSOLE
> >> char kgdbconbuf[BUFMAX];
> >
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> > in the body of a message to [email protected]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
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;
--------------------------------------
Lets face it, this bit of source is most likly of very little interest to most
users. I.e. it is a free page on which we can post what ever we want.
>
> What are info files?
>
> -Amit
>
>
>>comments...
>>
>>-g
>>
>>
>>>OK to checkin.
>>>-Amit
>>>
>>>
>>>># This is a BitKeeper generated patch for the following project:
>>>># Project Name: Linux kernel tree
>>>># This patch format is intended for GNU patch command version 2.5 or
>>>>higher. # This patch includes the following deltas:
>>>># ChangeSet 1.1663 -> 1.1664
>>>># arch/i386/kernel/irq.c 1.48 -> 1.49
>>>># drivers/net/kgdb_eth.c 1.2 -> 1.3
>>>># arch/x86_64/kernel/irq.c 1.21 -> 1.22
>>>># drivers/serial/kgdb_8250.c 1.3 -> 1.4
>>>># kernel/kgdb.c 1.3 -> 1.4
>>>># arch/ppc/kernel/irq.c 1.36 -> 1.37
>>>># include/linux/kgdb.h 1.3 -> 1.4
>>>>#
>>>># The following is the BitKeeper ChangeSet Log
>>>># --------------------------------------------
>>>># 04/02/25 [email protected] 1.1664
>>>># process_breakpoint/schedule_breakpoint.
>>>># --------------------------------------------
>>>>#
>>>>diff -Nru a/arch/i386/kernel/irq.c b/arch/i386/kernel/irq.c
>>>>--- a/arch/i386/kernel/irq.c Wed Feb 25 14:21:32 2004
>>>>+++ b/arch/i386/kernel/irq.c Wed Feb 25 14:21:32 2004
>>>>@@ -34,6 +34,7 @@
>>>>#include <linux/proc_fs.h>
>>>>#include <linux/seq_file.h>
>>>>#include <linux/kallsyms.h>
>>>>+#include <linux/kgdb.h>
>>>>
>>>>#include <asm/atomic.h>
>>>>#include <asm/io.h>
>>>>@@ -507,6 +508,8 @@
>>>> spin_unlock(&desc->lock);
>>>>
>>>> irq_exit();
>>>>+
>>>>+ kgdb_process_breakpoint();
>>>>
>>>> return 1;
>>>>}
>>>>diff -Nru a/arch/ppc/kernel/irq.c b/arch/ppc/kernel/irq.c
>>>>--- a/arch/ppc/kernel/irq.c Wed Feb 25 14:21:32 2004
>>>>+++ b/arch/ppc/kernel/irq.c Wed Feb 25 14:21:32 2004
>>>>@@ -46,6 +46,7 @@
>>>>#include <linux/random.h>
>>>>#include <linux/seq_file.h>
>>>>#include <linux/cpumask.h>
>>>>+#include <linux/kgdb.h>
>>>>
>>>>#include <asm/uaccess.h>
>>>>#include <asm/bitops.h>
>>>>@@ -536,7 +537,9 @@
>>>> if (irq != -2 && first)
>>>> /* That's not SMP safe ... but who cares ? */
>>>> ppc_spurious_interrupts++;
>>>>- irq_exit();
>>>>+ irq_exit();
>>>>+
>>>>+ kgdb_process_breakpoint();
>>>>}
>>>>
>>>>unsigned long probe_irq_on (void)
>>>>diff -Nru a/arch/x86_64/kernel/irq.c b/arch/x86_64/kernel/irq.c
>>>>--- a/arch/x86_64/kernel/irq.c Wed Feb 25 14:21:32 2004
>>>>+++ b/arch/x86_64/kernel/irq.c Wed Feb 25 14:21:32 2004
>>>>@@ -405,6 +405,8 @@
>>>> spin_unlock(&desc->lock);
>>>>
>>>> irq_exit();
>>>>+
>>>>+ kgdb_process_breakpoint();
>>>> return 1;
>>>>}
>>>>
>>>>diff -Nru a/drivers/net/kgdb_eth.c b/drivers/net/kgdb_eth.c
>>>>--- a/drivers/net/kgdb_eth.c Wed Feb 25 14:21:32 2004
>>>>+++ b/drivers/net/kgdb_eth.c Wed Feb 25 14:21:32 2004
>>>>@@ -60,7 +60,6 @@
>>>>static atomic_t in_count;
>>>>int kgdboe = 0; /* Default to tty mode */
>>>>
>>>>-extern void breakpoint(void);
>>>>static void rx_hook(struct netpoll *np, int port, char *msg, int len);
>>>>
>>>>static struct netpoll np = {
>>>>@@ -106,14 +105,12 @@
>>>>
>>>> np->remote_port = port;
>>>>
>>>>- /* Is this gdb trying to attach? */
>>>>- if (!netpoll_trap() && len == 8 && !strncmp(msg, "$Hc-1#09", 8))
>>>>- breakpoint();
>>>>+ /* Is this gdb trying to attach (!kgdb_connected) or break in
>>>>+ * (msg[0] == 3) ? */
>>>>+ if (!netpoll_trap() && (!kgdb_connected || msg[0] == 3))
>>>>+ kgdb_schedule_breakpoint();
>>>>
>>>> for (i = 0; i < len; i++) {
>>>>- if (msg[i] == 3)
>>>>- breakpoint();
>>>>-
>>>> if (atomic_read(&in_count) >= IN_BUF_SIZE) {
>>>> /* buffer overflow, clear it */
>>>> in_head = in_tail = 0;
>>>>diff -Nru a/drivers/serial/kgdb_8250.c b/drivers/serial/kgdb_8250.c
>>>>--- a/drivers/serial/kgdb_8250.c Wed Feb 25 14:21:32 2004
>>>>+++ b/drivers/serial/kgdb_8250.c Wed Feb 25 14:21:32 2004
>>>>@@ -248,7 +248,7 @@
>>>>
>>>> /* If we get an interrupt, then KGDB is trying to connect. */
>>>> if (!kgdb_connected) {
>>>>- breakpoint();
>>>>+ kgdb_schedule_breakpoint();
>>>> return IRQ_HANDLED;
>>>> }
>>>>
>>>>diff -Nru a/include/linux/kgdb.h b/include/linux/kgdb.h
>>>>--- a/include/linux/kgdb.h Wed Feb 25 14:21:32 2004
>>>>+++ b/include/linux/kgdb.h Wed Feb 25 14:21:32 2004
>>>>@@ -11,8 +11,22 @@
>>>>#include <asm/atomic.h>
>>>>#include <linux/debugger.h>
>>>>
>>>>+/*
>>>>+ * This file should not include ANY others. This makes it usable
>>>>+ * most anywhere without the fear of include order or inclusion.
>>>>+ * TODO: Make it so!
>>>>+ *
>>>>+ * This file may be included all the time. It is only active if
>>>>+ * CONFIG_KGDB is defined, otherwise it stubs out all the macros
>>>>+ * and entry points.
>>>>+ */
>>>>+
>>>>+#if defined(CONFIG_KGDB) && !defined(__ASSEMBLY__)
>>>>/* To enter the debugger explicitly. */
>>>>-void breakpoint(void);
>>>>+extern void breakpoint(void);
>>>>+extern void kgdb_schedule_breakpoint(void);
>>>>+extern void kgdb_process_breakpoint(void);
>>>>+extern volatile int kgdb_connected;
>>>>
>>>>#ifndef KGDB_MAX_NO_CPUS
>>>>#if CONFIG_NR_CPUS > 8
>>>>@@ -112,4 +126,7 @@
>>>>char *kgdb_hex2mem(char *buf, char *mem, int count);
>>>>int kgdb_get_mem(char *addr, unsigned char *buf, int count);
>>>>
>>>>+#else
>>>>+#define kgdb_process_breakpoint() do {} while(0)
>>>>+#endif /* KGDB && !__ASSEMBLY__ */
>>>>#endif /* _KGDB_H_ */
>>>>diff -Nru a/kernel/kgdb.c b/kernel/kgdb.c
>>>>--- a/kernel/kgdb.c Wed Feb 25 14:21:32 2004
>>>>+++ b/kernel/kgdb.c Wed Feb 25 14:21:32 2004
>>>>@@ -1169,6 +1169,29 @@
>>>> printk("Connected.\n");
>>>>}
>>>>
>>>>+/*
>>>>+ * Sometimes we need to schedule a breakpoint because we can't break
>>>>+ * right where we are.
>>>>+ */
>>>>+static int kgdb_need_breakpoint[NR_CPUS];
>>>>+
>>>>+void kgdb_schedule_breakpoint(void)
>>>>+{
>>>>+ kgdb_need_breakpoint[smp_processor_id()] = 1;
>>>>+}
>>>>+
>>>>+void kgdb_process_breakpoint(void)
>>>>+{
>>>>+ /*
>>>>+ * Handle a breakpoint queued from inside network driver code
>>>>+ * to avoid reentrancy issues
>>>>+ */
>>>>+ if (kgdb_need_breakpoint[smp_processor_id()]) {
>>>>+ kgdb_need_breakpoint[smp_processor_id()] = 0;
>>>>+ breakpoint();
>>>>+ }
>>>>+}
>>>>+
>>>>#ifdef CONFIG_KGDB_CONSOLE
>>>>char kgdbconbuf[BUFMAX];
>>>
>>>-
>>>To unsubscribe from this list: send the line "unsubscribe linux-kernel"
>>>in the body of a message to [email protected]
>>>More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>Please read the FAQ at http://www.tux.org/lkml/
>
>
--
George Anzinger [email protected]
High-res-timers: http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml
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.
-Amit
>
> Lets face it, this bit of source is most likly of very little interest to
> most users. I.e. it is a free page on which we can post what ever we want.
>
> > What are info files?
> >
> > -Amit
> >
> >>comments...
> >>
> >>-g
> >>
> >>>OK to checkin.
> >>>-Amit
> >>>
> >>>># This is a BitKeeper generated patch for the following project:
> >>>># Project Name: Linux kernel tree
> >>>># This patch format is intended for GNU patch command version 2.5 or
> >>>>higher. # This patch includes the following deltas:
> >>>># ChangeSet 1.1663 -> 1.1664
> >>>># arch/i386/kernel/irq.c 1.48 -> 1.49
> >>>># drivers/net/kgdb_eth.c 1.2 -> 1.3
> >>>># arch/x86_64/kernel/irq.c 1.21 -> 1.22
> >>>># drivers/serial/kgdb_8250.c 1.3 -> 1.4
> >>>># kernel/kgdb.c 1.3 -> 1.4
> >>>># arch/ppc/kernel/irq.c 1.36 -> 1.37
> >>>># include/linux/kgdb.h 1.3 -> 1.4
> >>>>#
> >>>># The following is the BitKeeper ChangeSet Log
> >>>># --------------------------------------------
> >>>># 04/02/25 [email protected] 1.1664
> >>>># process_breakpoint/schedule_breakpoint.
> >>>># --------------------------------------------
> >>>>#
> >>>>diff -Nru a/arch/i386/kernel/irq.c b/arch/i386/kernel/irq.c
> >>>>--- a/arch/i386/kernel/irq.c Wed Feb 25 14:21:32 2004
> >>>>+++ b/arch/i386/kernel/irq.c Wed Feb 25 14:21:32 2004
> >>>>@@ -34,6 +34,7 @@
> >>>>#include <linux/proc_fs.h>
> >>>>#include <linux/seq_file.h>
> >>>>#include <linux/kallsyms.h>
> >>>>+#include <linux/kgdb.h>
> >>>>
> >>>>#include <asm/atomic.h>
> >>>>#include <asm/io.h>
> >>>>@@ -507,6 +508,8 @@
> >>>> spin_unlock(&desc->lock);
> >>>>
> >>>> irq_exit();
> >>>>+
> >>>>+ kgdb_process_breakpoint();
> >>>>
> >>>> return 1;
> >>>>}
> >>>>diff -Nru a/arch/ppc/kernel/irq.c b/arch/ppc/kernel/irq.c
> >>>>--- a/arch/ppc/kernel/irq.c Wed Feb 25 14:21:32 2004
> >>>>+++ b/arch/ppc/kernel/irq.c Wed Feb 25 14:21:32 2004
> >>>>@@ -46,6 +46,7 @@
> >>>>#include <linux/random.h>
> >>>>#include <linux/seq_file.h>
> >>>>#include <linux/cpumask.h>
> >>>>+#include <linux/kgdb.h>
> >>>>
> >>>>#include <asm/uaccess.h>
> >>>>#include <asm/bitops.h>
> >>>>@@ -536,7 +537,9 @@
> >>>> if (irq != -2 && first)
> >>>> /* That's not SMP safe ... but who cares ? */
> >>>> ppc_spurious_interrupts++;
> >>>>- irq_exit();
> >>>>+ irq_exit();
> >>>>+
> >>>>+ kgdb_process_breakpoint();
> >>>>}
> >>>>
> >>>>unsigned long probe_irq_on (void)
> >>>>diff -Nru a/arch/x86_64/kernel/irq.c b/arch/x86_64/kernel/irq.c
> >>>>--- a/arch/x86_64/kernel/irq.c Wed Feb 25 14:21:32 2004
> >>>>+++ b/arch/x86_64/kernel/irq.c Wed Feb 25 14:21:32 2004
> >>>>@@ -405,6 +405,8 @@
> >>>> spin_unlock(&desc->lock);
> >>>>
> >>>> irq_exit();
> >>>>+
> >>>>+ kgdb_process_breakpoint();
> >>>> return 1;
> >>>>}
> >>>>
> >>>>diff -Nru a/drivers/net/kgdb_eth.c b/drivers/net/kgdb_eth.c
> >>>>--- a/drivers/net/kgdb_eth.c Wed Feb 25 14:21:32 2004
> >>>>+++ b/drivers/net/kgdb_eth.c Wed Feb 25 14:21:32 2004
> >>>>@@ -60,7 +60,6 @@
> >>>>static atomic_t in_count;
> >>>>int kgdboe = 0; /* Default to tty mode */
> >>>>
> >>>>-extern void breakpoint(void);
> >>>>static void rx_hook(struct netpoll *np, int port, char *msg, int len);
> >>>>
> >>>>static struct netpoll np = {
> >>>>@@ -106,14 +105,12 @@
> >>>>
> >>>> np->remote_port = port;
> >>>>
> >>>>- /* Is this gdb trying to attach? */
> >>>>- if (!netpoll_trap() && len == 8 && !strncmp(msg, "$Hc-1#09", 8))
> >>>>- breakpoint();
> >>>>+ /* Is this gdb trying to attach (!kgdb_connected) or break in
> >>>>+ * (msg[0] == 3) ? */
> >>>>+ if (!netpoll_trap() && (!kgdb_connected || msg[0] == 3))
> >>>>+ kgdb_schedule_breakpoint();
> >>>>
> >>>> for (i = 0; i < len; i++) {
> >>>>- if (msg[i] == 3)
> >>>>- breakpoint();
> >>>>-
> >>>> if (atomic_read(&in_count) >= IN_BUF_SIZE) {
> >>>> /* buffer overflow, clear it */
> >>>> in_head = in_tail = 0;
> >>>>diff -Nru a/drivers/serial/kgdb_8250.c b/drivers/serial/kgdb_8250.c
> >>>>--- a/drivers/serial/kgdb_8250.c Wed Feb 25 14:21:32 2004
> >>>>+++ b/drivers/serial/kgdb_8250.c Wed Feb 25 14:21:32 2004
> >>>>@@ -248,7 +248,7 @@
> >>>>
> >>>> /* If we get an interrupt, then KGDB is trying to connect. */
> >>>> if (!kgdb_connected) {
> >>>>- breakpoint();
> >>>>+ kgdb_schedule_breakpoint();
> >>>> return IRQ_HANDLED;
> >>>> }
> >>>>
> >>>>diff -Nru a/include/linux/kgdb.h b/include/linux/kgdb.h
> >>>>--- a/include/linux/kgdb.h Wed Feb 25 14:21:32 2004
> >>>>+++ b/include/linux/kgdb.h Wed Feb 25 14:21:32 2004
> >>>>@@ -11,8 +11,22 @@
> >>>>#include <asm/atomic.h>
> >>>>#include <linux/debugger.h>
> >>>>
> >>>>+/*
> >>>>+ * This file should not include ANY others. This makes it usable
> >>>>+ * most anywhere without the fear of include order or inclusion.
> >>>>+ * TODO: Make it so!
> >>>>+ *
> >>>>+ * This file may be included all the time. It is only active if
> >>>>+ * CONFIG_KGDB is defined, otherwise it stubs out all the macros
> >>>>+ * and entry points.
> >>>>+ */
> >>>>+
> >>>>+#if defined(CONFIG_KGDB) && !defined(__ASSEMBLY__)
> >>>>/* To enter the debugger explicitly. */
> >>>>-void breakpoint(void);
> >>>>+extern void breakpoint(void);
> >>>>+extern void kgdb_schedule_breakpoint(void);
> >>>>+extern void kgdb_process_breakpoint(void);
> >>>>+extern volatile int kgdb_connected;
> >>>>
> >>>>#ifndef KGDB_MAX_NO_CPUS
> >>>>#if CONFIG_NR_CPUS > 8
> >>>>@@ -112,4 +126,7 @@
> >>>>char *kgdb_hex2mem(char *buf, char *mem, int count);
> >>>>int kgdb_get_mem(char *addr, unsigned char *buf, int count);
> >>>>
> >>>>+#else
> >>>>+#define kgdb_process_breakpoint() do {} while(0)
> >>>>+#endif /* KGDB && !__ASSEMBLY__ */
> >>>>#endif /* _KGDB_H_ */
> >>>>diff -Nru a/kernel/kgdb.c b/kernel/kgdb.c
> >>>>--- a/kernel/kgdb.c Wed Feb 25 14:21:32 2004
> >>>>+++ b/kernel/kgdb.c Wed Feb 25 14:21:32 2004
> >>>>@@ -1169,6 +1169,29 @@
> >>>> printk("Connected.\n");
> >>>>}
> >>>>
> >>>>+/*
> >>>>+ * Sometimes we need to schedule a breakpoint because we can't break
> >>>>+ * right where we are.
> >>>>+ */
> >>>>+static int kgdb_need_breakpoint[NR_CPUS];
> >>>>+
> >>>>+void kgdb_schedule_breakpoint(void)
> >>>>+{
> >>>>+ kgdb_need_breakpoint[smp_processor_id()] = 1;
> >>>>+}
> >>>>+
> >>>>+void kgdb_process_breakpoint(void)
> >>>>+{
> >>>>+ /*
> >>>>+ * Handle a breakpoint queued from inside network driver code
> >>>>+ * to avoid reentrancy issues
> >>>>+ */
> >>>>+ if (kgdb_need_breakpoint[smp_processor_id()]) {
> >>>>+ kgdb_need_breakpoint[smp_processor_id()] = 0;
> >>>>+ breakpoint();
> >>>>+ }
> >>>>+}
> >>>>+
> >>>>#ifdef CONFIG_KGDB_CONSOLE
> >>>>char kgdbconbuf[BUFMAX];
> >>>
> >>>-
> >>>To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> >>>in the body of a message to [email protected]
> >>>More majordomo info at http://vger.kernel.org/majordomo-info.html
> >>>Please read the FAQ at http://www.tux.org/lkml/
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 [email protected]
High-res-timers: http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml
On Thursday 04 Mar 2004 5:50 am, George Anzinger wrote:
> 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
User _will_ see the exact context where he is going to continue. If we type
$pc=foo \n continue pc will be changed and will run in the same register
values where the serial irq occured.
> context any
>
> p fun()
p fun() will push arguments on stack over the place where irq occured, which
is exactly how it''ll run.
-Amit
>
> will run in.
>
> ~
Amit S. Kale wrote:
~
>
>>context any
>>
>>p fun()
>
>
> p fun() will push arguments on stack over the place where irq occured, which
> is exactly how it'll run.
Is this capability in kgdb lite? It was one of the last things I added to -mm
version.
~
--
George Anzinger [email protected]
High-res-timers: http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml
On Friday 12 Mar 2004 2:58 am, George Anzinger wrote:
> Amit S. Kale wrote:
> ~
>
> >>context any
> >>
> >>p fun()
> >
> > p fun() will push arguments on stack over the place where irq occured,
> > which is exactly how it'll run.
>
> Is this capability in kgdb lite? It was one of the last things I added to
> -mm version.
No! It's not present in kgdb heavy also. All you can do is set $pc, continue.
-Amit
Amit S. Kale wrote:
> On Friday 12 Mar 2004 2:58 am, George Anzinger wrote:
>
>>Amit S. Kale wrote:
>>~
>>
>>
>>>>context any
>>>>
>>>>p fun()
>>>
>>>p fun() will push arguments on stack over the place where irq occured,
>>>which is exactly how it'll run.
>>
>>Is this capability in kgdb lite? It was one of the last things I added to
>>-mm version.
>
>
> No! It's not present in kgdb heavy also. All you can do is set $pc, continue.
Possibly I can help here. I did it for the mm version. It does require a
couple of asm bits and it sort of messes up the set/fetch memory, but it does do
the job.
>
> -Amit
>
--
George Anzinger [email protected]
High-res-timers: http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml
On Friday 12 Mar 2004 1:33 pm, George Anzinger wrote:
> Amit S. Kale wrote:
> > On Friday 12 Mar 2004 2:58 am, George Anzinger wrote:
> >>Amit S. Kale wrote:
> >>~
> >>
> >>>>context any
> >>>>
> >>>>p fun()
> >>>
> >>>p fun() will push arguments on stack over the place where irq occured,
> >>>which is exactly how it'll run.
> >>
> >>Is this capability in kgdb lite? It was one of the last things I added
> >> to -mm version.
> >
> > No! It's not present in kgdb heavy also. All you can do is set $pc,
> > continue.
>
> Possibly I can help here. I did it for the mm version. It does require a
> couple of asm bits and it sort of messes up the set/fetch memory, but it
> does do the job.
I have seen that. It's too messy!
-Amit
Amit S. Kale wrote:
> On Friday 12 Mar 2004 1:33 pm, George Anzinger wrote:
>
>>Amit S. Kale wrote:
>>
>>>On Friday 12 Mar 2004 2:58 am, George Anzinger wrote:
>>>
>>>>Amit S. Kale wrote:
>>>>~
>>>>
>>>>
>>>>>>context any
>>>>>>
>>>>>>p fun()
>>>>>
>>>>>p fun() will push arguments on stack over the place where irq occured,
>>>>>which is exactly how it'll run.
>>>>
>>>>Is this capability in kgdb lite? It was one of the last things I added
>>>>to -mm version.
>>>
>>>No! It's not present in kgdb heavy also. All you can do is set $pc,
>>>continue.
>>
>>Possibly I can help here. I did it for the mm version. It does require a
>>couple of asm bits and it sort of messes up the set/fetch memory, but it
>>does do the job.
>
>
> I have seen that. It's too messy!
You have a better solution?
--
George Anzinger [email protected]
High-res-timers: http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml
On Tuesday 16 Mar 2004 1:22 am, George Anzinger wrote:
> Amit S. Kale wrote:
> > On Friday 12 Mar 2004 1:33 pm, George Anzinger wrote:
> >>Amit S. Kale wrote:
> >>>On Friday 12 Mar 2004 2:58 am, George Anzinger wrote:
> >>>>Amit S. Kale wrote:
> >>>>~
> >>>>
> >>>>>>context any
> >>>>>>
> >>>>>>p fun()
> >>>>>
> >>>>>p fun() will push arguments on stack over the place where irq occured,
> >>>>>which is exactly how it'll run.
> >>>>
> >>>>Is this capability in kgdb lite? It was one of the last things I added
> >>>>to -mm version.
> >>>
> >>>No! It's not present in kgdb heavy also. All you can do is set $pc,
> >>>continue.
> >>
> >>Possibly I can help here. I did it for the mm version. It does require
> >> a couple of asm bits and it sort of messes up the set/fetch memory, but
> >> it does do the job.
> >
> > I have seen that. It's too messy!
>
> You have a better solution?
Nope.
I think this feature is very likely to be abused by programmers. They do
deserve suffering if they choose to shoot at their own feet.
Kernel programmers have to be aware of implementation of this feature if they
choose to call arbitrary functions. This includes knowing whether interrupts
are disabled, handling of exceptions in gdb called functions, whether other
processors run, that breakpoints are disabled. Given that kgdb is used for
learning the kernel, such features are best kept aside.
-Amit
Amit S. Kale wrote:
>On Tuesday 16 Mar 2004 1:22 am, George Anzinger wrote:
>
>
>>Amit S. Kale wrote:
>>
>>
>>>On Friday 12 Mar 2004 1:33 pm, George Anzinger wrote:
>>>
>>>
>>>>Amit S. Kale wrote:
>>>>
>>>>
>>>>>On Friday 12 Mar 2004 2:58 am, George Anzinger wrote:
>>>>>
>>>>>
>>>>>>Amit S. Kale wrote:
>>>>>>~
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>context any
>>>>>>>>
>>>>>>>>p fun()
>>>>>>>>
>>>>>>>>
>>>>>>>p fun() will push arguments on stack over the place where irq occured,
>>>>>>>which is exactly how it'll run.
>>>>>>>
>>>>>>>
>>>>>>Is this capability in kgdb lite? It was one of the last things I added
>>>>>>to -mm version.
>>>>>>
>>>>>>
>>>>>No! It's not present in kgdb heavy also. All you can do is set $pc,
>>>>>continue.
>>>>>
>>>>>
>>>>Possibly I can help here. I did it for the mm version. It does require
>>>>a couple of asm bits and it sort of messes up the set/fetch memory, but
>>>>it does do the job.
>>>>
>>>>
>>>I have seen that. It's too messy!
>>>
>>>
>>You have a better solution?
>>
>>
>
>Nope.
>
>I think this feature is very likely to be abused by programmers. They do
>deserve suffering if they choose to shoot at their own feet.
>
>Kernel programmers have to be aware of implementation of this feature if they
>choose to call arbitrary functions. This includes knowing whether interrupts
>are disabled, handling of exceptions in gdb called functions, whether other
>processors run, that breakpoints are disabled. Given that kgdb is used for
>learning the kernel, such features are best kept aside.
>
>-Amit
>
Pardon my question. I've lost track of the thread and the available context
doesn't really help me.
Is this the ability to step into an arbitrary function from the gdb command
line or something else?
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell's sig
On Tuesday 16 Mar 2004 6:32 pm, La Monte H.P. Yarroll wrote:
> Amit S. Kale wrote:
> >On Tuesday 16 Mar 2004 1:22 am, George Anzinger wrote:
> >>Amit S. Kale wrote:
> >>>On Friday 12 Mar 2004 1:33 pm, George Anzinger wrote:
> >>>>Amit S. Kale wrote:
> >>>>>On Friday 12 Mar 2004 2:58 am, George Anzinger wrote:
> >>>>>>Amit S. Kale wrote:
> >>>>>>~
> >>>>>>
> >>>>>>>>context any
> >>>>>>>>
> >>>>>>>>p fun()
> >>>>>>>
> >>>>>>>p fun() will push arguments on stack over the place where irq
> >>>>>>> occured, which is exactly how it'll run.
> >>>>>>
> >>>>>>Is this capability in kgdb lite? It was one of the last things I
> >>>>>> added to -mm version.
> >>>>>
> >>>>>No! It's not present in kgdb heavy also. All you can do is set $pc,
> >>>>>continue.
> >>>>
> >>>>Possibly I can help here. I did it for the mm version. It does
> >>>> require a couple of asm bits and it sort of messes up the set/fetch
> >>>> memory, but it does do the job.
> >>>
> >>>I have seen that. It's too messy!
> >>
> >>You have a better solution?
> >
> >Nope.
> >
> >I think this feature is very likely to be abused by programmers. They do
> >deserve suffering if they choose to shoot at their own feet.
> >
> >Kernel programmers have to be aware of implementation of this feature if
> > they choose to call arbitrary functions. This includes knowing whether
> > interrupts are disabled, handling of exceptions in gdb called functions,
> > whether other processors run, that breakpoints are disabled. Given that
> > kgdb is used for learning the kernel, such features are best kept aside.
> >
> >-Amit
>
> Pardon my question. I've lost track of the thread and the available
> context doesn't really help me.
>
> Is this the ability to step into an arbitrary function from the gdb command
> line or something else?
This is ability to call arbitray function from gdb command line.
Example
(gdb) p myfunction(1,2,3)
-Amit