On 2011-10-18 15:30, Richard W.M. Jones wrote: > On Tue, Oct 18, 2011 at 12:47:23PM +0200, Jan Kiszka wrote: >> On 2011-10-18 12:41, Paolo Bonzini wrote: >>> On 10/18/2011 10:39 AM, Jan Kiszka wrote: >>>>>> >>>>>> Yeah, I see. Could also be solved via gdb scripts, but crash is already >>>>>> there. >>>> [ BTW, crash is for the dead. But having those features in form of gdb >>>> scripts would also allow live system analysis. Looks like it's worth >>>> obsoleting crash on the long run. ] >>> >>> Crash can also do live system analysis. :) >> >> Does it work via remote interface? And it's still the wrong way around: >> You have to append "gdb" to the majority of command when doing debugging >> instead of issuing additional analysis commands from the gdb shell. >> That's understandable given the limited scripting power of old gdbs. But >> that's now history thanks to its python interface. > > Before this conversation heads any further into the realm of > absurdity, let's get back to the key requirements for production > systems: > > (A) No development tools can be installed. > > (B) The core file must be removed from the production system quickly > and analyzed by on another machine (indeed, often by experts from > another company entirely). > > Anything that involves live debugging using GDB is simply not > acceptable for production systems, whether you think that's right or > not.
My memory is usually that bad, but not in this case. :) This discussion should also work out a bigger picture than just your (valid) scenario. We should look at meeting that requirements but also see what would be a useful foundation for future extensions like having post-crash analysis and live debugging at a similar feature level with very similar or (much better) identical tools. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
