From: Tom Rini <trini@kernel.crashing.org>
To: "Amit S. Kale" <amitkale@emsyssoft.com>
Cc: Kernel Mailing List <linux-kernel@vger.kernel.org>,
George Anzinger <george@mvista.com>, Pavel Machek <pavel@suse.cz>,
Andrew Morton <akpm@osdl.org>,
jim.houston@comcast.net,
Powerpc Linux <linuxppc-dev@lists.linuxppc.org>
Subject: Re: setjmp/longjmp hooks for kgdb 2.0.2
Date: Mon, 19 Jan 2004 08:09:16 -0700 [thread overview]
Message-ID: <20040119150916.GC13454@stop.crashing.org> (raw)
In-Reply-To: <200401171207.54506.amitkale@emsyssoft.com>
On Sat, Jan 17, 2004 at 12:07:54PM +0530, Amit S. Kale wrote:
> On Friday 16 Jan 2004 9:27 pm, Tom Rini wrote:
> > On Thu, Jan 15, 2004 at 10:52:30AM +0530, Amit S. Kale wrote:
> > > Hi Tom,
> > >
> > > It's nice to see someone working on integrating powerpc kgdb with
> > > mainline kgdb. There are a lot of features (like thread lists, gdb
> > > deatch-reattach, automodule loading) powerpc kgdb will inherit
> > > automatically from common core.
> > >
> > > setjmp, longjmp isn't required. search_exception_tables take care of
> > > invalid memory accesses by kgdb.
> > >
> > > In arch/ppc/mm/fault.c:do_page_fault, call bad_page_fault if
> > > debugger_memerr_expected is non-zero instead of holding mmap_sem.
> > >
> > > bad_page_fault calls search_exception_tables at the begining. It takes
> > > care of invalid memory addresses by kgdb as kgdb uses get_user, put_user
> > > to access memory when the access can fail.
> >
> > OK, thanks.
> >
> > > For powerpc arch specific code (like entry.S) look at
> > > http://kgdb.sourceforge.net/linux-2.4.23-kgdb-1.9.patch
> > > It contains powerpc arch specific code for kgdb. I was never able to test
> > > this code, so I don't know whether it works.
> >
> > It might work on some subset of machines, but the serial driver is still
> > broken for SERIAL_IO_MEM machines (which there are a lot of) nor is the
> > ppc 8xx (which is what I would assume TimeSys used) serial driver
> > patched up.
>
> Yes. There is a lot of #ifdef CONFIG_KGDB code in their
> arch/ppc/8260_io/uart.c If your ppc machine uses the same uart, please let me
> know and I'll send you this file.
Ah, that explains it.
> Which test machine do you have?
What I've got locally are a Motorola LoPEC and Motorola Sandpoint (both
with ns1655x UARTs) and an Embedded Planet RPXLite (MPC8xx with a
similar UART to the 8260 variant). But I'm doing this with my
MontaVista hat on, so in the end I'm going to try and test it on
everything that's not a powermac/chrp (more or less).
--
Tom Rini
http://gate.crashing.org/~trini/
prev parent reply other threads:[~2004-01-19 15:09 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-14 16:50 setjmp/longjmp hooks for kgdb 2.0.2 Tom Rini
2004-01-15 5:22 ` Amit S. Kale
2004-01-16 15:57 ` Tom Rini
2004-01-17 6:37 ` Amit S. Kale
2004-01-19 15:09 ` Tom Rini [this message]
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=20040119150916.GC13454@stop.crashing.org \
--to=trini@kernel.crashing.org \
--cc=akpm@osdl.org \
--cc=amitkale@emsyssoft.com \
--cc=george@mvista.com \
--cc=jim.houston@comcast.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.linuxppc.org \
--cc=pavel@suse.cz \
/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.