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. > 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? 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. > 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. 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. Jason. ------------------------------------------------------------------------- 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
