On Tue, 2009-12-01 at 21:57 +0100, Andreas Fritiofson wrote: > On Tue, Dec 1, 2009 at 10:32 AM, Zach Welch <[email protected]> wrote: > > On Tue, 2009-12-01 at 10:25 +0100, Øyvind Harboe wrote: > >> On Tue, Dec 1, 2009 at 10:17 AM, Zach Welch <[email protected]> wrote: > >> > On Tue, 2009-12-01 at 09:45 +0100, Øyvind Harboe wrote: > >> >> > 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. > >> >> > >> >> If something like this was added, it should not create any > >> >> dependencies or do anything remotely exotic. > >> >> > >> >> How about adding an option to statically link with GDB or create > >> >> a script that launched OpenOCD via GDB as default? > >> > > >> > No one was talking about linking with GDB. That's just insane. ;) > >> > libbfd is part of binutils. But again it should be_optional. > >> > >> OK. Explain the benefit of complicating OpenOCD vs. adding a script > >> to launch OpenOCD via GDB then... > > > > Seriously... you've never had a Heisenbug either? Am I the only one > > that gets segfaults and doesn't _want_ to have to debug them? Really? > > Isn't running with core dumps enabled a far simpler method to catch > those one-off crashes than keeping (and maintaining!) a bunch of code > in-tree to do essentially the same, but less? It's less awkward than > launching openocd within gdb, for sure.
Again, core dumps are great -- when you have the presence of mind to set yourself up to produce them. It has been my impression (for some time) that most folks run in environments where that is disabled by default, so we are again talking about performing precognitive steps if you want to capture unpredictable bugs (while not producing unwanted core files). This new code should require virtually no maintenance; it's very low-level library code, using glibc library APIs that have been stable for a fairly long time. The only changes I foresee (if it goes into the tree) would be new ports of the lowest-level APIs to call similar functions on other C libraries or OSes (e.g. eCos, Win32, etc.). Feature of this scope should be tested to death and proven reliable and removable before being merged. They should be optional for those who do not want them, but I think most everyone underestimates how useful this type of feature can be. I will post another patch that re-uses the stack walking code shortly. (Actually, it's already on my mirror.) How many here have worked on a complex application and had this feature? Unless you have had that experience, then let me conclude by saying that you simply don't know what you're missing. ;) --Z _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
