-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jason Wessel wrote: > Pete/Piet Delaney wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Jason Wessel wrote: >> >>>> -----Original Message----- >>>> From: Sergei Shtylyov [mailto:[EMAIL PROTECTED] >>>> >>>>>>> + >>>>>>> if(!CHECK_EXCEPTION_STACK()) { >>>>>>> >>>> Worth fixing if stmt style while at it. :-) >>>> >>>> >>> Noted and adjusted. >>> >>> Attached are the patches to be committed to core-lite.patch in the >>> 2.6.21_uprev branch. >>> >>> Now that this is tested and confirmed to work, these will be committed >>> with in the hour. >>> >> >> I haven't read or seen a description on the purpose of the tasklet in >> the kgdb stub. I get the impression that if you want to place a >> breakpoint in early startup that it's spawned when it's too early and >> the stub defers delivering information to gdb until the kernel is able >> to process the breakpoint. >> > I posted an e-mail in the last 2 days regarding the usage of the > tasklet. In the current kgdb implementation the breakpoint tasklet has > two purposes. > > 1) The breakpoint tasklet is used by kgdboe to literally schedule a > breakpoint to happen so you can generate an exception to enter kgdb. > > 2) The during the early kgdb init a tasklet was used to in the case of > waiting for the scheduler to activate to schedule a breakpoint if the > exception stack is not setup yet, so you can enter as early as > possible. While good on paper, in practice this does not work in the > SMP x86_64 system, so it should be delayed until a late init scenario.
I don't feel like I really understand WHY it's necessary. Perhaps adding a few debug printf's and cscope the code a bit more will help my getting the big picture. The idea of "scheduling a breakpoint" seems odd, I don't recall it the kgdb-ga.patch or other kgdb, kadb, kdbx or kdb code. Also the gdb-ga.patch supported kgdboe without the need for a kgdb tasklet. >> Have any mail or a pointer on this. Before digging into it a bit more >> would be nice to have something more to read than what I saw in the >> patches and code so far. None of the other kgdb stubs, including George >> Anzinger's kgdb-ga.patch back in Andrew's mm series, have ever done >> anything this invasive. As I recall, Andy Kleen expressed concern about >> the invasiveness of the patch and was wondering about how much it help >> early debugging and why George never needed it. >> > > I am not sure what you mean by invasive? By invasive do you mean using > a tasklet, or the type of code change used to fix it? Yes, by invasive I mean using a tasklet. Andy got bent out of shape with my just using a larger stack with kgdb. Creating a tasklet is a first for kgdb stubs, even for linux 2.6. > > Today KGDB only lives in the exception context and does all its work > from there. The same was true of all the other gdb/kgdb stubs I have > seen to date. No arguement there; it's even true for network based version like HP's HPUX kgdb (KWDB) which was very comprehensive and had it's own TCP/IP stack and SSH/SSL support. Does justify using a larger stack to some extent, at least IMHO. Often compiling the kernel -O0 increases the stack size, especially on SPARC with the loss of tail optimization. I like using a 'static_inline" macro and removing inlines in the TCP/IP stack just to make back-traces a lot easier to use; but also increases the stack size. > >> I was also wondering about Bernhard Kaindl's Firewire patch from back >> in March of last year. His web site doesn't show any progress >> since then: >> >> http://www.suse.de/~bk/firewire/ >> >> A couple of weeks ago Linus said he was impressed with debugging >> via Firewire and was wondering if assimilating it might help in >> the -mm patch migration to mainline. >> >> > > The fireproxy is nice because there is not really much of anything done > to the target kernel that is being debugged. To this end aside from > debugging the kernel the implementations/goals are so radically > different that the code cannot really be integrated into the kgdb sources. Yep; reminds me of Andy's SKDB gdb proxy. Not much we can do here. I wonder if it's worth making sure adding KGDB to the mainline won't interfere with KDB and Crash. Ideally it would be optimal for a kgdb session to be able to take a core dump with KEXEC/KDUMP and then use the dump with crash without any problems. I got KEXEC to boot another kernel but had problems getting it to make a core file in 2.6.13; I'll try in in newer kernels and make sure it's note a 2.6.13 limitation. > I am open to all reasonable means to simplify KGDB. The goal as always > is to have a way to do source level debugging of modules, exceptions and > what ever faults are possible to debug without a hardware assist device. Perhaps a KGDB internals paper in linux/Documentation/ would help in folks understanding the design and need for new functionality like a kgdb proxy. The KWDB author wrote and excellent paper on it's internals. - -piet > > > Jason. > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGcJBdJICwm/rv3hoRAn2dAJ9mLgfTZizAqhjucHmsQ2DSLHOl9gCeKqDc cPwjHO5L8jLp1fuF4FI7g/0= =z+0A -----END PGP SIGNATURE----- ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Kgdb-bugreport mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport
