Re: PPC KGDB changes and some help?

Re: PPC KGDB changes and some help?

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

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.

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


> +        */
> +#if 0
> +       extern atomic_t kgdb_setting_breakpoint;
> +       if (atomic_read(&kgdb_setting_breakpoint))
> +               regs->nip += 4;
> +#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.

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

--
Amit Kale
EmSysSoft (http://www.emsyssoft.com)
KGDB: Linux Kernel Source Level Debugger (http://kgdb.sourceforge.net)


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

Re: PPC KGDB changes and some help?

[Tom Rini]

On Wed, Jan 21, 2004 at 07:46:17PM +0530, Amit S. Kale wrote:

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

> 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.
>
> > -	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
link the kernel w/o this change (KGDB=n).

> > +        */
> > +#if 0
> > +       extern atomic_t kgdb_setting_breakpoint;
> > +       if (atomic_read(&kgdb_setting_breakpoint))
> > +               regs->nip += 4;
> > +#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.

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

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

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

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

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

Re: PPC KGDB changes and some help?

[Amit S. Kale]

On Wednesday 21 Jan 2004 9:00 pm, Tom Rini wrote:
> On Wed, Jan 21, 2004 at 07:46:17PM +0530, Amit S. Kale wrote:
> > 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.


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

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

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

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

--
Amit Kale
EmSysSoft (http://www.emsyssoft.com)
KGDB: Linux Kernel Source Level Debugger (http://kgdb.sourceforge.net)


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

Re: PPC KGDB changes and some help?

[Tom Rini]

On Wed, Jan 21, 2004 at 10:31:45PM +0530, Amit S. Kale wrote:
> On Wednesday 21 Jan 2004 9:00 pm, Tom Rini wrote:
> > On Wed, Jan 21, 2004 at 07:46:17PM +0530, Amit S. Kale wrote:
> > > 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.
>
>
> > > 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.

Ah, ok.

> > > 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.
>
> > > +       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.
>
> > > +       extern atomic_t kgdb_setting_breakpoint;
> > > +       if (atomic_read(&kgdb_setting_breakpoint))
> > > +               regs->nip += 4;

I could have sworn I tried a number of combinations of things, including
that.  But I'm grabbing 2.1.0 now and will get back to you.

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

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

FYI: Free Online Book: Inside Linux Kernel and PowerPC

[Huailin Chen]

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

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

Re: FYI: Free Online Book: Inside Linux Kernel and PowerPC

[Hollis Blanchard]

On Jan 21, 2004, at 7:13 PM, Huailin Chen wrote:
>
> 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

Are you saying you intend to write a book, and do we have comments on
the proposed ToC? Or that you have begun writing a book, and the
content is online somewhere and you'd like comments? Or that it's
already written? If there's anything more than a ToC to look at, please
provide a URL. :)

--
Hollis Blanchard
IBM Linux Technology Center


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

URL: FYI: Free Online Book: Inside Linux Kernel and PowerPC

[Huailin Chen]

Faint. I forgot give out the url. Thanks guys for
point me out:-).

----------------
www.xtrj.org/ppc
----------------



--- Huailin Chen <chen_huailin@yahoo.com> wrote:
>
> 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
>
>


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