On Tue, 2009-12-01 at 23:09 +0100, Andreas Fritiofson wrote: > On Tue, Dec 1, 2009 at 11:08 PM, Andreas Fritiofson > <andreas.fritiof...@gmail.com> wrote: > > On Tue, Dec 1, 2009 at 10:23 PM, Zach Welch <z...@superlucidity.net> wrote: > >> On Tue, 2009-12-01 at 21:57 +0100, Andreas Fritiofson wrote: > >>> On Tue, Dec 1, 2009 at 10:32 AM, Zach Welch <z...@superlucidity.net> > >>> wrote: > >>> > On Tue, 2009-12-01 at 10:25 +0100, Øyvind Harboe wrote: > >>> >> On Tue, Dec 1, 2009 at 10:17 AM, Zach Welch <z...@superlucidity.net> > >>> >> 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). > > > > Something like this simple patch would fix that in most (linux) users' > > environments. At least on my ubuntu the hard limit is unlimited, > > probably on most other dists as well. > >
I like it, except I think it needs to be disabled in the default case. We will get complaints if OpenOCD produces core dumps without asking, so this precludes the possibility of turning it on by default. Our program needs to respect the fact that the user could have configured their environment to let the program dump its core, so it seems like bad policy to override that default without the user's explicit authority. We could allow it to be turned on with OPENOCD_DUMPS_CORES set in the environment or via a script command (e.g. 'core dumps (on|off)'). This modified suggestion sounds like a reasonable feature to add, once more work has been done to manage portability. Right now, it's a rat's nest. Finally, I am not sure your suggestion would improve the assert() macro, as the last patch that I posted demonstrates. Does that macro produce core files with the stack trace at the point of assertion? I still want my stack tracing, because I cannot tell the future. It's also the least invasive to the user experience, when compared to GDB or core dumps. I am not kidding when I say that I do not want to do _any_ extra post-processing steps. I fail to see how core files meet this added requirement any better than GDB, when my code nearly does.... To be fair, I added a small perl script to my series that runs addr2line to translate the existing traces that the code produces, but this still has the clear advantage of not needing to predict your crashes. Even the tiny extra step of the perl script annoys me so much that I would rather add the code to do it in-process. Since I could implement these features portably, it would be insane to reject these improvements to the system, but you are welcome to call me crazy for making them. ;) --Z _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
