Re: [KGDB PATCH][7/7] Move debugger_entry()

From: George Anzinger
Date: Thu Mar 11 2004 - 17:51:14 EST


Tom Rini wrote:
On Thu, Mar 11, 2004 at 01:24:59PM -0800, George Anzinger wrote:

Amit S. Kale wrote:

On Wednesday 03 Mar 2004 6:38 am, George Anzinger wrote:


Amit S. Kale wrote:


OK to checkin.

-Amit

On Saturday 28 Feb 2004 3:24 am, Tom Rini wrote:


Hello. When we use kgdboe, we can't use it until do_basic_setup() is
done. So we have two options, not allow kgdboe to use the initial
breakpoint or move debugger_entry() to be past the point where kgdboe
will be usable. I've opted for the latter, as if an earlier breakpoint
is needed you can still use serial and throw
kgdb_schedule_breakpoint/breakpoint where desired.

--- linux-2.6.3-rc4/init/main.c 2004-02-17 09:51:19.000000000 -0700
+++ linux-2.6.3-rc4-kgdb/init/main.c 2004-02-17 11:33:51.854388988 -0700
@@ -581,6 +582,7 @@ static int init(void * unused)

smp_init();
do_basic_setup();
+ debugger_entry();

It would be nice to not need this. Could it be a side effect of
configuring the interface or some such so we don't have to patch
init/main.c


I attempted doing this when I was trying to code a netpoll independent ethernet interface. I couldn't do without it. I needed one hook to kgdb in init to mark completion of smp_init. If an interface was ready, that hook called breakpoint. A similar hook was placed in interface initialization code, it called breakpoint, if kgdb core was ready on account of smp_init completion.


I guess the real question is why do you need to wait so long? What is it that needs to be done prior to this call?


For kgdboe, you need to wait for the ethernet driver, networking, etc.
Without going and trying to do some big special case, that's when it has
to be, for kgdboe.

For serial, esp if you make kgdb_arch_init() handle kgdb_serial pointer,
it can happen much earlier. In fact, in that case you could probably
throw breakpoint() in as first line of C (PPC32) or close to it (some
mappings needed i386, sh, others, generally speaking).

So the question is do we cater to the worst or the best? If I put kgdb or what ever on the command line, I would like to see the connection ASAP what ever the connection is. So possibly, the command line parse part of kgdb sets a flag it it can not do the break NOW. The late bloomer code finds this flag when doing the kgdboe or what ever set up and enters at that time. Puts a little more smarts in the command line part, but gets things rolling ASAP regardless of the interface. This, of course, assumes that the kgdboe or what ever has an independent way of getting entered as soon as it can be set up, i.e. its prerequisites are satisfied.


--
George Anzinger george@xxxxxxxxxx
High-res-timers: http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml

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