From: "Amit S. Kale" <amitkale@emsyssoft.com>
To: Tom Rini <trini@kernel.crashing.org>
Cc: Powerpc Linux <linuxppc-dev@lists.linuxppc.org>
Subject: Re: PPC KGDB changes and some help?
Date: Wed, 21 Jan 2004 22:31:45 +0530 [thread overview]
Message-ID: <200401212231.45601.amitkale@emsyssoft.com> (raw)
In-Reply-To: <20040121153019.GR13454@stop.crashing.org>
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/
next prev parent reply other threads:[~2004-01-21 17:01 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20040120172708.GN13454@stop.crashing.org>
2004-01-21 14:16 ` PPC KGDB changes and some help? Amit S. Kale
2004-01-21 15:30 ` Tom Rini
2004-01-21 16:53 ` Amit S. Kale
2004-01-21 18:42 ` Tom Rini
2004-01-21 19:21 ` Tom Rini
2004-01-21 19:22 ` Tom Rini
2004-01-22 17:44 ` Tom Rini
2004-01-22 18:05 ` Tom Rini
2004-01-23 22:46 ` Tom Rini
2004-01-23 23:38 ` George Anzinger
2004-01-26 20:46 ` Tom Rini
2004-01-26 21:27 ` George Anzinger
2004-01-26 21:42 ` Tom Rini
2004-01-26 22:35 ` George Anzinger
2004-01-26 21:45 ` George Anzinger
2004-01-26 22:06 ` Tom Rini
2004-01-27 9:05 ` Amit S. Kale
2004-01-24 0:48 ` George Anzinger
2004-01-24 3:47 ` [PATCH] Kgdb dwarf2 for asm George Anzinger
2004-01-27 18:22 ` PPC KGDB changes and some help? Tom Rini
2004-01-21 22:03 ` Tom Rini
2004-01-21 23:12 ` George Anzinger
2004-01-22 15:07 ` Tom Rini
2004-01-22 15:25 ` Hollis Blanchard
2004-01-22 15:45 ` Tom Rini
2004-01-22 16:06 ` Amit S. Kale
2004-01-22 16:45 ` Tom Rini
2004-01-22 22:46 ` George Anzinger
2004-01-22 22:52 ` Tom Rini
2004-01-22 23:09 ` George Anzinger
2004-01-22 22:35 ` George Anzinger
2004-01-23 17:08 ` Tom Rini
2004-01-22 21:54 ` George Anzinger
2004-01-26 21:32 ` Tom Rini
2004-01-27 8:59 ` Amit S. Kale
2004-01-21 23:05 ` George Anzinger
2004-01-22 15:03 ` Tom Rini
2004-01-21 17:01 ` Amit S. Kale [this message]
2004-01-21 17:08 ` Tom Rini
2004-01-22 1:13 ` FYI: Free Online Book: Inside Linux Kernel and PowerPC Huailin Chen
2004-01-22 15:42 ` Hollis Blanchard
2004-01-22 18:43 ` URL: " Huailin Chen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200401212231.45601.amitkale@emsyssoft.com \
--to=amitkale@emsyssoft.com \
--cc=linuxppc-dev@lists.linuxppc.org \
--cc=trini@kernel.crashing.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.