PPC KGDB changes and some help?

Now, when I say that things don't quite work, here's a gdb log:
Remote debugging using /dev/ttyS0
Sending packet: $qPassSignals:0e;10;14;17;1a;1b;1c;21;24;25;4c;#df...Ack Packet received:
Packet qPassSignals (pass-signals) is NOT supported
Sending packet: $Hc-1#09...Ack
Packet received: OK
Sending packet: $qC#b4...Ack
Packet received: QC0000000000000001
Sending packet: $qOffsets#4b...Ack
Packet received:
Sending packet: $?#3f...Ack
Packet received: S05
Sending packet: $Hg1#e0...Ack
Packet received: OK
Sending packet: $g#67...Ack
Packet received:
00000001c3fddfd0c3fdb7400000002d00000448c01d4e7cffff8ae9c01d501c00007548c01 d00000000ea5fc01d00008200002200000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000004000000035303d30000 0000000000000c0003dec0000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000000000000000 000000000c002c9580002903242000028c002c9ecc00d5574000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000000000000000 0 Sending packet: $mc002c9e8,c#2a...Ack
Packet received: 4bffff513c60c0153863b1d0
0xc002c958 in breakpoint () at kernel/kgdbstub.c:1082
1082 wmb();

<< break show_cpuinfo >>

Sending packet: $qSymbol::#5b...Ack
Packet received:
Packet qSymbol (symbol-lookup) is NOT supported
Sending packet: $mc000be54,4#f0...Ack
Packet received: 9421ffd0
Sending packet: $mc000be58,4#f4...Ack
Packet received: 7c0802a6
Sending packet: $mc000be5c,4#1f...Ack
Packet received: 39600000
Sending packet: $mc000be60,4#ed...Ack
Packet received: bf410018
Sending packet: $mc000be64,4#f1...Ack
Packet received: 90010034
Sending packet: $mc000be68,4#f5...Ack
Packet received: 37e4ffff
Breakpoint 1 at 0xc000be68: file arch/ppc/kernel/setup.c, line 144.

<< continue >>

Continuing.
Sending packet: $Z0,c0000000,4#c9...Ack
Packet received: OK
Packet Z0 (software-breakpoint) is supported
Sending packet: $Z0,c000be68,4#3e...Ack
Packet received: OK
Sending packet: $Hs1#ec...Ack
Packet received:
Sending packet: $Hc0#db...Ack
Packet received: OK
Sending packet: $c#63...Ack
Packet received: S05p0000000000000001
[New Thread 1]
Sending packet: $g#67...Ack
Packet received:
00000001c3fddfd0c3fdb7400000002d00000448c01d4e7cffff8ae9c01d501c00007548c01 d00000000ea5fc01d00008200002200000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000004000000035303d30000 0000000000000c0003dec0000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000000000000000 000000000c002c9580002903242000028c002c9ecc00d5574000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000000000000000 0

Program received signal SIGTRAP, Trace/breakpoint trap. Sending packet: $mc002c9e8,c#2a...Ack
Packet received: 4bffff513c60c0153863b1d0 Sending packet: $z0,c0000000,4#e9...Ack
Packet received: OK
Sending packet: $z0,c000be68,4#5e...Ack
Packet received: OK
0xc002c958 in breakpoint () at kernel/kgdbstub.c:1082
1082 wmb();

<< continue >>

Continuing.
Sending packet: $Z0,c0000000,4#c9...Ack
Packet received: OK
Sending packet: $Z0,c000be68,4#3e...Ack
Packet received: OK
Sending packet: $c#63...Ack
Packet received: S05p0000000000000001
Sending packet: $g#67...Ack
Packet received:
00000001c3fddfd0c3fdb7400000002d00000448c01d4e7cffff8ae9c01d501c00007548c01 d00000000ea5fc01d00008200002200000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000004000000035303d30000 0000000000000c0003dec0000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000000000000000 000000000c002c9580002903242000028c002c9ecc00d5574000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000000000000000 0

Program received signal SIGTRAP, Trace/breakpoint trap. Sending packet: $mc002c9e8,c#2a...Ack
Packet received: 4bffff513c60c0153863b1d0 Sending packet: $z0,c0000000,4#e9...Ack
Packet received: OK
Sending packet: $z0,c000be68,4#5e...Ack
Packet received: OK
0xc002c958 in breakpoint () at kernel/kgdbstub.c:1082
1082 wmb();

<< quit >>

The program is running. Exit anyway? (y or n) Sending packet: $k#6b...Ack

Which leads me to wonder, has software breakpoints been tested at all? PPC allows for HW breakpoints, but in general there's only 1 or 2. And, FWIW, I have a much uglier version of things which overrides the linux_debug_hook with the working handle_exception function in ppc-stub.c, and found the same problem. Also, what I'm going to try and do next is to add support for using the HW breakpoints and see if that fixes things, or at least gets me further along.

Any pointers or ideas? Thanks.

Hi Tom,

Yes. Software breakpoints have been tested in the TimeSys ppc kernel source. They work quite well!! I'll be releasing that code soon.

Here are a couple of questions from a quick look at this code. I may have more when I do a merge this code with what I have.

Review

Quoted 2 lines

(quoted diff) +1 -1

-	bl	schedule
+	bl	user_schedule

I still have #ifdef CONFIG_KGDB_THREAD here. Threads listing is a necessary feature, agreed. Do you have any ideas on reducing the overhead of the code added by having to push all registers when doing a switch_to?

if (kgdb enabled) do a full push of registers else go to usual switch_to

Does this sound good?

From what I recall of starting on this around kgdb 2.0.2, I couldn't

Quoted 5 lines

(quoted diff) +5 -0

+        */
+#if 0
+       extern atomic_t kgdb_setting_breakpoint;
+       if (atomic_read(&kgdb_setting_breakpoint))
+               regs->nip += 4;

Review

Quoted 5 lines

(quoted diff) +5 -0

+#else
+       if (linux_regs->nip == 0x7d821008 )
+               /* Skip over breakpoint trap insn */
+               linux_regs->nip += 4;
+#endif

Why is kgdb_setting_breakpoint a bad idea?
My guess - problems on an smp board.

Hardcoded nip is worse.
Any ideas for a better code?

In following code, gdb packets and their responses appear correct. kgdb is supposed handle software breakpoints.

The breakpoint 0xc0000000 placed by gdb is _evil_ It may clobber data. The gdb at kgdb.sourceforge.net places it correctly at module_event.

Where is the other breakpoint placed? While you would have certainly done that, please confirm that kgdb actually inserts a breakpoint where you have asked it to: a simple printk at the address where the breakpoint is placed should be sufficient. printing from gdb will not work as gdb removes all breakpoints before giving control to a user.

Quoted 4 lines · Amit S. Kale

Hi Tom,

Yes. Software breakpoints have been tested in the TimeSys ppc kernel source. They work quite well!! I'll be releasing that code soon.

Any chance you can give me what they gave you? I can try and merge and test things.

Quoted 10 lines

Here are a couple of questions from a quick look at this code. I may have more when I do a merge this code with what I have.

Review

Quoted 2 lines

(quoted diff) +1 -1

-	bl	schedule
+	bl	user_schedule

I still have #ifdef CONFIG_KGDB_THREAD here. Threads listing is a necessary feature, agreed. Do you have any ideas on reducing the overhead of the code added by having to push all registers when doing a switch_to?

Quoted 3 lines

if (kgdb enabled) do a full push of registers else go to usual switch_to

Does this sound good?

From what I recall of starting on this around kgdb 2.0.2, I couldn't link the kernel w/o this change (KGDB=n).

Quoted 5 lines

Quoted 5 lines

(quoted diff) +5 -0

+        */
+#if 0
+       extern atomic_t kgdb_setting_breakpoint;
+       if (atomic_read(&kgdb_setting_breakpoint))
+               regs->nip += 4;

Quoted 8 lines

Review

Quoted 5 lines

(quoted diff) +5 -0

+#else
+       if (linux_regs->nip == 0x7d821008 )
+               /* Skip over breakpoint trap insn */
+               linux_regs->nip += 4;
+#endif

Why is kgdb_setting_breakpoint a bad idea?
My guess - problems on an smp board.

I don't know how well the current kgdb stub is tested on SMP, but it doesn't need any extra locking here.

Quoted 2 lines

Hardcoded nip is worse.
Any ideas for a better code?

I've got a feeling that the nip is always the trap instruction, so we could always do what the TimeSys code (and before that, the current stub) does of skipping over it. I used the hard-coded value there since I hadn't gotten around to re-arranging the code so I could do *(uint *)kgdb_ops->gdb_bpt_instr or so.

Quoted 5 lines

In following code, gdb packets and their responses appear correct. kgdb is supposed handle software breakpoints.

The breakpoint 0xc0000000 placed by gdb is _evil_ It may clobber data. The gdb at kgdb.sourceforge.net places it correctly at module_event.

I'm not quite sure what you're getting at. The gdb binary I'm using is
a good one (It's happy w/ the current kgdb stub, working in tandem w/ a BDI2000, etc). If the breakpoints being set aren't right, I suspect that it's related to the other problems I'm seeing.

Quoted 5 lines

Where is the other breakpoint placed? While you would have certainly done that, please confirm that kgdb actually inserts a breakpoint where you have asked it to: a simple printk at the address where the breakpoint is placed should be sufficient. printing from gdb will not work as gdb removes all breakpoints before giving control to a user.

The thing is the kernel gets into an infinite loop of stopping, as far as gdb can tell, at the initial breakpoint.

Hi,

Here it is: ppc kgdb from timesys kernel is available at
http://kgdb.sourceforge.net/kgdb-2/linux-2.6.1-kgdb-2.1.0.tar.bz2

This is my attempt at extracting kgdb from TimeSys kernel. It works well in TimeSys kernel, so blame me if above patch doesn't work.

Quoted 7 lines · Amit S. Kale

Hi,

Here it is: ppc kgdb from timesys kernel is available at
http://kgdb.sourceforge.net/kgdb-2/linux-2.6.1-kgdb-2.1.0.tar.bz2

This is my attempt at extracting kgdb from TimeSys kernel. It works well in TimeSys kernel, so blame me if above patch doesn't work.

Okay, here's my first patch against this.

Quoted 7 lines · Tom Rini

Quoted 5 lines · Amit S. Kale

Hi,

Here it is: ppc kgdb from timesys kernel is available at
http://kgdb.sourceforge.net/kgdb-2/linux-2.6.1-kgdb-2.1.0.tar.bz2

Quoted 4 lines

Quoted 2 lines

This is my attempt at extracting kgdb from TimeSys kernel. It works well in TimeSys kernel, so blame me if above patch doesn't work.

Okay, here's my first patch against this.

And dependant upon this is a patch to fixup the rest of the common PPC code, as follows:

Quoted 11 lines · Tom Rini

Quoted 10 lines · Tom Rini

Quoted 7 lines · Amit S. Kale

Hi,

Here it is: ppc kgdb from timesys kernel is available at
http://kgdb.sourceforge.net/kgdb-2/linux-2.6.1-kgdb-2.1.0.tar.bz2

This is my attempt at extracting kgdb from TimeSys kernel. It works well in TimeSys kernel, so blame me if above patch doesn't work.

Quoted 4 lines

Quoted 1 line

Okay, here's my first patch against this.

And dependant upon this is a patch to fixup the rest of the common PPC code, as follows:

And on top of all of that is the following, which allows KGDB to work on the Motorola LoPEC.

Quoted 14 lines · Tom Rini

Quoted 13 lines · Tom Rini

Quoted 11 lines · Tom Rini

Quoted 7 lines · Amit S. Kale

Hi,

Here it is: ppc kgdb from timesys kernel is available at
http://kgdb.sourceforge.net/kgdb-2/linux-2.6.1-kgdb-2.1.0.tar.bz2

This is my attempt at extracting kgdb from TimeSys kernel. It works well in TimeSys kernel, so blame me if above patch doesn't work.

Okay, here's my first patch against this.

Quoted 5 lines

Quoted 2 lines

And dependant upon this is a patch to fixup the rest of the common PPC code, as follows:

And on top of all of that is the following, which allows KGDB to work on the Motorola LoPEC.

On top of everything from yesterday, here's:

First up:
We need to call flush_instruction_cache() on a 'c' or 's' command.

 arch/ppc/kernel/ppc-stub.c |   19 ++++++-------------
 1 files changed, 6 insertions(+), 13 deletions(-)

On Thu, Jan 22, 2004 at 11:05:55AM -0700, Tom Rini wrote:
[snip]

Quoted 4 lines

First up:
We need to call flush_instruction_cache() on a 'c' or 's' command.
arch/ppc/kernel/ppc-stub.c | 19 ++++++-------------

1 files changed, 6 insertions(+), 13 deletions(-)

On tpo of this patch, there's the following:
Put back some code to figure out what signal we're dealing with.

 arch/ppc/kernel/ppc-stub.c |   63 ++++++++++++++++++++++++++++++++++++++++++---
 1 files changed, 60 insertions(+), 3 deletions(-)

arch/ppc/kernel/ppc-stub.c +60 -3

@@ -3,6 +3,7 @@
  *
  * PowerPC-specific bits to work with the common KGDB stub.
  *
+ * 1998 (c) Michael AK Tesch ([email protected])
  * 2003 (c) TimeSys Corporation
  * 2004 (c) MontaVista Software, Inc.
  * This file is licensed under the terms of the GNU General Public License

@@ -19,13 +20,69 @@
 #include <asm/processor.h>
 #include <asm/machdep.h>
 
+/* Convert the hardware trap type code to a unix signal number. */
+/*
+ * This table contains the mapping between PowerPC hardware trap types, and
+ * signals, which are primarily what GDB understands.
+ */
+static struct hard_trap_info
+{
+	unsigned int tt;		/* Trap type code for powerpc */
+	unsigned char signo;		/* Signal that we map this trap into */
+} hard_trap_info[] = {
+#if defined(CONFIG_40x)
+	{ 0x100, SIGINT  },		/* critical input interrupt */
+	{ 0x200, SIGSEGV },		/* machine check */
+	{ 0x300, SIGSEGV },		/* data storage */
+	{ 0x400, SIGBUS  },		/* instruction storage */
+	{ 0x500, SIGINT  },		/* interrupt */
+	{ 0x600, SIGBUS  },		/* alignment */
+	{ 0x700, SIGILL  },		/* program */
+	{ 0x800, SIGILL  },		/* reserved */
+	{ 0x900, SIGILL  },		/* reserved */
+	{ 0xa00, SIGILL  },		/* reserved */
+	{ 0xb00, SIGILL  },		/* reserved */
+	{ 0xc00, SIGCHLD },		/* syscall */
+	{ 0xd00, SIGILL  },		/* reserved */
+	{ 0xe00, SIGILL  },		/* reserved */
+	{ 0xf00, SIGILL  },		/* reserved */
+	{ 0x2000, SIGTRAP},		/* debug */
+#else
+	{ 0x200, SIGSEGV },		/* machine check */
+	{ 0x300, SIGSEGV },		/* address error (store) */
+	{ 0x400, SIGBUS },		/* instruction bus error */
+	{ 0x500, SIGINT },		/* interrupt */
+	{ 0x600, SIGBUS },		/* alingment */
+	{ 0x700, SIGTRAP },		/* breakpoint trap */
+	{ 0x800, SIGFPE },		/* fpu unavail */
+	{ 0x900, SIGALRM },		/* decrementer */
+	{ 0xa00, SIGILL },		/* reserved */
+	{ 0xb00, SIGILL },		/* reserved */
+	{ 0xc00, SIGCHLD },		/* syscall */
+	{ 0xd00, SIGTRAP },		/* single-step/watch */
+	{ 0xe00, SIGFPE },		/* fp assist */
+#endif
+	{ 0, 0}				/* Must be last */
+};
+
+static int computeSignal(unsigned int tt)
+{
+	struct hard_trap_info *ht;
+
+	for (ht = hard_trap_info; ht->tt && ht->signo; ht++)
+		if (ht->tt == tt)
+			return ht->signo;
+
+	return SIGHUP; /* default for things we don't know about */
+}
+
 /*
  * Routines
  */
 static void
 kgdb_debugger(struct pt_regs *regs)
 {
-	(*linux_debug_hook) (0, 0, 0, regs);
+	(*linux_debug_hook) (0, computeSignal(regs->trap), 0, regs);
 	return;
 }
 

@@ -52,14 +109,14 @@
 int
 kgdb_iabr_match(struct pt_regs *regs)
 {
-	(*linux_debug_hook) (0, 0, 0, regs);
+	(*linux_debug_hook) (0, computeSignal(regs->trap), 0, regs);
 	return 1;
 }
 
 int
 kgdb_dabr_match(struct pt_regs *regs)
 {
-	(*linux_debug_hook) (0, 0, 0, regs);
+	(*linux_debug_hook) (0, computeSignal(regs->trap), 0, regs);
 	return 1;
 }
 

Now, not being as well versed in all of the debugging infos that can be passed around, it sounds like this patch could be dropped in the future for a cleaner method using some of the dwarf2 bits being talked about. But I don't know, and clarification and pointers (if so) to how to do this would be appreciated.

Quoted 116 lines · Tom Rini

On Thu, Jan 22, 2004 at 11:05:55AM -0700, Tom Rini wrote:
[snip]

Quoted 4 lines

First up:
We need to call flush_instruction_cache() on a 'c' or 's' command.
arch/ppc/kernel/ppc-stub.c | 19 ++++++-------------

1 files changed, 6 insertions(+), 13 deletions(-)

On tpo of this patch, there's the following:
Put back some code to figure out what signal we're dealing with.

arch/ppc/kernel/ppc-stub.c | 63
++++++++++++++++++++++++++++++++++++++++++---

1 files changed, 60 insertions(+), 3 deletions(-)

arch/ppc/kernel/ppc-stub.c +4 -0

@@ -3,6 +3,7 @@
 *
 * PowerPC-specific bits to work with the common KGDB stub.
 *
+ * 1998 (c) Michael AK Tesch ([email protected])
 * 2003 (c) TimeSys Corporation
 * 2004 (c) MontaVista Software, Inc.
 * This file is licensed under the terms of the GNU General Public License

@@ -19,13 +20,69 @@
 #include <asm/processor.h>
 #include <asm/machdep.h>
 
+/* Convert the hardware trap type code to a unix signal number. */
+/*
+ * This table contains the mapping between PowerPC hardware trap types, 

and
+ * signals, which are primarily what GDB understands.
+ */

arch/ppc/kernel/ppc-stub.c +4 -0

+static struct hard_trap_info
+{
+	unsigned int tt;		/* Trap type code for powerpc */
+	unsigned char signo;		/* Signal that we map this trap into 

*/

arch/ppc/kernel/ppc-stub.c +47 -0

+} hard_trap_info[] = {
+#if defined(CONFIG_40x)
+	{ 0x100, SIGINT  },		/* critical input interrupt */
+	{ 0x200, SIGSEGV },		/* machine check */
+	{ 0x300, SIGSEGV },		/* data storage */
+	{ 0x400, SIGBUS  },		/* instruction storage */
+	{ 0x500, SIGINT  },		/* interrupt */
+	{ 0x600, SIGBUS  },		/* alignment */
+	{ 0x700, SIGILL  },		/* program */
+	{ 0x800, SIGILL  },		/* reserved */
+	{ 0x900, SIGILL  },		/* reserved */
+	{ 0xa00, SIGILL  },		/* reserved */
+	{ 0xb00, SIGILL  },		/* reserved */
+	{ 0xc00, SIGCHLD },		/* syscall */
+	{ 0xd00, SIGILL  },		/* reserved */
+	{ 0xe00, SIGILL  },		/* reserved */
+	{ 0xf00, SIGILL  },		/* reserved */
+	{ 0x2000, SIGTRAP},		/* debug */
+#else
+	{ 0x200, SIGSEGV },		/* machine check */
+	{ 0x300, SIGSEGV },		/* address error (store) */
+	{ 0x400, SIGBUS },		/* instruction bus error */
+	{ 0x500, SIGINT },		/* interrupt */
+	{ 0x600, SIGBUS },		/* alingment */
+	{ 0x700, SIGTRAP },		/* breakpoint trap */
+	{ 0x800, SIGFPE },		/* fpu unavail */
+	{ 0x900, SIGALRM },		/* decrementer */
+	{ 0xa00, SIGILL },		/* reserved */
+	{ 0xb00, SIGILL },		/* reserved */
+	{ 0xc00, SIGCHLD },		/* syscall */
+	{ 0xd00, SIGTRAP },		/* single-step/watch */
+	{ 0xe00, SIGFPE },		/* fp assist */
+#endif
+	{ 0, 0}				/* Must be last */
+};
+
+static int computeSignal(unsigned int tt)
+{
+	struct hard_trap_info *ht;
+
+	for (ht = hard_trap_info; ht->tt && ht->signo; ht++)
+		if (ht->tt == tt)
+			return ht->signo;
+
+	return SIGHUP; /* default for things we don't know about */
+}
+

/*
* Routines
*/
static void
kgdb_debugger(struct pt_regs *regs)
{

arch/ppc/kernel/ppc-stub.c +1 -1

-	(*linux_debug_hook) (0, 0, 0, regs);
+	(*linux_debug_hook) (0, computeSignal(regs->trap), 0, regs);

	return;
}

arch/ppc/kernel/ppc-stub.c +0 -0

@@ -52,14 +109,14 @@

int
kgdb_iabr_match(struct pt_regs *regs)
{

arch/ppc/kernel/ppc-stub.c +1 -1

-	(*linux_debug_hook) (0, 0, 0, regs);
+	(*linux_debug_hook) (0, computeSignal(regs->trap), 0, regs);

	return 1;
}

int
kgdb_dabr_match(struct pt_regs *regs)
{

arch/ppc/kernel/ppc-stub.c +1 -1

-	(*linux_debug_hook) (0, 0, 0, regs);
+	(*linux_debug_hook) (0, computeSignal(regs->trap), 0, regs);

	return 1;
}

Quoted 5 lines

Now, not being as well versed in all of the debugging infos that can be passed around, it sounds like this patch could be dropped in the future for a cleaner method using some of the dwarf2 bits being talked about. But I don't know, and clarification and pointers (if so) to how to do this would be appreciated.

I am not sure what this buys you. I don't think dwarf2 will help here.

There is a real danger of passing signal info back to gdb as it will want to try to deliver the signal which is a non-compute in most kgdbs in the field. I did put code in the mm-kgdb to do just this, but usually the arrival of such a signal (other than SIGTRAP) is the end of the kernel. All that is left is to read the tea leaves.

Quoted 119 lines · George Anzinger

Quoted 117 lines · Tom Rini

On Thu, Jan 22, 2004 at 11:05:55AM -0700, Tom Rini wrote:
[snip]

Quoted 4 lines

First up:
We need to call flush_instruction_cache() on a 'c' or 's' command.
arch/ppc/kernel/ppc-stub.c | 19 ++++++-------------

1 files changed, 6 insertions(+), 13 deletions(-)

On tpo of this patch, there's the following:
Put back some code to figure out what signal we're dealing with.

arch/ppc/kernel/ppc-stub.c | 63
++++++++++++++++++++++++++++++++++++++++++---

1 files changed, 60 insertions(+), 3 deletions(-)

arch/ppc/kernel/ppc-stub.c +4 -0

@@ -3,6 +3,7 @@
 *
 * PowerPC-specific bits to work with the common KGDB stub.
 *
+ * 1998 (c) Michael AK Tesch ([email protected])
 * 2003 (c) TimeSys Corporation
 * 2004 (c) MontaVista Software, Inc.
 * This file is licensed under the terms of the GNU General Public License

@@ -19,13 +20,69 @@
 #include <asm/processor.h>
 #include <asm/machdep.h>
 
+/* Convert the hardware trap type code to a unix signal number. */
+/*
+ * This table contains the mapping between PowerPC hardware trap types, 

and
+ * signals, which are primarily what GDB understands.
+ */

arch/ppc/kernel/ppc-stub.c +4 -0

+static struct hard_trap_info
+{
+	unsigned int tt;		/* Trap type code for powerpc */
+	unsigned char signo;		/* Signal that we map this trap into 

*/

arch/ppc/kernel/ppc-stub.c +47 -0

+} hard_trap_info[] = {
+#if defined(CONFIG_40x)
+	{ 0x100, SIGINT  },		/* critical input interrupt */
+	{ 0x200, SIGSEGV },		/* machine check */
+	{ 0x300, SIGSEGV },		/* data storage */
+	{ 0x400, SIGBUS  },		/* instruction storage */
+	{ 0x500, SIGINT  },		/* interrupt */
+	{ 0x600, SIGBUS  },		/* alignment */
+	{ 0x700, SIGILL  },		/* program */
+	{ 0x800, SIGILL  },		/* reserved */
+	{ 0x900, SIGILL  },		/* reserved */
+	{ 0xa00, SIGILL  },		/* reserved */
+	{ 0xb00, SIGILL  },		/* reserved */
+	{ 0xc00, SIGCHLD },		/* syscall */
+	{ 0xd00, SIGILL  },		/* reserved */
+	{ 0xe00, SIGILL  },		/* reserved */
+	{ 0xf00, SIGILL  },		/* reserved */
+	{ 0x2000, SIGTRAP},		/* debug */
+#else
+	{ 0x200, SIGSEGV },		/* machine check */
+	{ 0x300, SIGSEGV },		/* address error (store) */
+	{ 0x400, SIGBUS },		/* instruction bus error */
+	{ 0x500, SIGINT },		/* interrupt */
+	{ 0x600, SIGBUS },		/* alingment */
+	{ 0x700, SIGTRAP },		/* breakpoint trap */
+	{ 0x800, SIGFPE },		/* fpu unavail */
+	{ 0x900, SIGALRM },		/* decrementer */
+	{ 0xa00, SIGILL },		/* reserved */
+	{ 0xb00, SIGILL },		/* reserved */
+	{ 0xc00, SIGCHLD },		/* syscall */
+	{ 0xd00, SIGTRAP },		/* single-step/watch */
+	{ 0xe00, SIGFPE },		/* fp assist */
+#endif
+	{ 0, 0}				/* Must be last */
+};
+
+static int computeSignal(unsigned int tt)
+{
+	struct hard_trap_info *ht;
+
+	for (ht = hard_trap_info; ht->tt && ht->signo; ht++)
+		if (ht->tt == tt)
+			return ht->signo;
+
+	return SIGHUP; /* default for things we don't know about */
+}
+

/*
* Routines
*/
static void
kgdb_debugger(struct pt_regs *regs)
{

arch/ppc/kernel/ppc-stub.c +1 -1

-	(*linux_debug_hook) (0, 0, 0, regs);
+	(*linux_debug_hook) (0, computeSignal(regs->trap), 0, regs);

	return;
}

arch/ppc/kernel/ppc-stub.c +0 -0

@@ -52,14 +109,14 @@

int
kgdb_iabr_match(struct pt_regs *regs)
{

arch/ppc/kernel/ppc-stub.c +1 -1

-	(*linux_debug_hook) (0, 0, 0, regs);
+	(*linux_debug_hook) (0, computeSignal(regs->trap), 0, regs);

	return 1;
}

int
kgdb_dabr_match(struct pt_regs *regs)
{

arch/ppc/kernel/ppc-stub.c +1 -1

-	(*linux_debug_hook) (0, 0, 0, regs);
+	(*linux_debug_hook) (0, computeSignal(regs->trap), 0, regs);

	return 1;
}

Quoted 7 lines

Quoted 5 lines

Now, not being as well versed in all of the debugging infos that can be passed around, it sounds like this patch could be dropped in the future for a cleaner method using some of the dwarf2 bits being talked about. But I don't know, and clarification and pointers (if so) to how to do this would be appreciated.

I am not sure what this buys you. I don't think dwarf2 will help here.

OK.

Quoted 1 line

There is a real danger of passing signal info back to gdb as it will want to try to deliver the signal which is a non-compute in most kgdbs in the field. I did put code in the mm-kgdb to do just this, but usually the arrival of such a signal (other than SIGTRAP) is the end of the kernel. All that is left is to read the tea leaves.

The gdb I've been testing this with knows better than to try and send a singal back, so that's not a worry. The motivation behind doing this however is along the lines of "if it ain't broke, don't remove it". The original stub was getting all of this information correctly, so why stop doing it?

Quoted 140 lines · Tom Rini

Quoted 119 lines · George Anzinger

Quoted 117 lines · Tom Rini

On Thu, Jan 22, 2004 at 11:05:55AM -0700, Tom Rini wrote:
[snip]

Quoted 4 lines

First up:
We need to call flush_instruction_cache() on a 'c' or 's' command.
arch/ppc/kernel/ppc-stub.c | 19 ++++++-------------

1 files changed, 6 insertions(+), 13 deletions(-)

On tpo of this patch, there's the following:
Put back some code to figure out what signal we're dealing with.

arch/ppc/kernel/ppc-stub.c | 63
++++++++++++++++++++++++++++++++++++++++++---

1 files changed, 60 insertions(+), 3 deletions(-)

arch/ppc/kernel/ppc-stub.c +4 -0

@@ -3,6 +3,7 @@
 *
 * PowerPC-specific bits to work with the common KGDB stub.
 *
+ * 1998 (c) Michael AK Tesch ([email protected])
 * 2003 (c) TimeSys Corporation
 * 2004 (c) MontaVista Software, Inc.
 * This file is licensed under the terms of the GNU General Public License

@@ -19,13 +20,69 @@
 #include <asm/processor.h>
 #include <asm/machdep.h>
 
+/* Convert the hardware trap type code to a unix signal number. */
+/*
+ * This table contains the mapping between PowerPC hardware trap types, 

and
+ * signals, which are primarily what GDB understands.
+ */

arch/ppc/kernel/ppc-stub.c +4 -0

+static struct hard_trap_info
+{
+	unsigned int tt;		/* Trap type code for powerpc */
+	unsigned char signo;		/* Signal that we map this trap into 

*/

arch/ppc/kernel/ppc-stub.c +47 -0

+} hard_trap_info[] = {
+#if defined(CONFIG_40x)
+	{ 0x100, SIGINT  },		/* critical input interrupt */
+	{ 0x200, SIGSEGV },		/* machine check */
+	{ 0x300, SIGSEGV },		/* data storage */
+	{ 0x400, SIGBUS  },		/* instruction storage */
+	{ 0x500, SIGINT  },		/* interrupt */
+	{ 0x600, SIGBUS  },		/* alignment */
+	{ 0x700, SIGILL  },		/* program */
+	{ 0x800, SIGILL  },		/* reserved */
+	{ 0x900, SIGILL  },		/* reserved */
+	{ 0xa00, SIGILL  },		/* reserved */
+	{ 0xb00, SIGILL  },		/* reserved */
+	{ 0xc00, SIGCHLD },		/* syscall */
+	{ 0xd00, SIGILL  },		/* reserved */
+	{ 0xe00, SIGILL  },		/* reserved */
+	{ 0xf00, SIGILL  },		/* reserved */
+	{ 0x2000, SIGTRAP},		/* debug */
+#else
+	{ 0x200, SIGSEGV },		/* machine check */
+	{ 0x300, SIGSEGV },		/* address error (store) */
+	{ 0x400, SIGBUS },		/* instruction bus error */
+	{ 0x500, SIGINT },		/* interrupt */
+	{ 0x600, SIGBUS },		/* alingment */
+	{ 0x700, SIGTRAP },		/* breakpoint trap */
+	{ 0x800, SIGFPE },		/* fpu unavail */
+	{ 0x900, SIGALRM },		/* decrementer */
+	{ 0xa00, SIGILL },		/* reserved */
+	{ 0xb00, SIGILL },		/* reserved */
+	{ 0xc00, SIGCHLD },		/* syscall */
+	{ 0xd00, SIGTRAP },		/* single-step/watch */
+	{ 0xe00, SIGFPE },		/* fp assist */
+#endif
+	{ 0, 0}				/* Must be last */
+};
+
+static int computeSignal(unsigned int tt)
+{
+	struct hard_trap_info *ht;
+
+	for (ht = hard_trap_info; ht->tt && ht->signo; ht++)
+		if (ht->tt == tt)
+			return ht->signo;
+
+	return SIGHUP; /* default for things we don't know about */
+}
+

/*
* Routines
*/
static void
kgdb_debugger(struct pt_regs *regs)
{

arch/ppc/kernel/ppc-stub.c +1 -1

-	(*linux_debug_hook) (0, 0, 0, regs);
+	(*linux_debug_hook) (0, computeSignal(regs->trap), 0, regs);

	return;
}

arch/ppc/kernel/ppc-stub.c +0 -0

@@ -52,14 +109,14 @@

int
kgdb_iabr_match(struct pt_regs *regs)
{

arch/ppc/kernel/ppc-stub.c +1 -1

-	(*linux_debug_hook) (0, 0, 0, regs);
+	(*linux_debug_hook) (0, computeSignal(regs->trap), 0, regs);

	return 1;
}

int
kgdb_dabr_match(struct pt_regs *regs)
{

arch/ppc/kernel/ppc-stub.c +1 -1

-	(*linux_debug_hook) (0, 0, 0, regs);
+	(*linux_debug_hook) (0, computeSignal(regs->trap), 0, regs);

	return 1;
}

Quoted 7 lines

Quoted 5 lines

Now, not being as well versed in all of the debugging infos that can be passed around, it sounds like this patch could be dropped in the future for a cleaner method using some of the dwarf2 bits being talked about. But I don't know, and clarification and pointers (if so) to how to do this would be appreciated.

I am not sure what this buys you. I don't think dwarf2 will help here.

OK.

Quoted 5 lines

There is a real danger of passing signal info back to gdb as it will want to try to deliver the signal which is a non-compute in most kgdbs in the field. I did put code in the mm-kgdb to do just this, but usually the arrival of such a signal (other than SIGTRAP) is the end of the kernel. All that is left is to read the tea leaves.

Quoted 6 lines

The gdb I've been testing this with knows better than to try and send a singal back, so that's not a worry. The motivation behind doing this however is along the lines of "if it ain't broke, don't remove it". The original stub was getting all of this information correctly, so why stop doing it?

OK, but I still don't like losing the return address. Tell me again, why do you need three different functions all doing the same thing?

Quoted 46 lines

Quoted 46 lines

Quoted 30 lines

Quoted 30 lines

+
/*
* Routines
*/
static void
kgdb_debugger(struct pt_regs *regs)
{

(quoted diff) +1 -1

-	(*linux_debug_hook) (0, 0, 0, regs);
+	(*linux_debug_hook) (0, computeSignal(regs->trap), 0, regs);

	return;
}

(quoted diff) +0 -0

@@ -52,14 +109,14 @@

int
kgdb_iabr_match(struct pt_regs *regs)
{

(quoted diff) +1 -1

-	(*linux_debug_hook) (0, 0, 0, regs);
+	(*linux_debug_hook) (0, computeSignal(regs->trap), 0, regs);

	return 1;
}

int
kgdb_dabr_match(struct pt_regs *regs)
{

(quoted diff) +1 -1

-	(*linux_debug_hook) (0, 0, 0, regs);
+	(*linux_debug_hook) (0, computeSignal(regs->trap), 0, regs);

	return 1;
}

Quoted 7 lines

Quoted 5 lines

Now, not being as well versed in all of the debugging infos that can be passed around, it sounds like this patch could be dropped in the future for a cleaner method using some of the dwarf2 bits being talked about. But I don't know, and clarification and pointers (if so) to how to do this would be appreciated.

I am not sure what this buys you. I don't think dwarf2 will help here.

OK.

Quoted 1 line

There is a real danger of passing signal info back to gdb as it will want to try to deliver the signal which is a non-compute in most kgdbs in the field. I did put code in the mm-kgdb to do just this, but usually the arrival of such a signal (other than SIGTRAP) is the end of the kernel. All that is left is to read the tea leaves.

Quoted 8 lines

Quoted 6 lines

The gdb I've been testing this with knows better than to try and send a singal back, so that's not a worry. The motivation behind doing this however is along the lines of "if it ain't broke, don't remove it". The original stub was getting all of this information correctly, so why stop doing it?

OK, but I still don't like losing the return address. Tell me again, why do you need three different functions all doing the same thing?

You get:
- kgdb_breakpoint => debugger_bpt : This is how the various PPC codes drop you into KGDB.
- kgdb_iabr_match => debugger_iabr_match : Called from InstructionBreakpoint, exception.
- kgdb_dabr_match => debugger_dabr_match : Called from do_page_fault, this is a Data Access Breakpoint Register match.

So we need at least 2 for the KGDB side of things (prototypes) and 3 just to make it clear.

Quoted 2 lines

There is a real danger of passing signal info back to gdb as it will want to try to deliver the signal which is a non-compute in most kgdbs in the field. I did put code in the mm-kgdb to do just this, but usually the arrival of such a signal (other than SIGTRAP) is the end of the kernel. All that is left is to read the tea leaves.

The gdb I've been testing this with knows better than to try and send a singal back, so that's not a worry. The motivation behind doing this however is along the lines of "if it ain't broke, don't remove it". The original stub was getting all of this information correctly, so why stop doing it?

Quoted 8 lines · Tom Rini

Quoted 6 lines

There is a real danger of passing signal info back to gdb as it will want to try to deliver the signal which is a non-compute in most kgdbs in the field. I did put code in the mm-kgdb to do just this, but usually the arrival of such a signal (other than SIGTRAP) is the end of the kernel. All that is left is to read the tea leaves.

Quoted 6 lines

The gdb I've been testing this with knows better than to try and send a singal back, so that's not a worry. The motivation behind doing this however is along the lines of "if it ain't broke, don't remove it". The original stub was getting all of this information correctly, so why stop doing it?

You sure. If so what gdb? And how does it know? I suppose you could tell it with a script, but then what if one forgets?

Quoted 7 lines · George Anzinger

Quoted 6 lines · Tom Rini

Quoted 5 lines

There is a real danger of passing signal info back to gdb as it will want to try to deliver the signal which is a non-compute in most kgdbs in the field. I did put code in the mm-kgdb to do just this, but usually the arrival of such a signal (other than SIGTRAP) is the end of the kernel. All that is left is to read the tea leaves.

Quoted 8 lines

Quoted 5 lines

The gdb I've been testing this with knows better than to try and send a singal back, so that's not a worry. The motivation behind doing this however is along the lines of "if it ain't broke, don't remove it". The original stub was getting all of this information correctly, so why stop doing it?

You sure. If so what gdb? And how does it know? I suppose you could tell it with a script, but then what if one forgets?

GNU gdb 6.0 (MontaVista 6.0-8.0.4.0300532 2003-12-24) Copyright 2003 Free Software Foundation, Inc. [snip]

[New Thread 289]

Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 289]
0x00000000 in ?? ()
(gdb) c
Continuing.
Can't send signals to this remote system. SIGSEGV not sent.

Noting that 0x0 is correct as the code that triggered this was:
static void (*dummy)(struct pt_regs *regs);

int drop_kgdb(void) {
        struct pt_regs regs;
        memset(&regs, 0, sizeof(regs));
        dummy(&regs);

        return 0;
}

module_init(drop_kgdb);

--
Tom Rini
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

On Thu, Jan 22, 2004 at 11:05:55AM -0700, Tom Rini wrote:
[snip]

Quoted 4 lines

First up:
We need to call flush_instruction_cache() on a 'c' or 's' command.

 arch/ppc/kernel/ppc-stub.c |   19 ++++++-------------
 1 files changed, 6 insertions(+), 13 deletions(-)

On tpo of this patch, there's the following:
Put back some code to figure out what signal we're dealing with.

Quoted 7 lines · Tom Rini

Quoted 5 lines · Amit S. Kale

Hi,

Here it is: ppc kgdb from timesys kernel is available at
http://kgdb.sourceforge.net/kgdb-2/linux-2.6.1-kgdb-2.1.0.tar.bz2

Quoted 4 lines

Quoted 2 lines

This is my attempt at extracting kgdb from TimeSys kernel. It works well in TimeSys kernel, so blame me if above patch doesn't work.

Okay, here's my first patch against this.

And dependant upon this is a patch to fixup the rest of the common PPC code, as follows:

Quoted 11 lines · Tom Rini

Quoted 6 lines · Amit S. Kale

Hi,

Here it is: ppc kgdb from timesys kernel is available at
http://kgdb.sourceforge.net/kgdb-2/linux-2.6.1-kgdb-2.1.0.tar.bz2

This is my attempt at extracting kgdb from TimeSys kernel. It works well in TimeSys kernel, so blame me if above patch doesn't work.

Okay, here's my first patch against this.

And dependant upon this is a patch to fixup the rest of the common PPC code, as follows:
- Add FRAME_POINTER
- Put the bits of kgdbppc_init into ppc_kgdb_init.
- None of the gen550 stuffs depend on CONFIG_8250_SERIAL directly, remove that constraint.
- Add missing bits like debuggerinfo, BREAKPOINT, etc.
- Add a kgdb_map_scc machdep pointer.

arch/ppc/Kconfig +0 -0

@@ -1405,6 +1405,14 @@
 	  Say Y here only if you plan to use some sort of debugger to

Quoted 37 lines · Tom Rini

Quoted 5 lines · Tom Rini

Quoted 2 lines · Amit S. Kale

Hi,

Quoted 7 lines

Quoted 5 lines

Here it is: ppc kgdb from timesys kernel is available at
http://kgdb.sourceforge.net/kgdb-2/linux-2.6.1-kgdb-2.1.0.tar.bz2

This is my attempt at extracting kgdb from TimeSys kernel. It works well in TimeSys kernel, so blame me if above patch doesn't work.

Okay, here's my first patch against this.

And dependant upon this is a patch to fixup the rest of the common PPC code, as follows:
- Add FRAME_POINTER
- Put the bits of kgdbppc_init into ppc_kgdb_init.
- None of the gen550 stuffs depend on CONFIG_8250_SERIAL directly, remove that constraint.
- Add missing bits like debuggerinfo, BREAKPOINT, etc.
- Add a kgdb_map_scc machdep pointer.

arch/ppc/Kconfig +5 -0

@@ -1405,6 +1405,14 @@
 	  Say Y here only if you plan to use some sort of debugger to
 	  debug the kernel.
 	  If you don't debug the kernel, you can say N.
+
+config FRAME_POINTER
+	bool "Compile the kernel with frame pointers"
+	help
+	  If you say Y here the resulting kernel image will be slightly 

larger

arch/ppc/Kconfig line 1415

Quoted 4 lines

arch/ppc/Kconfig +2 -0

+	  and slower, but it will give very useful debugging information.
+	  If you don't debug the kernel, you can say N, but we may not be 

able

arch/ppc/Kconfig +1 -0

+	  to solve problems without frame pointers.

This is fast becoming old hat. If you compile with dwarf debug info, you not only get more reliable frame info, but you do not need frame pointers. Gdb is almost there. The languages have already arrived.

A question I have been meaning to ask: Why is the arch/common connection via a structure of addresses instead of just calls? I seems to me that just calling is a far cleaner way to do things here. All the struct seems to offer is a way to change the backend on the fly. I don't thing we ever want to do that. Am I missing something?

Quoted 5 lines · George Anzinger

A question I have been meaning to ask: Why is the arch/common connection via a structure of addresses instead of just calls? I seems to me that just calling is a far cleaner way to do things here. All the struct seems to offer is a way to change the backend on the fly. I don't thing we ever want to do that. Am I missing something?

I imagine it's a style thing. I don't have a preference either way.

Quoted 13 lines · Tom Rini

Quoted 9 lines · George Anzinger

A question I have been meaning to ask: Why is the arch/common connection
via a structure of addresses instead of just calls? I seems to me that
just calling is a far cleaner way to do things here. All the struct seems
to offer is a way to change the backend on the fly. I don't thing we ever
want to do that. Am I missing something?

Quoted 1 line

I imagine it's a style thing. I don't have a preference either way.

I think we in PPC land have gotten used to that "style" because we have one kernel that supports different "platforms", i.e. it selects the appropriate code at runtime as George says. In general that's a little bit slower and a little bit bigger.

Unless you need to choose among PPC KGDB functions at runtime, which I don't think you do, you don't need it...

Quoted 19 lines · Hollis Blanchard

Quoted 11 lines · Tom Rini

Quoted 9 lines · George Anzinger

A question I have been meaning to ask: Why is the arch/common connection
via a structure of addresses instead of just calls? I seems to me that
just calling is a far cleaner way to do things here. All the struct seems
to offer is a way to change the backend on the fly. I don't thing we ever
want to do that. Am I missing something?

Quoted 1 line

I imagine it's a style thing. I don't have a preference either way.

I think we in PPC land have gotten used to that "style" because we have one kernel that supports different "platforms", i.e. it selects the appropriate code at runtime as George says. In general that's a little bit slower and a little bit bigger.

Quoted 2 lines

Unless you need to choose among PPC KGDB functions at runtime, which I don't think you do, you don't need it...

That's certainly true, so if (and if I understand Georges question right) Amit wants to change kgdb_arch into a set of required functions, with stubs in, say, kernel/kgdbdummy.c, (and just keep the flags / etc in the struct), that's fine with me.

Quoted 20 lines · Tom Rini

Quoted 19 lines · Hollis Blanchard

Quoted 11 lines · Tom Rini

Quoted 9 lines · George Anzinger

A question I have been meaning to ask: Why is the arch/common connection
via a structure of addresses instead of just calls? I seems to me that
just calling is a far cleaner way to do things here. All the struct seems
to offer is a way to change the backend on the fly. I don't thing we ever
want to do that. Am I missing something?

Quoted 1 line

I imagine it's a style thing. I don't have a preference either way.

I think we in PPC land have gotten used to that "style" because we have one kernel that supports different "platforms", i.e. it selects the appropriate code at runtime as George says. In general that's a little bit slower and a little bit bigger.

Quoted 7 lines

Quoted 2 lines

Unless you need to choose among PPC KGDB functions at runtime, which I don't think you do, you don't need it...

That's certainly true, so if (and if I understand Georges question right) Amit wants to change kgdb_arch into a set of required functions, with stubs in, say, kernel/kgdbdummy.c, (and just keep the flags / etc in the struct), that's fine with me.

The penalty of keeping them consolidated in a structure isn't so high. I prefer to keep them that way. I'll work on reducing number of initialization functions, though.

I have to do something about early connect though. Powerpc kgdb on 8260 is definitely capable of starting debugging right at architecture setup time. It's just that kgdbstub.c isn't ready yet.

How about changing the code in kgdbstub to allow kgdb to be configured in one of the following ways:
Late kgdb - kgdb comes up after smp_init in the kernel boot sequence. kgdb8250 can be used with more flexibility through kernel command line options. One can boot a kgdb kernel without activating kgdb. Works with the interface chosen by kernel command line (kgdb8250 and kgdbeth for the moment).

Early kgdb - kgdb comes up right at the begining of start_kernel at the cost of flexibility. It doesn't show any messages such as "waiting for gdb". All configurations have to be compiled in through menuconfig. Once a kernel is built, it'll always run with kgdb and with 8250 at a fixed port and speed.

i386 architecture will support both kgdb configuration.
KGDB in powerpc 8260 will be of early kgdb type. Other powerpc arches (550 etc will depend on whether the interface can be initialized early or later)

FWIW, this is true of KGDB on all PPCs. IIRC, so long as the serial definitions are filled out statically, the stub currently in kernel.org for PPC can do first-line-of-C already.

Quoted 2 lines

How about changing the code in kgdbstub to allow kgdb to be configured in one of the following ways:
Late kgdb - kgdb comes up after smp_init in the kernel boot sequence. kgdb8250 can be used with more flexibility through kernel command line options. One can boot a kgdb kernel without activating kgdb. Works with the interface chosen by kernel command line (kgdb8250 and kgdbeth for the moment).

Which is basically how it goes now, right?

Quoted 1 line

Early kgdb - kgdb comes up right at the begining of start_kernel at the cost of flexibility. It doesn't show any messages such as "waiting for gdb".

Quoted 14 lines · Tom Rini

FWIW, this is true of KGDB on all PPCs. IIRC, so long as the serial definitions are filled out statically, the stub currently in kernel.org for PPC can do first-line-of-C already.

Quoted 7 lines

How about changing the code in kgdbstub to allow kgdb to be configured in one of the following ways:
Late kgdb - kgdb comes up after smp_init in the kernel boot sequence. kgdb8250 can be used with more flexibility through kernel command line options. One can boot a kgdb kernel without activating kgdb. Works with the interface chosen by kernel command line (kgdb8250 and kgdbeth for the moment).

A further thought on this. I think kgdb should take control on oops, panic and other bad news things. This without being anthing but configured in. Thus the command line options to set up the interface, etc, should not automatically connect to gdb.

Quoted 12 lines · George Anzinger

Quoted 9 lines · Tom Rini

FWIW, this is true of KGDB on all PPCs. IIRC, so long as the serial definitions are filled out statically, the stub currently in kernel.org for PPC can do first-line-of-C already.

Quoted 2 lines

How about changing the code in kgdbstub to allow kgdb to be configured in one of the following ways:
Late kgdb - kgdb comes up after smp_init in the kernel boot sequence. kgdb8250 can be used with more flexibility through kernel command line options. One can boot a kgdb kernel without activating kgdb. Works with the interface chosen by kernel command line (kgdb8250 and kgdbeth for the moment).

Quoted 1 line

A further thought on this. I think kgdb should take control on oops, panic and other bad news things. This without being anthing but configured in. Thus the command line options to set up the interface, etc, should not automatically connect to gdb.

*confused look* it doesn't do this already on i386? I'm fairly certain that it does on PPC, regardless of the stub (since I've got this wierd panic happening on my testbox right now, but kgdb is kicking in..)

Quoted 23 lines · Tom Rini

Quoted 21 lines · Hollis Blanchard

Quoted 12 lines · Tom Rini

Quoted 9 lines · George Anzinger

A question I have been meaning to ask: Why is the arch/common connection
via a structure of addresses instead of just calls? I seems to me that
just calling is a far cleaner way to do things here. All the struct seems
to offer is a way to change the backend on the fly. I don't thing we ever
want to do that. Am I missing something?

Quoted 1 line

I imagine it's a style thing. I don't have a preference either way.

I think we in PPC land have gotten used to that "style" because we have one kernel that supports different "platforms", i.e. it selects the appropriate code at runtime as George says. In general that's a little bit slower and a little bit bigger.

Quoted 7 lines

Quoted 2 lines

Unless you need to choose among PPC KGDB functions at runtime, which I don't think you do, you don't need it...

That's certainly true, so if (and if I understand Georges question right) Amit wants to change kgdb_arch into a set of required functions, with stubs in, say, kernel/kgdbdummy.c, (and just keep the flags / etc in the struct), that's fine with me.

The penalty of keeping them consolidated in a structure isn't so high. I prefer to keep them that way. I'll work on reducing number of initialization functions, though.

I have to do something about early connect though. Powerpc kgdb on 8260 is definitely capable of starting debugging right at architecture setup time. It's just that kgdbstub.c isn't ready yet.

How about changing the code in kgdbstub to allow kgdb to be configured in one of the following ways:
Late kgdb - kgdb comes up after smp_init in the kernel boot sequence. kgdb8250 can be used with more flexibility through kernel command line options. One can boot a kgdb kernel without activating kgdb. Works with the interface chosen by kernel command line (kgdb8250 and kgdbeth for the moment).

Command line flexibilty is of great help if you have to test on 2-3 servers (I used to do that a lot at Veritas). The same kernel can be compiled with drivers needed by all of them plus kgdb. Command line options choose port no and speeds depending on machine hardware connections. I guess it's of little use on embedded systems where usually a new kernel has to be compiled for each board.

Early kgdb - kgdb comes up right at the begining of start_kernel at the cost of flexibility. It doesn't show any messages such as "waiting for gdb". All configurations have to be compiled in through menuconfig. Once a kernel is built, it'll always run with kgdb and with 8250 at a fixed port and speed.

i386 architecture will support both kgdb configuration.
KGDB in powerpc 8260 will be of early kgdb type. Other powerpc arches (550 etc will depend on whether the interface can be initialized early or later)

Quoted 23 lines · Tom Rini

Quoted 21 lines · Hollis Blanchard

Quoted 11 lines · Tom Rini

Quoted 9 lines · George Anzinger

A question I have been meaning to ask: Why is the arch/common connection
via a structure of addresses instead of just calls? I seems to me that
just calling is a far cleaner way to do things here. All the struct seems
to offer is a way to change the backend on the fly. I don't thing we ever
want to do that. Am I missing something?

Quoted 1 line

I imagine it's a style thing. I don't have a preference either way.

I think we in PPC land have gotten used to that "style" because we have one kernel that supports different "platforms", i.e. it selects the appropriate code at runtime as George says. In general that's a little bit slower and a little bit bigger.

Unless you need to choose among PPC KGDB functions at runtime, which I don't think you do, you don't need it...

Quoted 4 lines

That's certainly true, so if (and if I understand Georges question right) Amit wants to change kgdb_arch into a set of required functions, with stubs in, say, kernel/kgdbdummy.c, (and just keep the flags / etc in the struct), that's fine with me.

The penalty of keeping them consolidated in a structure isn't so high. I prefer to keep them that way. I'll work on reducing number of initialization functions, though.

Quoted 15 lines · Hollis Blanchard

Quoted 10 lines · Tom Rini

Quoted 5 lines · George Anzinger

A question I have been meaning to ask: Why is the arch/common connection via a structure of addresses instead of just calls? I seems to me that just calling is a far cleaner way to do things here. All the struct seems to offer is a way to change the backend on the fly. I don't thing we ever want to do that. Am I missing something?

I imagine it's a style thing. I don't have a preference either way.

I think we in PPC land have gotten used to that "style" because we have one kernel that supports different "platforms", i.e. it selects the appropriate code at runtime as George says. In general that's a little bit slower and a little bit bigger.

Quoted 1 line

Unless you need to choose among PPC KGDB functions at runtime, which I don't think you do, you don't need it...

That's certainly true, so if (and if I understand Georges question right) Amit wants to change kgdb_arch into a set of required functions, with stubs in, say, kernel/kgdbdummy.c, (and just keep the flags / etc in the struct), that's fine with me.

Quoted 7 lines · Tom Rini

Quoted 5 lines · Amit S. Kale

Hi,

Here it is: ppc kgdb from timesys kernel is available at
http://kgdb.sourceforge.net/kgdb-2/linux-2.6.1-kgdb-2.1.0.tar.bz2

Quoted 4 lines

Quoted 2 lines

This is my attempt at extracting kgdb from TimeSys kernel. It works well in TimeSys kernel, so blame me if above patch doesn't work.

Okay, here's my first patch against this.

And dependant upon this is a patch to fixup the rest of the common PPC code, as follows:

Quoted 12 lines · Tom Rini

Quoted 10 lines · Tom Rini

Quoted 7 lines · Amit S. Kale

Hi,

Here it is: ppc kgdb from timesys kernel is available at
http://kgdb.sourceforge.net/kgdb-2/linux-2.6.1-kgdb-2.1.0.tar.bz2

This is my attempt at extracting kgdb from TimeSys kernel. It works well in TimeSys kernel, so blame me if above patch doesn't work.

Okay, here's my first patch against this.

Quoted 2 lines

And dependant upon this is a patch to fixup the rest of the common PPC code, as follows:

Relative to this, due to the PPC changes is the following:

- In kgdb_handle_exception, memset remcomOutBuffer twice, instead of continiously throwing in NULLs around.

- Remove a KERN_CRIT from the printk while waiting for kgdb to connect (it's not needed there).

- Switch the initial packet from an 'S' packet (followed by a p for the thread ID) to a 'T' packet.

This is tested on PPC and i386 (lightly).

 include/asm-i386/kgdb.h   |    4 ++
 include/asm-ppc/kgdb.h    |    3 +
 include/asm-x86_64/kgdb.h |    4 ++
 kernel/kgdbstub.c         |   70

++++++++++++++++++++++------------------------ 4 files changed, 45 insertions(+), 36 deletions(-)

include/asm-i386/kgdb.h +4 -0

@@ -43,6 +43,10 @@
 	_GS    /* 15 */
 };
 
+#define PC_REGNUM	_PC	/* Program Counter */
+#define SP_REGNUM	_ESP	/* Stack Pointer */
+#define PTRACE_PC	eip	/* Program Counter, in ptrace regs. */
+
 #define BREAKPOINT() asm("   int $3");
 #define BREAK_INSTR_SIZE       1
 

include/asm-ppc/kgdb.h +3 -0

@@ -19,6 +19,9 @@
 #define NUMREGBYTES		(MAXREG * sizeof(int))
 #define BUFMAX			((NUMREGBYTES * 2) + 512)
 #define OUTBUFMAX		((NUMREGBYTES * 2) + 512)
+#define PC_REGNUM		64
+#define SP_REGNUM		1
+#define PTRACE_PC		nip	/* Program Counter, in ptrace regs. */
 #define BREAKPOINT()		asm(".long 0x7d821008") /* twge r2, r2 */
 
 /* Things specific to the gen550 backend. */

include/asm-x86_64/kgdb.h +4 -0

@@ -44,6 +44,10 @@
 	       _PS,
 	       _LASTREG=_PS };
 
+#define PC_REGNUM	_PC	/* Program Counter */
+#define SP_REGNUM	_RSP	/* Stack Pointer */
+#define PTRACE_PC	rip	/* Program Counter, in ptrace regs. */
+
 /* Number of bytes of registers.  */
 #define NUMREGBYTES (_LASTREG*8)
 

kernel/kgdbstub.c +34 -37

@@ -615,6 +615,9 @@
 	 * need one here */
 	procindebug[smp_processor_id()] = 1;
 
+	/* Clear the out buffer. */
+	memset(remcomOutBuffer, 0, sizeof(remcomOutBuffer));
+
 	/* Master processor is completely in the debugger */
 	if (kgdb_ops->post_master_code)
 		kgdb_ops->post_master_code(linux_regs, exVector, err_code);

@@ -624,9 +627,7 @@
 		if(remcomInBuffer[0] == 'H' && remcomInBuffer[1] =='c') {
 			remove_all_break();
 			atomic_set(&kgdb_killed_or_detached, 0);
-			remcomOutBuffer[0] = 'O';
-			remcomOutBuffer[1] = 'K';
-			remcomOutBuffer[2] = 0;
+			strcpy(remcomOutBuffer, "OK");
 		}
 		else
 			return 1;

@@ -634,13 +635,25 @@
 	else {
 
 		/* reply to host that an exception has occurred */
-		remcomOutBuffer[0] = 'S';
-		remcomOutBuffer[1] = hexchars[signo >> 4];
-		remcomOutBuffer[2] = hexchars[signo % 16];
-		remcomOutBuffer[3] = 'p';
-
+		ptr = remcomOutBuffer;
+		*ptr++ = 'T';
+		*ptr++ = hexchars[(signo >> 4) % 16];
+		*ptr++ = hexchars[signo % 16];
+		*ptr++ = hexchars[(PC_REGNUM >> 4) % 16];
+		*ptr++ = hexchars[PC_REGNUM % 16];
+		*ptr++ = ':';
+		ptr = kgdb_mem2hex((char *)&linux_regs->PTRACE_PC, ptr, 4, 0);
+		*ptr++ = ';';
+		*ptr++ = hexchars[SP_REGNUM >> 4];
+		*ptr++ = hexchars[SP_REGNUM & 0xf];
+		*ptr++ = ':';
+		ptr = kgdb_mem2hex(((char *)linux_regs) + SP_REGNUM * 4, ptr,
+				4, 0);
+		*ptr++ = ';';
+		ptr += strlen(strcpy(ptr, "thread:"));
 		int_to_threadref(&thref, shadow_pid(current->pid));
-		*pack_threadid(remcomOutBuffer + 4, &thref) = 0;
+		ptr = pack_threadid(ptr, &thref);
+		*ptr++ = ';';
 	}
 	putpacket(remcomOutBuffer, 0);
 	kgdb_connected = 1;

@@ -651,8 +664,10 @@
 	while (1) {
 		int bpt_type = 0;
 		error = 0;
-		remcomOutBuffer[0] = 0;
-		remcomOutBuffer[1] = 0;
+
+		/* Clear the out buffer. */
+		memset(remcomOutBuffer, 0, sizeof(remcomOutBuffer));
+
 		getpacket(remcomInBuffer);
 
 #if KGDB_DEBUG

@@ -666,7 +681,6 @@
 			remcomOutBuffer[0] = 'S';
 			remcomOutBuffer[1] = hexchars[signo >> 4];
 			remcomOutBuffer[2] = hexchars[signo % 16];
-			remcomOutBuffer[3] = 0;
 			break;
 
 		case 'g':	/* return the value of the CPU registers */

@@ -764,9 +778,7 @@
 			 * continue.
 			 */
 		case 'D':
-			remcomOutBuffer[0] = 'O';
-			remcomOutBuffer[1] = 'K';
-			remcomOutBuffer[2] = '\0';
+			strcpy(remcomOutBuffer, "OK");
 			remove_all_break();
 			putpacket(remcomOutBuffer, 0);
 			kgdb_connected = 0;

@@ -804,19 +816,16 @@
 						i++;
 					}
 				}
-				*(--ptr) = '\0';
 				break;
 
 			case 'C':
 				/* Current thread id */
-				remcomOutBuffer[0] = 'Q';
-				remcomOutBuffer[1] = 'C';
+				strcpy(remcomOutBuffer, "QC");
 
 				threadid = shadow_pid(current->pid);
 
 				int_to_threadref(&thref, threadid);
 				pack_threadid(remcomOutBuffer + 2, &thref);
-				remcomOutBuffer[18] = '\0';
 				break;
 
 			case 'E':

@@ -829,7 +838,6 @@
 			case 'T':
 				if (memcmp(remcomInBuffer+1, "ThreadExtraInfo,",16))
 				{
-					remcomOutBuffer[0] = 0;
 					strcpy(remcomOutBuffer, "E05");
 					break;
 				}

@@ -872,14 +880,11 @@
 				thread = getthread(linux_regs, threadid);
 				if (!thread && threadid > 0) {
 					remcomOutBuffer[0] = 'E';
-					remcomOutBuffer[1] = '\0';
 					break;
 				}
 				kgdb_usethread = thread;
 				kgdb_usethreadid = threadid;
-				remcomOutBuffer[0] = 'O';
-				remcomOutBuffer[1] = 'K';
-				remcomOutBuffer[2] = '\0';
+				strcpy(remcomOutBuffer, "OK");
 				break;
 
 			case 'c':

@@ -892,14 +897,11 @@
 					thread = getthread(linux_regs, threadid);
 					if (!thread && threadid > 0) {
 						remcomOutBuffer[0] = 'E';
-						remcomOutBuffer[1] = '\0';
 						break;
 					}
 					kgdb_contthread = thread;
 				}
-				remcomOutBuffer[0] = 'O';
-				remcomOutBuffer[1] = 'K';
-				remcomOutBuffer[2] = '\0';
+				strcpy(remcomOutBuffer, "OK");
 				break;
 			}
 			break;

@@ -909,14 +911,10 @@
 			ptr = &remcomInBuffer[1];
 			kgdb_hexToLong(&ptr, &threadid);
 			thread = getthread(linux_regs, threadid);
-			if (thread) {
-				remcomOutBuffer[0] = 'O';
-				remcomOutBuffer[1] = 'K';
-				remcomOutBuffer[2] = '\0';
-			} else {
+			if (thread)
+				strcpy(remcomOutBuffer, "OK");
+			else
 				remcomOutBuffer[0] = 'E';
-				remcomOutBuffer[1] = '\0';
-			}
 			break;
 		case 'z':
 		case 'Z':

@@ -1127,7 +1125,7 @@
 	 */
 	printk(KERN_CRIT "Waiting for connection from remote gdb... ");
 	breakpoint() ;
-	printk(KERN_CRIT "Connected.\n");
+	printk("Connected.\n");
 }
 
 #ifdef CONFIG_KGDB_CONSOLE
 
--

Tom Rini
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Quoted 6 lines · Amit S. Kale

Hi,

Here it is: ppc kgdb from timesys kernel is available at
http://kgdb.sourceforge.net/kgdb-2/linux-2.6.1-kgdb-2.1.0.tar.bz2

This is my attempt at extracting kgdb from TimeSys kernel. It works well in TimeSys kernel, so blame me if above patch doesn't work.

Okay, here's my first patch against this.
===== kernel/kgdbstub.c 1.1 vs edited =====

kernel/kgdbstub.c +5 -3

@@ -1058,9 +1058,6 @@
 	kgdb_serial->write_char('+');
 
 	linux_debug_hook = kgdb_handle_exception;
-	
-	if (kgdb_ops->kgdb_init)
-		kgdb_ops->kgdb_init();
 
 	/* We can't do much if this fails */
 	register_module_notifier(&kgdb_module_load_nb);

@@ -1104,6 +1101,11 @@
 	if (!kgdb_enter) {
 		return;
 	}
+
+	/* Let the arch do any initalization it needs to */
+	if (kgdb_ops->kgdb_init)
+		kgdb_ops->kgdb_init();
+
 	if (!kgdb_serial) {
 		printk("KGDB: no gdb interface available.\n"
 		       "kgdb can't be enabled\n");

I'm not sure why you were calling the arch-specific init so late in the process, but since it's a nop on both i386 and x86_64 (so perhaps it should be removed for both of these?), this change doesn't matter to them. But it does make the PPC code cleaner, IMHO.

Quoted 39 lines · Tom Rini

Quoted 7 lines · Amit S. Kale

Hi,

Here it is: ppc kgdb from timesys kernel is available at
http://kgdb.sourceforge.net/kgdb-2/linux-2.6.1-kgdb-2.1.0.tar.bz2

This is my attempt at extracting kgdb from TimeSys kernel. It works well in TimeSys kernel, so blame me if above patch doesn't work.

Okay, here's my first patch against this.
===== kernel/kgdbstub.c 1.1 vs edited =====

kernel/kgdbstub.c +5 -3

@@ -1058,9 +1058,6 @@
 	kgdb_serial->write_char('+');
 
 	linux_debug_hook = kgdb_handle_exception;
-	
-	if (kgdb_ops->kgdb_init)
-		kgdb_ops->kgdb_init();
 
 	/* We can't do much if this fails */
 	register_module_notifier(&kgdb_module_load_nb);

@@ -1104,6 +1101,11 @@
 	if (!kgdb_enter) {
 		return;
 	}
+
+	/* Let the arch do any initalization it needs to */
+	if (kgdb_ops->kgdb_init)
+		kgdb_ops->kgdb_init();
+
 	if (!kgdb_serial) {
 		printk("KGDB: no gdb interface available.\n"
 		       "kgdb can't be enabled\n");

Quoted 4 lines

I'm not sure why you were calling the arch-specific init so late in the process, but since it's a nop on both i386 and x86_64 (so perhaps it should be removed for both of these?), this change doesn't matter to them. But it does make the PPC code cleaner, IMHO.

I agree. Lets dump all the init calls/code. I have not seen anything yet that can not be done as a side effect of the first call, or better yet, at compile time.

I am willing to be shown a valid case, however. Remember, I want to be able to do a breakpoint() as the first line of C code in the kernel. (works with the mm kgdb).

Quoted 4 lines · Amit S. Kale

Hi Tom,

Yes. Software breakpoints have been tested in the TimeSys ppc kernel source. They work quite well!! I'll be releasing that code soon.

Any chance you can give me what they gave you? I can try and merge and test things.

Quoted 2 lines

The breakpoint 0xc0000000 placed by gdb is _evil_ It may clobber data. The gdb at kgdb.sourceforge.net places it correctly at module_event.

I'm not quite sure what you're getting at. The gdb binary I'm using is
a good one (It's happy w/ the current kgdb stub, working in tandem w/ a BDI2000, etc). If the breakpoints being set aren't right, I suspect that it's related to the other problems I'm seeing.

Quoted 6 lines

Where is the other breakpoint placed? While you would have certainly done that, please confirm that kgdb actually inserts a breakpoint where you have asked it to: a simple printk at the address where the breakpoint is placed should be sufficient. printing from gdb will not work as gdb removes all breakpoints before giving control to a user.

The thing is the kernel gets into an infinite loop of stopping, as far as gdb can tell, at the initial breakpoint

Review

Quoted 3 lines

(quoted diff) +3 -0

+       if (linux_regs->nip == 0x7d821008 )
+               /* Skip over breakpoint trap insn */
+               linux_regs->nip += 4;

Review

Quoted 3 lines

(quoted diff) +3 -0

+       extern atomic_t kgdb_setting_breakpoint;
+       if (atomic_read(&kgdb_setting_breakpoint))
+               regs->nip += 4;

Quoted 8 lines · Tom Rini

Quoted 4 lines · Amit S. Kale

Hi Tom,

Yes. Software breakpoints have been tested in the TimeSys ppc kernel source. They work quite well!! I'll be releasing that code soon.

Any chance you can give me what they gave you? I can try and merge and test things.

Done.

Quoted 7 lines

Quoted 2 lines

The breakpoint 0xc0000000 placed by gdb is _evil_ It may clobber data. The gdb at kgdb.sourceforge.net places it correctly at module_event.

I'm not quite sure what you're getting at. The gdb binary I'm using is
a good one (It's happy w/ the current kgdb stub, working in tandem w/ a BDI2000, etc). If the breakpoints being set aren't right, I suspect that it's related to the other problems I'm seeing.

Stock gdb places a breakpoint to detect loading of shared libraries. Since kernel doesn't have the symbols that ld-linux-* has, it places that at begining of the kernel (or elsewhere I haven't been able to figure out exactly where it places it). This breakpoint corrupts kernel data many a times.

The gdb I maintain at kgdb.sourceforge.net places a breakpoint correctly at module_event and detects loading of modules.

Quoted 8 lines

Quoted 5 lines

Where is the other breakpoint placed? While you would have certainly done that, please confirm that kgdb actually inserts a breakpoint where you have asked it to: a simple printk at the address where the breakpoint is placed should be sufficient. printing from gdb will not work as gdb removes all breakpoints before giving control to a user.

The thing is the kernel gets into an infinite loop of stopping, as far as gdb can tell, at the initial breakpoint

I thought you could place a breakpoint somewhere and the breakpoint was never hit.

ok. Now I know where it went wrong: nip is instruction pointer, not instruction contents. The change you had done compared nip to breakpoint instruction contents.

Quoted 3 lines

Review

Quoted 3 lines

(quoted diff) +3 -0

+       if (linux_regs->nip == 0x7d821008 )
+               /* Skip over breakpoint trap insn */
+               linux_regs->nip += 4;

Checking for kgdb_setting_breakpoint is better. Following code from my patch is correct.

Quoted 3 lines

Quoted 3 lines

(quoted diff) +3 -0

+       extern atomic_t kgdb_setting_breakpoint;
+       if (atomic_read(&kgdb_setting_breakpoint))
+               regs->nip += 4;

I tried to collect some documents related to linux and ppc. And did some document(I'm not yet confident enough to say: kernel analysis) about linux ppc machine dependent part.

It's far away being good. But wish helpful and
meantime get some feedback so that I could make a
better job.

The ToC is:
-------------
Chapter 1 Embedded PowerPC Family
Chapter 2: Programming Model
Chapter 3: PowerPC EABI
Chapter 4: PowerPC Interrupt/Exception
Chapter 5: PowerPC 4xx Reset and Initialization
Chapter 6: Synchronization Requirements
Chapter 7: Linux Kernel Bootup and Initialization

Chapter 8: Kernel Initialization
Chapter 9: Kernel Setup---start_kernel
Chapter 10: Kernel Exception Handler
Chapter 11 Kernel Memory Management
Chapter 12: Kernel Process Management
Chapter 13 Interrupt Handling routines
Chapter 14 System Call handling
Chapter 15: PowerPC EABI Cross Compiler

Hi, team,

I tried to collect some documents related to linux and
ppc. And did some document(I'm not yet confident enough to say: kernel analysis) about linux ppc machine dependent part.

It's far away being good. But wish helpful and
meantime get some feedback so that I could make a
better job.

The ToC is:
-------------
Chapter 1 Embedded PowerPC Family
Chapter 2: Programming Model
Chapter 3: PowerPC EABI
Chapter 4: PowerPC Interrupt/Exception
Chapter 5: PowerPC 4xx Reset and Initialization
Chapter 6: Synchronization Requirements
Chapter 7: Linux Kernel Bootup and Initialization
Chapter 8: Kernel Initialization
Chapter 9: Kernel Setup---start_kernel
Chapter 10: Kernel Exception Handler
Chapter 11 Kernel Memory Management
Chapter 12: Kernel Process Management
Chapter 13 Interrupt Handling routines
Chapter 14 System Call handling
Chapter 15: PowerPC EABI Cross Compiler

Regards,

Huailin, Chen
www.xtrj.org