On Jul 11, 2013, at 4:05 PM, Artem Belevich <a...@freebsd.org> wrote: > > It would probably work for most of the crashes, but will not work in few > interesting classes of failure. Using in-kernel stack implicitly assumes that > your memory allocator still works as both the stack and the interface driver > will need to get their mbufs and other data somewhere. Alas it's those > unusual cases that are hardest to debug and where you really do want debugger > or coredump to work. > > Back at my previous work we did it 'embedded system way'. Interface driver > provided dumb functions to re-init device, send a frame and poll for received > frame. All that without using system malloc. There was a dumb malloc that > gave few chunks of memory from static buffer to gzip, but the rest of the > code was independent of any kernel facilities. We had simple > ARP/IP/UDP/TFTP(+gzip) implementation to upload compressed image of physical > memory to a specified server. Overall it worked pretty well.
That's the exact reason why we invented our own mini stack and hooks into the network driver. After many failure cases, you can no longer rely on malloc, interrupts, routing tables or other goodies to be working correctly. It's too easy for the rest of the system to be broken enough that touching any of those pieces was enough to crash again. It really depends on the scope of problem you're trying to debug, but at minimum I think you need to revert to polled networking, disable all interrupts, and use your own stack/memory pool. Even then it's still not foolproof, but at least then you spend less time trying to debug your debugger.
smime.p7s
Description: S/MIME cryptographic signature
