On Tue, Dec 1, 2009 at 11:50 PM, Zach Welch <z...@superlucidity.net> wrote: > 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.
I don't follow. If a user has no clue what a core file is but wants to report a crash, he'll be pleased to find that the file we request is already there, ready to submit in a bug report. If a user knows about core files and _wants_ them, he surely has them enabled anyway (ulimit -c unlimited). If that user _doesn't_ want any core files from openocd, he'll have set the hard limit to 0 (ulimit -c 0), in which case openocd cannot change that. Tough luck. The default policy, which the user may override, is "don't dump core unless the process wants to". > 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? Yes. Unless, of course, your mentioned patch is applied... :) It also dumps on some other signals (SIGILL, SIGFPE and SIGQUIT). The fact is that the most recent crash I had with OpenOCD (log_print_lf adding a newline beyond the end of the cheaply allocated string) wouldn't have been caught with your stack trace, since it did not SIGSEGV, it was aborted by a later free(). It would have dumped core though. Of course, your solution could have been trivially improved to catch SIGABRT as well. > 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. What kind of post-processing steps do you mean and why don't you want them? Given an executable and its core dump its as simple as $ gdb executable (gdb) target core core and wham you have a debug session up where you can backtrace, examine variables and such. I'm not saying your patches have no use here in any context, they could very well be the fanciest solution to some particular problems, but they feel a bit like .. reinventing ... something round. /Andreas _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
