Zach Welch wrote: > On Mon, 2009-11-30 at 14:42 -0800, David Brownell wrote: > >> On Monday 30 November 2009, Zachary T Welch wrote: >> >>> Registers a signal handler to catch SIGSEGV in order to display the >>> stack where the program crashed. >>> >> Is this for inside OpenOCD? If so, I'd rather just expect folk >> to run inside GDB. Either they're running natively and should >> never see SEGV ... or they should be able to fire up GDB to get >> this data (and likely more). >> >> > > Not everyone wants to run GDB, and not all segfaults can be predicted. > > If you get one, it's better to have usable data than be required to > reproduce what might be a Heisenbug. I have found this feature to be > highly useful in the past, to the extent that I am not joking about > wanting to implement a libbfd version of the module symbol lookup. > This feature ensures that we can get reasonable stack traces from users, > without them having to do any extra work. Less steps for crash reports > is a Good Thing, I imagine Martha would say. > Hm - I'm with David here: I am not very fond of re-inventing parts of gdb to include it in OpenOCD.
Fully implementing this would make OpenOCD depend on libbfd just for crash reports - this is ridiculous. > Good built-in debugging facilities can be far superior to a debugger, > and the Jim scripting language adds the fun twist where OpenOCD can > expose these debug features directly to the user. You laugh now. The > first time you use one of the stack dumps that it can produce, you will > come to thank me for adding this feature. ;) Right now, I seem to find > new ways to create segfaults on a regular basis, and this makes it much > faster for me to see what has happened -- without ever running GDB. > What is the problem with running gdb? cu Michael _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
