From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <0a2b6d495fb105e382687ea83c531041@coraid.com> From: erik quanstrom Date: Mon, 4 Feb 2008 14:45:41 -0500 To: 9fans@cse.psu.edu Subject: Re: [9fans] 9pcf debugging In-Reply-To: <45219fb00802040818v440cfee9q71e6ac585f07fb8e@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Topicbox-Message-UUID: 44f60afc-ead3-11e9-9d60-3106f5b1d025 > I've seen there is rdbfs for debugging the 9pc kernel through a serial port... > > The computer the driver fails on doesn't have a serial port. I'd like > to the debug the ethernet driver, so I don't have ethernet. :) > > Any ideas, over the common lot-of-print() ? > > Thanks in advance. yes. we have a small embedded kernel with no user space. since it's hard to find serial these days, serial didn't seem like the best solution. so we export the segments, stack and memory as aoe targets. this won't help in the very early phases of boot, and requires a working ethernet driver. but our example is about 250 lines of code. with aoedbfs (/n/sources/contrib/quanstro/src/aoedbfs) acid or db can be used to debug the target with acid or db. with the plan 9 kernel, i think the right solution would be to put the aoe debugger in 9load. this would require the plan 9 kernel leaving 9load in core (wasting 8 mb or so) and having a mechanism for passing control back to 9load. this mechanism could replace doublefault() and be inserted into debugbpt and (on the 386) fault386. - erik p.s. there's also a program called aoesnap in /n/sources/contrib/quanstro/src that will take a snapshot of a process exporting debugging via aoe. there may be some assumptions that are unique to our situation and the code is somewhat convoluted due to the fact that we typically snapshot processes using gigabytes of memory, so the image needs to be streamed out rather than processed in a serial manner like snap. it also contains compatability goo so it compiles on linux.