The following patch set represents the Novell Linux Kernel Debugger,
stripped off of its original low-level exception handling framework.
Jan
Jan Beulich wrote:
> The following patch set represents the Novell Linux Kernel Debugger,
> stripped off of its original low-level exception handling framework.
Honestly, just seeing all these code changes makes me think we really
don't need it in the kernel. How many "early" and "alternative" gadgets
do we really need just for this thing?
Jeff
On Wed, 9 Nov 2005, Jeff Garzik wrote:
> Jan Beulich wrote:
> > The following patch set represents the Novell Linux Kernel Debugger,
> > stripped off of its original low-level exception handling framework.
>
>
> Honestly, just seeing all these code changes makes me think we really
> don't need it in the kernel. How many "early" and "alternative" gadgets
> do we really need just for this thing?
On the surface I have to agree. However, if Jan wants feedback
on the patches, that's a reasonable request IMO.
(but they need to be readable via email so that someone
can comment on them)
At a quick blush, I would guess it has as much chance as
kdb does (or did) for merging.
--
~Randy
>On the surface I have to agree. However, if Jan wants feedback
>on the patches, that's a reasonable request IMO.
Getting feedback is not the only goal.
>(but they need to be readable via email so that someone
>can comment on them)
Sorry, I hear this quite often, but I also have to play by some company
rules, one of which is to use a certain mail system (or otherwise be
left alone in case of problems).
>At a quick blush, I would guess it has as much chance as
>kdb does (or did) for merging.
The intention isn't necessarily to merge the whole debugger, but what
we desire is to merge everything to allow the debugger to be built
outside of the tree (perhaps as a standalong module).
Jan
On Mer, 2005-11-09 at 11:59 -0500, Jeff Garzik wrote:
> Honestly, just seeing all these code changes makes me think we really
> don't need it in the kernel. How many "early" and "alternative" gadgets
> do we really need just for this thing?
I think it is clearly the case that the design is wrong. The existance
of kgdb shows how putting the complex logic remotely on another system
is not only a lot cleaner and simpler but can also provide more
functionality and higher reliability.
The presence of user mode linux and Xen also provide solutions to the
usual concern about needing two systems, as will future hardware
features.
Alan
On Mer, 2005-11-09 at 18:14 +0100, Jan Beulich wrote:
> Sorry, I hear this quite often, but I also have to play by some company
> rules, one of which is to use a certain mail system (or otherwise be
> left alone in case of problems).
Which is more important. Your employers email system or the ability of
people to quote and work easily with patches ? Please send patches in a
sensible format, even if you use a different mail tool for all your
other email.
Other Novell contributors many of them large and important contributors
from SuSE don't appear to be having this problem
Alan Cox wrote:
>On Mer, 2005-11-09 at 11:59 -0500, Jeff Garzik wrote:
>
>
>>Honestly, just seeing all these code changes makes me think we really
>>don't need it in the kernel. How many "early" and "alternative" gadgets
>>do we really need just for this thing?
>>
>>
>
>I think it is clearly the case that the design is wrong. The existance
>of kgdb shows how putting the complex logic remotely on another system
>is not only a lot cleaner and simpler but can also provide more
>functionality and higher reliability.
>
>The presence of user mode linux and Xen also provide solutions to the
>usual concern about needing two systems, as will future hardware
>features.
>
>
Not necessarily true with regard to having the functionality in the
kernel, but for Linux, probably better for maintenance based on the social
issues. I have MDB fully integrated in the kernel and I don't have all
these problems. It's just an update to the kdb hooks, patch, build and go.
Novell should probably just fork the kernel and start their own distro
and dump the mainstream Linux. They have the people and infrastructure
to support drivers and do just as good a job as LKML with the old
NetWare group. Novell was presented with MDB two years ago and opted
to build their own rather than go with ours. I have been disappointed
with the quality of what they have produced to date.
They should fork form Linux and understand that the Linux folks and
their culture is totaly alien to Novell's culture. They will never make
progress with the Linux folks and continued interactions will waste both
groups time. They have the talent and resources to preempt Linux
and do their own thing. They need to just go and do it.
J
>Alan
>
>-
>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/
>
>
>
On Wed, Nov 09, 2005 at 06:14:05PM +0100, Jan Beulich wrote:
> >On the surface I have to agree. However, if Jan wants feedback
> >on the patches, that's a reasonable request IMO.
>
> Getting feedback is not the only goal.
What is the goal? You never stated it.
> >(but they need to be readable via email so that someone
> >can comment on them)
>
> Sorry, I hear this quite often, but I also have to play by some company
> rules, one of which is to use a certain mail system (or otherwise be
> left alone in case of problems).
Please remember, lkml does _not_ care about any company rules.
You need to follow the community's rules, not try to get the community
to follow yours, if you wish to get them to do anything.
thanks,
greg k-h
Jan wrote:
> Sorry, I hear this quite often, but I also have to play by some company
> rules, one of which is to use a certain mail system (or otherwise be
> left alone in case of problems).
May I recommend a separate tool for sending patches, instead
of using your email client. Consider for example:
http://www.speakeasy.org/~pj99/sgi/sendpatchset
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <[email protected]> 1.925.600.0401
On Wed, Nov 09, 2005 at 06:14:05PM +0100, Jan Beulich wrote:
> >At a quick blush, I would guess it has as much chance as
> >kdb does (or did) for merging.
>
> The intention isn't necessarily to merge the whole debugger, but what
> we desire is to merge everything to allow the debugger to be built
> outside of the tree (perhaps as a standalong module).
While you're posted a few actually useful patches that fix or encehance
core code we're not going to put in any of your odd hooks or exports.
As you might have noticed while reading lkml we are everything but keen
on those.
Alan Cox wrote:
>
> I think it is clearly the case that the design is wrong. The existance
> of kgdb shows how putting the complex logic remotely on another system
> is not only a lot cleaner and simpler but can also provide more
> functionality and higher reliability.
Unless the target machine is modern (2005+ era) and has no serial ports,
nor any way to add them other than via the USB stack.
Cheers
On Thu, Nov 10, 2005 at 09:48:42AM -0500, Mark Lord wrote:
> Alan Cox wrote:
> >
> >I think it is clearly the case that the design is wrong. The existance
> >of kgdb shows how putting the complex logic remotely on another system
> >is not only a lot cleaner and simpler but can also provide more
> >functionality and higher reliability.
>
> Unless the target machine is modern (2005+ era) and has no serial ports,
> nor any way to add them other than via the USB stack.
There's always ethernet. Or, where there is a will, there is a way, as
shown by PowerPC's xmon over firewire.
--
Tom Rini
http://gate.crashing.org/~trini/
On Iau, 2005-11-10 at 09:48 -0500, Mark Lord wrote:
> Unless the target machine is modern (2005+ era) and has no serial ports,
> nor any way to add them other than via the USB stack.
Debugger USB serial isn't hard. A micro polled USB stack is tiny (see
for example the BIOS USB in a PC). You've also get ethernet and
firewire. gdb remote has supported ethernet for years along with just
about anything else you can get a bitstream in and out of.
Alan
"Randy.Dunlap" <[email protected]> writes:
> On Wed, 9 Nov 2005, Jeff Garzik wrote:
>
> > Jan Beulich wrote:
> > > The following patch set represents the Novell Linux Kernel Debugger,
> > > stripped off of its original low-level exception handling framework.
> >
> >
> > Honestly, just seeing all these code changes makes me think we really
> > don't need it in the kernel. How many "early" and "alternative" gadgets
> > do we really need just for this thing?
>
> On the surface I have to agree. However, if Jan wants feedback
> on the patches, that's a reasonable request IMO.
> (but they need to be readable via email so that someone
> can comment on them)
>
> At a quick blush, I would guess it has as much chance as
> kdb does (or did) for merging.
I hope we can follow the same strategy as I did for debuggers on x86-64 -
which imho worked very well. Get all the (sane) hooks in so that everybody
who wants to use their particular flavour of debugger can use it
by (ideally) either just loading it or alternatively applying a small
core patch and the debugger files elsewhere. The die chains started
from that.
Making the debugger work modular is a bit more work, but possible (was
done for kdb at least before with some changes). IMHO that's the ideal
state for users - they can just compile it externally and load it when
they need it, but the core kernel doesn't need to carry it. It
conflicts a bit with the usual policy of not exporting stuff that's
not used in the core kernel; but I think making an exception here is
reasonable because
So I guess it's best to concentrate on merging the hooks needed in a sane
way.
I think the many additions for "early" code in the NLKD patchkit
comes from Jan's desire to make the debugger work in as many weird
corner cases as possible. I must say he found a lot of problems in
corner cases during that work in x86-64 and i386, fixing generic
bugs and making even the standard oops code and other error handling
code (e.g. double faults on i386) more reliable, which I appreciate.
The particular early changes have to be weighted of course in
intrusiveness. If it's simple and not too ugly stuff I guess it is
reasonable to consider it. If not the debugger will have
to live without it.
I already merged all the changes that looked good (and where I was cc'ed)
for x86-64 now. Some patches need changes, and I guess with that
feedback the i386 part can be similarly adjusted.
-Andi
Mark Lord <[email protected]> writes:
> Alan Cox wrote:
> >
> > I think it is clearly the case that the design is wrong. The existance
> > of kgdb shows how putting the complex logic remotely on another system
> > is not only a lot cleaner and simpler but can also provide more
> > functionality and higher reliability.
>
> Unless the target machine is modern (2005+ era) and has no serial ports,
> nor any way to add them other than via the USB stack.
Firewire looks most promising actually right now, at least for Desktop/Laptop
type systems. And servers still have serial ports right now, either in
hardware or simulated in some way.
-Andi
Andi Kleen wrote:
>"Randy.Dunlap" <[email protected]> writes:
>
>
>
>>On Wed, 9 Nov 2005, Jeff Garzik wrote:
>>
>>
>>
>>>Jan Beulich wrote:
>>>
>>>
>>>>The following patch set represents the Novell Linux Kernel Debugger,
>>>>stripped off of its original low-level exception handling framework.
>>>>
>>>>
>>>Honestly, just seeing all these code changes makes me think we really
>>>don't need it in the kernel. How many "early" and "alternative" gadgets
>>>do we really need just for this thing?
>>>
>>>
>>On the surface I have to agree. However, if Jan wants feedback
>>on the patches, that's a reasonable request IMO.
>>(but they need to be readable via email so that someone
>>can comment on them)
>>
>>At a quick blush, I would guess it has as much chance as
>>kdb does (or did) for merging.
>>
>>
>
>I hope we can follow the same strategy as I did for debuggers on x86-64 -
>which imho worked very well. Get all the (sane) hooks in so that everybody
>who wants to use their particular flavour of debugger can use it
>by (ideally) either just loading it or alternatively applying a small
>core patch and the debugger files elsewhere. The die chains started
>from that.
>
>
Yes. This is the way to go. Use kdb as a base and instrument an
alternate debugger interface. You need to also find a good way to
allow GDB to work properly with alternate debuggers. At present, the
code in traps.c is mutually exclusive since embedded int3
breakpoints trigger in the kernel for gbd. This is busted.
Jeff
>Making the debugger work modular is a bit more work, but possible (was
>done for kdb at least before with some changes). IMHO that's the ideal
>state for users - they can just compile it externally and load it when
>they need it, but the core kernel doesn't need to carry it. It
>conflicts a bit with the usual policy of not exporting stuff that's
>not used in the core kernel; but I think making an exception here is
>reasonable because
>
>So I guess it's best to concentrate on merging the hooks needed in a sane
>way.
>
>I think the many additions for "early" code in the NLKD patchkit
>comes from Jan's desire to make the debugger work in as many weird
>corner cases as possible. I must say he found a lot of problems in
>corner cases during that work in x86-64 and i386, fixing generic
>bugs and making even the standard oops code and other error handling
>code (e.g. double faults on i386) more reliable, which I appreciate.
>
>The particular early changes have to be weighted of course in
>intrusiveness. If it's simple and not too ugly stuff I guess it is
>reasonable to consider it. If not the debugger will have
>to live without it.
>
>I already merged all the changes that looked good (and where I was cc'ed)
>for x86-64 now. Some patches need changes, and I guess with that
>feedback the i386 part can be similarly adjusted.
>
>-Andi
>-
>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/
>
>
>
On Sunday 13 November 2005 03:53, jmerkey wrote:
> Yes. This is the way to go. Use kdb as a base and instrument an
> alternate debugger interface. You need to also find a good way to
> allow GDB to work properly with alternate debuggers. At present, the
> code in traps.c is mutually exclusive since embedded int3
> breakpoints trigger in the kernel for gbd. This is busted.
I don't think we'll support stacking multiple kernel debuggers (except
for special cases like kprobes+another debugger). It's complicated
and probably not worth it.
-Andi
Andi Kleen wrote:
>On Sunday 13 November 2005 03:53, jmerkey wrote:
>
>
>
>>Yes. This is the way to go. Use kdb as a base and instrument an
>>alternate debugger interface. You need to also find a good way to
>>allow GDB to work properly with alternate debuggers. At present, the
>>code in traps.c is mutually exclusive since embedded int3
>>breakpoints trigger in the kernel for gbd. This is busted.
>>
>>
>
>
>I don't think we'll support stacking multiple kernel debuggers (except
>for special cases like kprobes+another debugger). It's complicated
>and probably not worth it.
>
>-Andi
>
>
>
>
I already instrumented an alternate debugger interface in MDB. It's not
complicated at all. Here's the code. All you
need to do is change two places. Add the alternate interface into kdb,
and fix the int3 contention problem with GDB. GDB
support with kdb action involves creating a callback into GDB signaling
the int3 POST kdb handling. In other words, keep
a table of breakpoints for int3 alternate debuggers they must register,
compare against this table and divert the int3 on this basis,
it is matches the table, send to the registered debugger entry point, if
it doesn't match, call the GDB handler and send it to
userspace. Seems simple. Here's part one. Someone else can write part 2.
Jeff
diff -Naur ./kdb/kdbmain.c ../linux-2.6.9-mdb/./kdb/kdbmain.c
--- ./kdb/kdbmain.c 2004-10-18 11:46:59.439535288 -0600
+++ ../linux-2.6.9-mdb/./kdb/kdbmain.c 2004-10-18 11:44:47.000000000
-0600
@@ -57,7 +57,12 @@
int kdb_seqno = 2; /* how many times kdb has been entered */
volatile int kdb_nextline = 1;
+
+#if defined(CONFIG_MDB)
+volatile int kdb_new_cpu; /* Which cpu to switch to */
+#else
static volatile int kdb_new_cpu; /* Which cpu to switch to */
+#endif
volatile int kdb_state[NR_CPUS]; /* Per cpu state */
@@ -1134,8 +1139,13 @@
extern char kdb_prompt_str[];
+#if defined(CONFIG_MDB)
static int
kdb_local(kdb_reason_t reason, int error, struct pt_regs *regs,
kdb_dbtrap_t db_result)
+#else
+int
+kdb_local(kdb_reason_t reason, int error, struct pt_regs *regs,
kdb_dbtrap_t db_result)
+#endif
{
char *cmdbuf;
int diag;
@@ -1676,6 +1686,27 @@
int result = 0; /* Default is kdb did not handle it */
int ss_event;
kdb_dbtrap_t db_result=KDB_DB_NOBPT;
+
+#if defined(CONFIG_MDB)
+ extern int AlternateDebuggerRoutine(kdb_reason_t reason, int
error,
+ struct pt_regs *ef);
+ if (!kdb_on)
+ return 0;
+
+ result = AlternateDebuggerRoutine(reason, error, regs);
+ switch (result)
+ {
+ case 1: // alternate debugger handled event
+ return 1;
+
+ case -1: // alternate debugger did not handle event
+ return 0;
+
+ default: // drop into kdb
+ break;
+ }
+#endif
+
atomic_inc(&kdb_event);
switch(reason) {
@@ -3016,6 +3047,40 @@
* Remarks:
*/
+#if defined (CONFIG_MDB)
+
+#include <linux/mdbglobals.h>
+
+void
+mdb_ps1(struct task_struct *p)
+{
+ DBGPrint("0x%p %8d %8d %d %4d %c 0x%p %c%s\n",
+ (void *)p, p->pid, p->parent->pid,
+ kdb_task_has_cpu(p), kdb_process_cpu(p),
+ (p->state == 0) ? 'R' :
+ (p->state < 0) ? 'U' :
+ (p->state & TASK_UNINTERRUPTIBLE) ? 'D' :
+ (p->state & TASK_STOPPED || p->ptrace & PT_PTRACED) ? 'T' :
+ (p->state & TASK_ZOMBIE) ? 'Z' :
+ (p->state & TASK_INTERRUPTIBLE) ? 'S' : '?',
+ (void *)(&p->thread),
+ (p == current) ? '*': ' ',
+ p->comm);
+ if (kdb_task_has_cpu(p)) {
+ struct kdb_running_process *krp = kdb_running_process +
kdb_process_cpu(p);
+ if (!krp->seqno || !krp->p)
+ DBGPrint(" Error: no saved data for this cpu\n");
+ else {
+ if (krp->seqno < kdb_seqno - 1)
+ DBGPrint(" Warning: process state is stale\n");
+ if (krp->p != p)
+ DBGPrint(" Error: does not match running process table
(0x%p)\n", krp->p);
+ }
+ }
+}
+
+#endif
+
void
kdb_ps1(struct task_struct *p)
{
@@ -3835,6 +3900,10 @@
void __init
kdb_init(void)
{
+#if defined(CONFIG_MDB)
+ extern void mdb_init(void);
+#endif
+
kdb_initial_cpu = smp_processor_id();
/*
* This must be called before any calls to kdb_printf.
@@ -3855,6 +3924,11 @@
kdb_cmd_init(); /* Preset commands from kdb_cmds */
kdb_initial_cpu = -1; /* Avoid recursion problems */
+
+#if defined(CONFIG_MDB)
+ mdb_init();
+#endif
+
kdb(KDB_REASON_SILENT, 0, 0); /* Activate any preset breakpoints
on boot cpu */
kdb_initial_cpu = smp_processor_id();
notifier_chain_register(&panic_notifier_list, &kdb_block);
Jeff V. Merkey wrote:
> Andi Kleen wrote:
>
>> On Sunday 13 November 2005 03:53, jmerkey wrote:
>>
>>
>>
>>> Yes. This is the way to go. Use kdb as a base and instrument an
>>> alternate debugger interface. You need to also find a good way to
>>> allow GDB to work properly with alternate debuggers. At present, the
>>> code in traps.c is mutually exclusive since embedded int3
>>> breakpoints trigger in the kernel for gbd. This is busted.
>>>
>>
>>
>>
>> I don't think we'll support stacking multiple kernel debuggers (except
>> for special cases like kprobes+another debugger). It's complicated
>> and probably not worth it.
>>
>> -Andi
>>
>>
>>
>>
> I already instrumented an alternate debugger interface in MDB. It's
> not complicated at all. Here's the code. All you
> need to do is change two places. Add the alternate interface into
> kdb, and fix the int3 contention problem with GDB. GDB
> support with kdb action involves creating a callback into GDB
> signaling the int3 POST kdb handling. In other words, keep
> a table of breakpoints for int3 alternate debuggers they must
> register, compare against this table and divert the int3 on this basis,
> it is matches the table, send to the registered debugger entry point,
> if it doesn't match, call the GDB handler and send it to
> userspace. Seems simple. Here's part one. Someone else can write
> part 2.
>
> Jeff
> diff -Naur ./kdb/kdbmain.c ../linux-2.6.9-mdb/./kdb/kdbmain.c
> --- ./kdb/kdbmain.c 2004-10-18 11:46:59.439535288 -0600
> +++ ../linux-2.6.9-mdb/./kdb/kdbmain.c 2004-10-18
> 11:44:47.000000000 -0600
> @@ -57,7 +57,12 @@
> int kdb_seqno = 2; /* how many times kdb has been
> entered */
>
> volatile int kdb_nextline = 1;
> +
> +#if defined(CONFIG_MDB)
> +volatile int kdb_new_cpu; /* Which cpu to switch to */
> +#else
> static volatile int kdb_new_cpu; /* Which cpu to switch to */
> +#endif
>
> volatile int kdb_state[NR_CPUS]; /* Per cpu state */
>
> @@ -1134,8 +1139,13 @@
>
> extern char kdb_prompt_str[];
>
> +#if defined(CONFIG_MDB)
> static int
> kdb_local(kdb_reason_t reason, int error, struct pt_regs *regs,
> kdb_dbtrap_t db_result)
> +#else
> +int
> +kdb_local(kdb_reason_t reason, int error, struct pt_regs *regs,
> kdb_dbtrap_t db_result)
> +#endif
> {
> char *cmdbuf;
> int diag;
> @@ -1676,6 +1686,27 @@
> int result = 0; /* Default is kdb did not handle it */
> int ss_event;
> kdb_dbtrap_t db_result=KDB_DB_NOBPT;
> +
> +#if defined(CONFIG_MDB)
> + extern int AlternateDebuggerRoutine(kdb_reason_t reason, int
> error,
> + struct pt_regs *ef);
> + if (!kdb_on)
> + return 0;
> +
> + result = AlternateDebuggerRoutine(reason, error, regs);
> + switch (result)
> + {
> + case 1: // alternate debugger handled event
> + return 1;
> +
> + case -1: // alternate debugger did not handle event
> + return 0;
> +
> + default: // drop into kdb
> + break;
> + }
> +#endif
> +
> atomic_inc(&kdb_event);
>
> switch(reason) {
> @@ -3016,6 +3047,40 @@
> * Remarks:
> */
>
> +#if defined (CONFIG_MDB)
> +
> +#include <linux/mdbglobals.h>
> +
> +void
> +mdb_ps1(struct task_struct *p)
> +{
> + DBGPrint("0x%p %8d %8d %d %4d %c 0x%p %c%s\n",
> + (void *)p, p->pid, p->parent->pid,
> + kdb_task_has_cpu(p), kdb_process_cpu(p),
> + (p->state == 0) ? 'R' :
> + (p->state < 0) ? 'U' :
> + (p->state & TASK_UNINTERRUPTIBLE) ? 'D' :
> + (p->state & TASK_STOPPED || p->ptrace & PT_PTRACED) ? 'T' :
> + (p->state & TASK_ZOMBIE) ? 'Z' :
> + (p->state & TASK_INTERRUPTIBLE) ? 'S' : '?',
> + (void *)(&p->thread),
> + (p == current) ? '*': ' ',
> + p->comm);
> + if (kdb_task_has_cpu(p)) {
> + struct kdb_running_process *krp = kdb_running_process +
> kdb_process_cpu(p);
> + if (!krp->seqno || !krp->p)
> + DBGPrint(" Error: no saved data for this cpu\n");
> + else {
> + if (krp->seqno < kdb_seqno - 1)
> + DBGPrint(" Warning: process state is stale\n");
> + if (krp->p != p)
> + DBGPrint(" Error: does not match running process
> table (0x%p)\n", krp->p);
> + }
> + }
> +}
> +
> +#endif
> +
> void
> kdb_ps1(struct task_struct *p)
> {
> @@ -3835,6 +3900,10 @@
> void __init
> kdb_init(void)
> {
> +#if defined(CONFIG_MDB)
> + extern void mdb_init(void); +#endif
> +
> kdb_initial_cpu = smp_processor_id();
> /*
> * This must be called before any calls to kdb_printf.
> @@ -3855,6 +3924,11 @@
>
> kdb_cmd_init(); /* Preset commands from kdb_cmds */
> kdb_initial_cpu = -1; /* Avoid recursion problems */
> +
> +#if defined(CONFIG_MDB)
> + mdb_init(); +#endif
> +
> kdb(KDB_REASON_SILENT, 0, 0); /* Activate any preset
> breakpoints on boot cpu */
> kdb_initial_cpu = smp_processor_id();
> notifier_chain_register(&panic_notifier_list, &kdb_block);
>
>
Alternate Debuggers should register an init function called from
kdb_init. Calling AlternateDebuggerInterface should call all registred
debuggers
and allow each one to report status. NetWare has had an alternate
debugger interface for years. It's easy to instrument. The only thing
in Linux that's odd at all is the way GDB int3's are handled. All this
other stuff they are making you put in is not the problem of Linux.
Jeff
Jeff