Re: [PATCH][0/6] A different KGDB stub

[Tom Rini]

On Wed, Feb 11, 2004 at 04:27:56PM -0800, Andrew Morton wrote:

> Tom Rini <trini@xxxxxxxxxxxxxxxxxxx> wrote:
> >
> > Hi Andrew.  As a reply to this message, I'm going to send you patches to
> > replace George's KGDB with a version that is Amit Kale's work, with a
> > number of additional cleanups (that I'll put in his CVS ASAP).  There
> > are 6 different patches:
> > core.patch: All of the non-arch specific bits, that aren't drivers.
> > 8250.patch: The i/o driver for KGDB, via a standard PC uart.
> > kgdboe.patch: The i/o driver for KGDB, via netpoll.
> > i386.patch: The i386-specific code, tested.
> > ppc32.patch: The ppc32-specific code, tested.
> > x86_64.patch: The x86_64-specific bits, untested.
> 
> OK.
> 
> > With this, there's a few design questions I have.  First, as I've done
> > things right now, a breakpoint at the first line of C code is untested.
> > It should work, but I have a question of how we want to handle setting
> > up the pointer to our i/o functions (if we have a pointer).  There's a
> > couple of ways that this could be solved, with pros and cons.  For
> > example, if we want to allow for both serial and enet to be used in the
> > same kernel, we could default to setting this pointer to the 8250
> > version, and allow for kgdb_arch_init to override (as PPC sometimes
> > does).  This is what I've done for now, but I don't know if I like how
> > it looks or not. If we don't care about allowing for > 1 i/o driver, we
> > can simply drop kgdb_serial as a function pointer and just call
> > kgdb_getDebugChar/kgdb_putDebugChar/etc.  Or someone else can suggest an
> > better way.
> 
> I don't think runtime selection is very important, personally.  You tend to
> get things set up with a serial cable or ethernet and just leave it that
> way.  Given that you need to recompile the kernel anyway, I'd say that
> Kconfig-time selection is acceptable.

I'll start on that then.

> > Next, what features of George's version are a must-have?  And what that
> > we have now, can we drop?  For example, up until I started working on
> > kgdboe+netpoll, I found KGBB_CONSOLE quite handy.  Now, I'm very happy
> > with netconsole, so I don't have a strong attachment to KGDB_CONSOLE
> > anymore.  But it's not much code anyhow.  And of course, what could be
> > done better?
> 
> I use KGDB_CONSOLE occasionally, although that's only when I can't stomach
> the thought of using minicom ;)
> 
> A few things which I believe have debatable value are:
> 
> CONFIG_KGDB_MORE
> CONFIG_KGDB_OPTIONS
> CONFIG_NO_KGDB_CPUS
> CONFIG_KGDB_TS
> CONFIG_STACK_OVERFLOW_TEST
> CONFIG_KGDB_SYSRQ		(Just turn it on by default?)
> 
> I have never used (or, as far as I know, needed) any of the above.

I think CONFIG_KGDB_SYSRQ can die since with the 8250 and enet drivers
you can try and connect at any point, which will schedule a breakpoint
and you can get in like that.  As for NO_KGDB_CPUS, I'm not entirely
certain why this can't go away and there'd be an array of NR_CPUS in
size.

-- 
Tom Rini
http://gate.crashing.org/~trini/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/