On Tue, 12 Feb 2008 19:20:24 +0100 Andi Kleen <andi@firstfloor.org> wrote:Yes. A stopped CPU is very visible and hence can change the behaviour of the system which is being tested. I don't think you'd want to be poking around in kernel internals while some of the CPUs are continuing to run. It sounds rather creepy. You want everything to stop. Including time-related things. Bear in mind that one of the things you do with kgdb is to modify kernel memory - I'd do things like int foo; ... if (foo == 1) special_stuff(); ... to trigger a particular behaviour at a particular time. If you're making multiple changes, you want them "atomic" wrt all CPUs. (Of course, if you happeed to breakpoint one CPU while it was partway through reading multiple locations, you lose. But that's a teeny window). OT: another thing you can do with kgdb is error-path testing: foo = kmalloc(...) BP-> if (!foo) recover(); put a breakpoint on the !foo test and set foo to zero by hand. --
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Ingo Molnar | Re: [RFT] x86 acpi: normalize segment descriptor register on resume |
| Andrew Morton | -mm merge plans for 2.6.23 |
| Greg Kroah-Hartman | [PATCH 004/196] Chinese: add translation of SubmittingPatches |
git: | |
| Gerrit Renker | [PATCH 15/37] dccp: Set per-connection CCIDs via socket options |
| David Miller | Re: [GIT]: Networking |
| David Miller | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Ingo Molnar | [bug] stuck localhost TCP connections, v2.6.26-rc3+ |
