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.
>
> /Andreas
>
D'oh...
diff --git a/src/main.c b/src/main.c
index a71977d..b580c8b 100644
--- a/src/main.c
+++ b/src/main.c
@@ -23,6 +23,7 @@
#include "config.h"
#endif
#include "openocd.h"
+#include <sys/resource.h>
/* This is the main entry for developer PC hosted OpenOCD.
*
@@ -35,5 +36,12 @@
int main(int argc, char *argv[])
{
+ struct rlimit rlim;
+
+ if (getrlimit(RLIMIT_CORE, &rlim) == 0) {
+ rlim.rlim_cur = rlim.rlim_max;
+ setrlimit(RLIMIT_CORE, &rlim);
+ }
+
return openocd_main(argc, argv);
}
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
