Re: [Openocd-development] s3c2410 nand operations
Hello Fabien, On Sat, Nov 28, 2009 at 5:13 PM, lementec fabien wrote: > Hi, > > I have a board using this chip. I lost the nand contents, > I would like to program it using openocd. I saw the > functions are not implemented, do you think it is difficult, > is anyone working on it? Is there any reason this is not yet > done, difficulty, lack of documentation? > The TinCanTools Hammer is a s3c2410 based module. The configuration that can be found in tcl/board/hammer.cfg could be a good starting point. I tried yesterday to flash my hammer using a fresh (git) openocd and that did not work (to me it looks like the init script is not called). Greetings ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [rfc] improving 'help'... volunteers?
David Brownell a écrit : > On Tuesday 01 December 2009, Zach Welch wrote: The use of angle brackets intends to distinguish parameter names from literal arguments. Thus [] means an optional thing which semantically will be used as a "foo", whereas [foo|bar] means you can optionally provide the 'foo' or 'bar' options (literally). If the parameter is required, I used (foo|bar) or depending on whether the parameter should be literal or figurative, respectively. >>> I've seen it used in places where it's optional ... e.g. the typical >>> "if no parameter, just dump current state" stuff. >> Okay, but how could you then distinguish constant and variable tokens? > > BNF uses quotes: > > 'literal' variable Honestly, that's where linguistic correctness hampers useability. Using pristine BNF notation when providing help for a language assumes the reader who wants to understand the language syntax is more than familiar with the BNF syntax and can handle both without confusion. Pure BNF is quite useful for defining or discussing languages among language designers. For the purpose of teaching a language in one-liners, it is counter-productive in some aspects--which is why some kind of natural selection altered it especially at the lexical level, as randomly sampling some linux command line helps can show. Amicalement, -- Albert. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [patch 1/2] ARM: core DPM support for watchpoints
This is a NOP unless the underlying core exposes two new methods, and
neither of the two cores using this (ARM11xx, Cortex-A8) do so yet.
This patch only updates those cores so they pass a flag saying whether
or not to update breakpoint and watchpoint status before resuming; and
removing some now-needless anti-segfault code from ARM11. Cortex-A8
didn't have that code ... yes, it segfaulted when setting watchpoints.
NOTE: this uses a slightly different strategy for setting/clearing
breakpoints than the ARM7/ARM9/etc code uses. It leaves them alone
unless it's *got* to change something, to speed halt/resume cycles
(including single stepping).
ALSO NOTE: this under-delivers for Cortex-A8, where regions with size
up to 2 GBytes can be watched ... it handles watchpoints which ARM11 can
also handle (size 1/2/4 bytes). Should get fixed later.
---
src/target/arm11.c | 35 +-
src/target/arm_dpm.c | 244 ++-
src/target/arm_dpm.h | 50 +
src/target/cortex_a8.c | 12 --
4 files changed, 301 insertions(+), 40 deletions(-)
--- a/src/target/arm11.c
+++ b/src/target/arm11.c
@@ -293,12 +293,11 @@ static int arm11_on_enter_debug_state(st
return ERROR_OK;
}
-/** Restore processor state
- *
- * This is called in preparation for the RESTART function.
- *
- */
-static int arm11_leave_debug_state(struct arm11_common *arm11)
+/**
+ * Restore processor state. This is called in preparation for
+ * the RESTART function.
+ */
+static int arm11_leave_debug_state(struct arm11_common *arm11, bool bpwp)
{
int retval;
@@ -354,7 +353,7 @@ static int arm11_leave_debug_state(struc
/* restore CPSR, PC, and R0 ... after flushing any modified
* registers.
*/
- retval = arm_dpm_write_dirty_registers(&arm11->dpm);
+ retval = arm_dpm_write_dirty_registers(&arm11->dpm, bpwp);
register_cache_invalidate(arm11->arm.core_cache);
@@ -598,7 +597,7 @@ static int arm11_resume(struct target *t
arm11_sc7_set_vcr(arm11, arm11_vcr);
}
- arm11_leave_debug_state(arm11);
+ arm11_leave_debug_state(arm11, handle_breakpoints);
arm11_add_IR(arm11, ARM11_RESTART, TAP_IDLE);
@@ -762,7 +761,7 @@ static int arm11_step(struct target *tar
R(DSCR) |= ARM11_DSCR_INTERRUPTS_DISABLE;
- CHECK_RETVAL(arm11_leave_debug_state(arm11));
+ CHECK_RETVAL(arm11_leave_debug_state(arm11,
handle_breakpoints));
arm11_add_IR(arm11, ARM11_RESTART, TAP_IDLE);
@@ -1203,22 +1202,6 @@ static int arm11_remove_breakpoint(struc
return ERROR_OK;
}
-static int arm11_add_watchpoint(struct target *target,
- struct watchpoint *watchpoint)
-{
- LOG_WARNING("Not implemented: %s", __func__);
-
- return ERROR_FAIL;
-}
-
-static int arm11_remove_watchpoint(struct target *target,
- struct watchpoint *watchpoint)
-{
- LOG_WARNING("Not implemented: %s", __func__);
-
- return ERROR_FAIL;
-}
-
static int arm11_target_create(struct target *target, Jim_Interp *interp)
{
struct arm11_common *arm11;
@@ -1605,8 +1588,6 @@ struct target_type arm11_target = {
.add_breakpoint = arm11_add_breakpoint,
.remove_breakpoint =arm11_remove_breakpoint,
- .add_watchpoint = arm11_add_watchpoint,
- .remove_watchpoint =arm11_remove_watchpoint,
.run_algorithm =armv4_5_run_algorithm,
--- a/src/target/arm_dpm.c
+++ b/src/target/arm_dpm.c
@@ -25,6 +25,8 @@
#include "arm_dpm.h"
#include "jtag.h"
#include "register.h"
+#include "breakpoints.h"
+#include "target_type.h"
/**
@@ -34,6 +36,8 @@
* implementation differences between cores like ARM1136 and Cortex-A8.
*/
+/*--*/
+
/*
* Coprocessor support
*/
@@ -85,6 +89,8 @@ static int dpm_mcr(struct target *target
return retval;
}
+/*--*/
+
/*
* Register access utilities
*/
@@ -178,7 +184,7 @@ static int dpm_write_reg(struct arm_dpm
switch (regnum) {
case 0 ... 14:
- /* load register from DCC: "MCR p14, 0, Rnum, c0, c5, 0" */
+ /* load register from DCC: "MRC p14, 0, Rnum, c0, c5, 0" */
retval = dpm->instr_write_data_dcc(dpm,
ARMV4_5_MRC(14, 0, regnum, 0, 5, 0),
value);
@@ -256,6 +262,11 @@ int arm_dpm_read_current_registers(struc
/* NOTE: SPSR ignored (if it's even relevant). */
+ /* REVISIT the debugger can trigger various exceptions. See the
+* ARMv7A architecture spec, section C5.7, for more info about
+* what defenses are needed; v6 debug has the most issues.
+*/
+
fail:
/* (void) */ dpm->finish(dpm);
return retval;
@@
[Openocd-development] [patch 2/2] Cortex-A8: basic watchpoint support
Actually this should handle both breakpoints and watchpoints ... but
the DPM framework only handles watchpoints for now. Works on Beagle.
---
src/target/cortex_a8.c | 66 +++
1 file changed, 66 insertions(+)
--- a/src/target/cortex_a8.c
+++ b/src/target/cortex_a8.c
@@ -460,6 +460,66 @@ static int cortex_a8_instr_read_data_r0(
return cortex_a8_read_dcc(a8, data, &dscr);
}
+static int cortex_a8_bpwp_enable(struct arm_dpm *dpm, unsigned index,
+ uint32_t addr, uint32_t control)
+{
+ struct cortex_a8_common *a8 = dpm_to_a8(dpm);
+ uint32_t vr = a8->armv7a_common.debug_base;
+ uint32_t cr = a8->armv7a_common.debug_base;
+ int retval;
+
+ switch (index) {
+ case 0 ... 15: /* breakpoints */
+ vr += CPUDBG_BVR_BASE;
+ cr += CPUDBG_BCR_BASE;
+ break;
+ case 16 ... 31: /* watchpoints */
+ vr += CPUDBG_WVR_BASE;
+ cr += CPUDBG_WCR_BASE;
+ index -= 16;
+ break;
+ default:
+ return ERROR_FAIL;
+ }
+ vr += 4 * index;
+ cr += 4 * index;
+
+ LOG_DEBUG("A8: bpwp enable, vr %08x cr %08x",
+ (unsigned) vr, (unsigned) cr);
+
+ retval = cortex_a8_dap_write_memap_register_u32(dpm->arm->target,
+ vr, addr);
+ if (retval != ERROR_OK)
+ return retval;
+ retval = cortex_a8_dap_write_memap_register_u32(dpm->arm->target,
+ cr, control);
+ return retval;
+}
+
+static int cortex_a8_bpwp_disable(struct arm_dpm *dpm, unsigned index)
+{
+ struct cortex_a8_common *a8 = dpm_to_a8(dpm);
+ uint32_t cr;
+
+ switch (index) {
+ case 0 ... 15:
+ cr = a8->armv7a_common.debug_base + CPUDBG_BCR_BASE;
+ break;
+ case 16 ... 31:
+ cr = a8->armv7a_common.debug_base + CPUDBG_WCR_BASE;
+ index -= 16;
+ break;
+ default:
+ return ERROR_FAIL;
+ }
+ cr += 4 * index;
+
+ LOG_DEBUG("A8: bpwp disable, cr %08x", (unsigned) cr);
+
+ /* clear control register */
+ return cortex_a8_dap_write_memap_register_u32(dpm->arm->target, cr, 0);
+}
+
static int cortex_a8_dpm_setup(struct cortex_a8_common *a8, uint32_t didr)
{
struct arm_dpm *dpm = &a8->armv7a_common.dpm;
@@ -477,6 +537,9 @@ static int cortex_a8_dpm_setup(struct co
dpm->instr_read_data_dcc = cortex_a8_instr_read_data_dcc;
dpm->instr_read_data_r0 = cortex_a8_instr_read_data_r0;
+ dpm->bpwp_enable = cortex_a8_bpwp_enable;
+ dpm->bpwp_disable = cortex_a8_bpwp_disable;
+
return arm_dpm_setup(dpm);
}
@@ -745,6 +808,7 @@ static int cortex_a8_debug_entry(struct
case 5: /* vector catch */
target->debug_reason = DBG_REASON_BREAKPOINT;
break;
+ case 2: /* asynch watchpoint */
case 10:/* precise watchpoint */
target->debug_reason = DBG_REASON_WATCHPOINT;
/* REVISIT could collect WFAR later, to see just
@@ -1276,6 +1340,8 @@ static int cortex_a8_write_memory(struct
*
* For both ICache and DCache, walk all cache lines in the
* address range. Cortex-A8 has fixed 64 byte line length.
+*
+* REVISIT per ARMv7, these may trigger watchpoints ...
*/
/* invalidate I-Cache */
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] policy vs. mechanism
On Tue, 2009-12-01 at 20:57 -0800, David Brownell wrote:
> On Tuesday 01 December 2009, Zach Welch wrote:
> > After the command cleanup that I have started, I believe this type of
> > factoring deserves to be pursued in the other modules. I propose making
> > these changes in the following order:
> >
> > - svf, xsvf, pld: simple core/tcl separation: */core.c and */tcl.c
>
> And maybe merge svf and xsvf into a common directory, so their
> sharing is a bit less convoluted.
Great. I am all for this too.
> > - flash/nor, flash/nand: likewise, if renamed; otherwise *_{core,tcl}.c
> > - target.c: split into target/core.c and target/tcl.c
>
> Probably fair, although I'd be skeptical about internals
> getting exposed there.
>
> One way to address that issue of exposure: switch #include "foo.h"
> over to #include "subdir/foo.h", and minimize the inclusion of
> stuff from other directories. The "/" will flag potential trouble.
I just sent another proposal that I had written up, waiting for feedback
from others on this one. :) We are on the same page here, I think.
>
> > - split drivers similarly: .c and _tcl.c
>
> I'm not quite so keen on that one. Few of them have many Tcl
> functions, and splitting them out separately wouldn't win ...
> it'd just open up innards that *ought* to stay private.
It's about using the same tricks I just used with #if.
I suppose that this could be skipped... anyway, it's a ways out and this
point deserves revisiting.
> However ... splitting ft2232.c into chunks would be good.
> One per adapter. It's quite a mess now.
I just mentioned this to someone else today off-list! It's like you're
reading my mind eeek! ;) Creepy! Great minds think alike.
--Z
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] libopenocd... again
Hi all, Assuming a split between policy and mechanism can be addressed, OpenOCD will become much more usable as a proper library. One of the questions that needs resolution is "how to install our header files". The answer that we chose for this will determine how much restructuring will be required to make it happen. The easiest option to simply mirror the public headers in our existing src/ hierarchy into /usr/include/openocd[-]/, such that applications can use -I and #include . Indeed, I have a series of patches that accomplishes these changes for all s and s in the tree. (Via a script, so it's easy to recreate its patches when I get merge conflicts.) Of the options that I consider as viable, this is the least invasive and most flexible. Each source module gains its own namespace for header files, allowing us to adopt some common idioms across modules. An alternative would be to install all headers in the above location, but that flattens our namespace and prevents some useful possibilities. For example, it would be nice to be able to #include and for each of our modules. These should permit writing very low-level or a script-based applications with built-in commands that use our modules' helper functions, respectively. We should approach this problem as though we intend to eventually decouple Jim from the core functionality and switch to a different front-end language. That would take a lot of extra work, but the preparation would yield solid architectural improvements to the system. Even if we never do that (and there's no reason to), the system will be cleaner for our efforts; it's classic model-view-controller separation. It would be the best way to make Jim 2.0 feasible, wherein its APIs can change wholesale while remaining backward-compatible with 1.0 scripts. Getting from here to there will require a number of large patch series, but I see this specific conversion as being required for writing a proper test suite. Tests should be written for our APIs in the same way as real applications, and the helper API is reaching a state where I want to start a test suite for it. Yes, I have patches started for that in my tree as well, built on the above series. If libocdhelper can become usable independently of OpenOCD, that will be a huge a step in the right direction. I think it's possible very soon. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] policy vs. mechanism
On Tuesday 01 December 2009, Zach Welch wrote:
> After the command cleanup that I have started, I believe this type of
> factoring deserves to be pursued in the other modules. I propose making
> these changes in the following order:
>
> - svf, xsvf, pld: simple core/tcl separation: */core.c and */tcl.c
And maybe merge svf and xsvf into a common directory, so their
sharing is a bit less convoluted.
> - flash/nor, flash/nand: likewise, if renamed; otherwise *_{core,tcl}.c
> - target.c: split into target/core.c and target/tcl.c
Probably fair, although I'd be skeptical about internals
getting exposed there.
One way to address that issue of exposure: switch #include "foo.h"
over to #include "subdir/foo.h", and minimize the inclusion of
stuff from other directories. The "/" will flag potential trouble.
> - split drivers similarly: .c and _tcl.c
I'm not quite so keen on that one. Few of them have many Tcl
functions, and splitting them out separately wouldn't win ...
it'd just open up innards that *ought* to stay private.
However ... splitting ft2232.c into chunks would be good.
One per adapter. It's quite a mess now.
- Dave
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 0/3] remove all #if logic from openocd.c
On Tue, 2009-12-01 at 20:49 -0800, David Brownell wrote: > On Tuesday 01 December 2009, Zachary T Welch wrote: > > This series removes all #if logic from the src/openocd.c file, making > > it look much nicer and helping to stablize our ABI in the process. > > Yes! These patches were easy. I am not yet certain how hard it will be to plow through the tree from top to bottom, so don't get _too_ excited. ;) But thanks for the encouraging word. Literally. :) --Z ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 0/3] remove all #if logic from openocd.c
On Tuesday 01 December 2009, Zachary T Welch wrote: > This series removes all #if logic from the src/openocd.c file, making > it look much nicer and helping to stablize our ABI in the process. Yes! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH 2/3] remove BUILD_IOUTIL symbol
Add ioutil_stubs.c to provide an empty ioutil_init() routine.
Add ioutil.h to prevent applications from needing to declare it.
Allows unconditionally calling that function during startup, and the
resulting libocdhelper library API is now more stable.
Prints a DEBUG message when the stub implementation is included.
Signed-off-by: Zachary T Welch
---
configure.in |6 --
src/ecosboard.c |8 +---
src/helper/Makefile.am|3 +++
src/helper/ioutil.h | 27 +++
src/helper/ioutil_stubs.c | 29 +
src/openocd.c |7 +--
6 files changed, 61 insertions(+), 19 deletions(-)
create mode 100644 src/helper/ioutil.h
create mode 100644 src/helper/ioutil_stubs.c
diff --git a/configure.in b/configure.in
index 81e4326..1a4299d 100644
--- a/configure.in
+++ b/configure.in
@@ -614,12 +614,6 @@ else
AC_DEFINE(BUILD_ZY1000, 0, [0 if you don't want ZY1000.])
fi
-if test $build_ioutil = yes; then
- AC_DEFINE(BUILD_IOUTIL, 1, [1 if you want ioutils.])
-else
- AC_DEFINE(BUILD_IOUTIL, 0, [0 if you don't want ioutils.])
-fi
-
if test $build_httpd = yes; then
AC_DEFINE(BUILD_HTTPD, 1, [1 if you want httpd.])
else
diff --git a/src/ecosboard.c b/src/ecosboard.c
index 36e807e..fe2c024 100644
--- a/src/ecosboard.c
+++ b/src/ecosboard.c
@@ -23,6 +23,7 @@
#include "types.h"
#include "jtag.h"
+#include "ioutil.h"
#include "configuration.h"
#include "xsvf.h"
#include "svf.h"
@@ -942,8 +943,6 @@ static int add_default_dirs(void)
return ERROR_OK;
}
-int ioutil_init(struct command_context *cmd_ctx);
-
int main(int argc, char *argv[])
{
/* ramblockdevice will be the same address every time. The deflate app
uses a buffer 16mBytes out, so we
@@ -1080,13 +1079,8 @@ int main(int argc, char *argv[])
command_set_output_handler(cmd_ctx, configuration_output_handler, NULL);
command_context_mode(cmd_ctx, COMMAND_CONFIG);
-#if BUILD_IOUTIL
if (ioutil_init(cmd_ctx) != ERROR_OK)
- {
return EXIT_FAILURE;
- }
-#endif
-
#ifdef CYGPKG_PROFILE_GPROF
COMMAND_REGISTER(cmd_ctx, NULL, "ecosboard_profile",
eCosBoard_handle_eCosBoard_profile_command,
diff --git a/src/helper/Makefile.am b/src/helper/Makefile.am
index 22b3c33..01e805e 100644
--- a/src/helper/Makefile.am
+++ b/src/helper/Makefile.am
@@ -27,6 +27,8 @@ libhelper_la_SOURCES = \
if IOUTIL
libhelper_la_SOURCES += ioutil.c
+else
+libhelper_la_SOURCES += ioutil_stubs.c
endif
libhelper_la_CFLAGS =
@@ -38,6 +40,7 @@ endif
noinst_HEADERS = \
binarybuffer.h \
configuration.h \
+ ioutil.h \
types.h \
log.h \
command.h \
diff --git a/src/helper/ioutil.h b/src/helper/ioutil.h
new file mode 100644
index 000..855ae55
--- /dev/null
+++ b/src/helper/ioutil.h
@@ -0,0 +1,27 @@
+/***
+ * Copyright (C) 2009 Zachary T Welch *
+ * *
+ * This program is free software; you can redistribute it and/or modify *
+ * it under the terms of the GNU General Public License as published by *
+ * the Free Software Foundation; either version 2 of the License, or *
+ * (at your option) any later version. *
+ * *
+ * This program is distributed in the hope that it will be useful, *
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of*
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the *
+ * GNU General Public License for more details. *
+ * *
+ * You should have received a copy of the GNU General Public License *
+ * along with this program; if not, write to the *
+ * Free Software Foundation, Inc., *
+ * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. *
+ ***/
+
+#ifndef HELPER_IOUTILS_H
+#define HELPER_IOUTILS_H
+
+struct command_context;
+
+int ioutil_init(struct command_context *cmd_ctx);
+
+#endif // HELPER_IOUTILS_H
diff --git a/src/helper/ioutil_stubs.c b/src/helper/ioutil_stubs.c
new file mode 100644
index 000..1171a6f
--- /dev/null
+++ b/src/helper/ioutil_stubs.c
@@ -0,0 +1,29 @@
+/***
+ * Copyright (C) 2009 Zachary T Welch *
+ * *
+ * This program is free software; you can redistribute it and/or modify *
+ * it under the terms of the GNU General Public License as published by *
+ * the
[Openocd-development] [PATCH 1/3] remove #if logic for openocd_sleep_*lude
Adds server_stubs.c to hold these routines, using automake logic to
ensure it gets included under the right conditions.
Signed-off-by: Zachary T Welch
---
src/openocd.c | 14 --
src/openocd.h |5 -
src/server/Makefile.am|4
src/server/server.h |9 +
src/server/server_stubs.c | 32
5 files changed, 45 insertions(+), 19 deletions(-)
create mode 100644 src/server/server_stubs.c
diff --git a/src/openocd.c b/src/openocd.c
index 12bcf44..2043a92 100644
--- a/src/openocd.c
+++ b/src/openocd.c
@@ -215,20 +215,6 @@ struct command_context *setup_command_handler(Jim_Interp
*interp)
return cmd_ctx;
}
-#if !BUILD_HTTPD && !BUILD_ECOSBOARD
-/* implementations of OpenOCD that uses multithreading needs to know when
- * OpenOCD is sleeping. No-op in vanilla OpenOCD
- */
-void openocd_sleep_prelude(void)
-{
-}
-
-void openocd_sleep_postlude(void)
-{
-}
-#endif
-
-
/* normally this is the main() function entry, but if OpenOCD is linked
* into application, then this fn will not be invoked, but rather that
* application will have it's own implementation of main(). */
diff --git a/src/openocd.h b/src/openocd.h
index a91d46f..e43f156 100644
--- a/src/openocd.h
+++ b/src/openocd.h
@@ -31,11 +31,6 @@
*/
int openocd_main(int argc, char *argv[]);
-/// used by the server_loop() function in src/server/server.c
-void openocd_sleep_prelude(void);
-/// used by the server_loop() function in src/server/server.c
-void openocd_sleep_postlude(void);
-
/// provides a hard-coded command environment setup
extern const char openocd_startup_tcl[];
diff --git a/src/server/Makefile.am b/src/server/Makefile.am
index 95fb519..b47b8d0 100644
--- a/src/server/Makefile.am
+++ b/src/server/Makefile.am
@@ -13,6 +13,10 @@ libserver_la_SOURCES = server.c telnet_server.c gdb_server.c
if HTTPD
libserver_la_SOURCES += httpd.c
+else
+if !ECOSBOARD
+libserver_la_SOURCES += server_stubs.c
+endif
endif
noinst_HEADERS += httpd.h
diff --git a/src/server/server.h b/src/server/server.h
index 173de95..e632bf1 100644
--- a/src/server/server.h
+++ b/src/server/server.h
@@ -82,6 +82,15 @@ int server_loop(struct command_context *command_context);
int server_register_commands(struct command_context *context);
/**
+ * Used by server_loop(), defined in server_stubs.c, httpd.c, or ecosboard.c
+ */
+void openocd_sleep_prelude(void);
+/**
+ * Used by server_loop(), defined in server_stubs.c, httpd.c, or ecosboard.c
+ */
+void openocd_sleep_postlude(void);
+
+/**
* Defines an extended command handler function declaration to enable
* access to (and manipulation of) the server port number.
* Call server_port like a normal COMMAND_HANDLER with an extra @a out
parameter
diff --git a/src/server/server_stubs.c b/src/server/server_stubs.c
new file mode 100644
index 000..dcddec0
--- /dev/null
+++ b/src/server/server_stubs.c
@@ -0,0 +1,32 @@
+/***
+ * Copyright (C) 2009 Zachary T Welch *
+ * *
+ * This program is free software; you can redistribute it and/or modify *
+ * it under the terms of the GNU General Public License as published by *
+ * the Free Software Foundation; either version 2 of the License, or *
+ * (at your option) any later version. *
+ * *
+ * This program is distributed in the hope that it will be useful, *
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of*
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the *
+ * GNU General Public License for more details. *
+ * *
+ * You should have received a copy of the GNU General Public License *
+ * along with this program; if not, write to the *
+ * Free Software Foundation, Inc., *
+ * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. *
+ ***/
+
+#ifdef HAVE_CONFIG_H
+#include
+#endif
+#include "server.h"
+
+void openocd_sleep_prelude(void)
+{
+ // no-op
+}
+void openocd_sleep_postlude(void)
+{
+ // no-op
+}
--
1.6.4.4
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH 3/3] remove #if BUILD_HTTPD
Add httpd_stubs.c to provide no-op implementations of httpd_start()
and httpd_stop().
Allows these routines to be called unconditionally and ensures the
libocdserver ABI remains unchanged regardless of whether this feature
was built-in or not.
Prints a DEBUG message when the stub implementation is included.
Signed-off-by: Zachary T Welch
---
configure.in |6 --
src/openocd.c|4
src/server/Makefile.am |1 +
src/server/httpd_stubs.c | 32
4 files changed, 33 insertions(+), 10 deletions(-)
create mode 100644 src/server/httpd_stubs.c
diff --git a/configure.in b/configure.in
index 1a4299d..9cb2b0f 100644
--- a/configure.in
+++ b/configure.in
@@ -614,12 +614,6 @@ else
AC_DEFINE(BUILD_ZY1000, 0, [0 if you don't want ZY1000.])
fi
-if test $build_httpd = yes; then
- AC_DEFINE(BUILD_HTTPD, 1, [1 if you want httpd.])
-else
- AC_DEFINE(BUILD_HTTPD, 0, [0 if you don't want httpd.])
-fi
-
if test $build_at91rm9200 = yes; then
build_bitbang=yes
AC_DEFINE(BUILD_AT91RM9200, 1, [1 if you want at91rm9200.])
diff --git a/src/openocd.c b/src/openocd.c
index 1f45837..9a08019 100644
--- a/src/openocd.c
+++ b/src/openocd.c
@@ -244,10 +244,8 @@ int openocd_main(int argc, char *argv[])
if (ret != ERROR_OK)
return EXIT_FAILURE;
-#if BUILD_HTTPD
if (httpd_start(cmd_ctx) != ERROR_OK)
return EXIT_FAILURE;
-#endif
ret = server_init(cmd_ctx);
if (ERROR_OK != ret)
@@ -266,9 +264,7 @@ int openocd_main(int argc, char *argv[])
server_quit();
-#if BUILD_HTTPD
httpd_stop();
-#endif
unregister_all_commands(cmd_ctx, NULL);
diff --git a/src/server/Makefile.am b/src/server/Makefile.am
index b47b8d0..989a682 100644
--- a/src/server/Makefile.am
+++ b/src/server/Makefile.am
@@ -14,6 +14,7 @@ libserver_la_SOURCES = server.c telnet_server.c gdb_server.c
if HTTPD
libserver_la_SOURCES += httpd.c
else
+libserver_la_SOURCES += httpd_stubs.c
if !ECOSBOARD
libserver_la_SOURCES += server_stubs.c
endif
diff --git a/src/server/httpd_stubs.c b/src/server/httpd_stubs.c
new file mode 100644
index 000..0a63362
--- /dev/null
+++ b/src/server/httpd_stubs.c
@@ -0,0 +1,32 @@
+/***
+ * Copyright (C) 2009 Zachary T Welch *
+ * *
+ * This program is free software; you can redistribute it and/or modify *
+ * it under the terms of the GNU General Public License as published by *
+ * the Free Software Foundation; either version 2 of the License, or *
+ * (at your option) any later version. *
+ * *
+ * This program is distributed in the hope that it will be useful, *
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of*
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the *
+ * GNU General Public License for more details. *
+ * *
+ * You should have received a copy of the GNU General Public License *
+ * along with this program; if not, write to the *
+ * Free Software Foundation, Inc., *
+ * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. *
+ ***/
+
+#ifdef HAVE_CONFIG_H
+#include
+#endif
+#include "httpd.h"
+
+int httpd_start(struct command_context *cmd_ctx)
+{
+ LOG_DEBUG("libocdserver was built without HTTPD support");
+ return ERROR_OK;
+}
+void httpd_stop(void)
+{
+}
--
1.6.4.4
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH 0/3] remove all #if logic from openocd.c
Hi all, This series removes all #if logic from the src/openocd.c file, making it look much nicer and helping to stablize our ABI in the process. If these look good, I will continue this quest in future series. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 0/7] split the 'init' command
On Tue, 2009-12-01 at 13:01 -0800, Zachary T Welch wrote: > Hi all, > > This series makes most of the individual steps in 'init' accessible to > direct invocation. The changes should allow recovery in cases when > OpenOCD is run interactively and (for example) you fail to specify an > interface before trying to to run 'init'. These new subcommands help > with the transition to fine-grained, context-sensitive commands. > > It also includes one patch to refactor target_init, whose previous > monolithic form bugged me more than I could stand. David, You found the previous regression that my factoring introduced in this area of the system, so you might consider taking a look at these before they go into the tree. There is a possibility that I have broken something after updating the command mode switching; this stands to be improved further, but I've made a reasonable dent in modularizing it and allowing for recovery and retry. I think a few more patches would allow the current 'init' command to be rewritten entirely in TCL as a sequence of ' init' commands, though these are all temporary measures on the command upgrade path. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 2/4] produce stack traces on segfaults
On Wed, 2009-12-02 at 00:56 +0100, Andreas Fritiofson wrote: > On Tue, Dec 1, 2009 at 11:50 PM, Zach Welch wrote: > > On Tue, 2009-12-01 at 23:09 +0100, Andreas Fritiofson wrote: [snip] > > 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". But all of these things are extra steps, grok? If the stack trace is Just There, we get it in the first report; we don't have to add a round-trip to the communication to tell them to look at the core file. And you must have missed my point in another line of this thread that none of these things are suitable for _users_. These are things that developers will do. While some developers may make these efforts, I think the majority of users will just want a tool that works, and they are not going to be bothered to debug our problems. Heck, I claim that class of user will uninstall us if it segfaults for them off-the-shelf, but this shows that we care enough about them to encourage bug reports. They just might stick around and see how we respond, and maybe they will be convinced to continue with it -- if it gets fixed without us asking them to do a lot of grunt work like generating a core file or using GDB. Say, that reminds me to update the segfault output to tell users to report them to us. :) Your core files can't do that! > > 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. More patches are welcome, but base patches off my repo.or.cz branch and not those posted to the list. :) > > 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. Developers should know tricks like this to get detailed information, but I never want to ask a user to do this. I think it is reprehensible as a maintainer to do so, when it could have been prevented by dumping the stack trace for them right into the log for them. > 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. At least we have the glibc APIs to do this somewhat cleanly. I mean, it's not like I am asking to walk down the stack by hand. ;) Thank goodness I don't need to handle C++ name demangling too, though libgcc has APIs to make that easy too (IIRC). --Z _
Re: [Openocd-development] split flash/* into flash/nor/* and flash/nand/*
Yeah, sorry Dean. I know it impacts you, but -- as I said -- I think that it will be relatively easy to merge your changes after the refactoring. I Want To Believe that Git is that smart. The truth will be out there, waiting for you in your tree when you get back to it. ;) On Tue, 2009-12-01 at 17:52 -0600, Dean Glazeski wrote: > Aargh, darn school! I can't keep up with these patches, but do it! > This leaves some room for work I want to do when I have time again :). > > // Dean Glazeski > > > On Tue, Dec 1, 2009 at 5:30 PM, Zach Welch > wrote: > Hi all, > > I want to clean up our flash directory, moving the files into > subdirectories and simplifying the nand filenames. This paves > the way > for future types of flash technologies, drivers for which seem > like they > could be imminent. It simplifies another proposal of mine > appreciably, > so I want to see this work done before putting it up for > discussion. > > Git seems pretty smart about moved files, so this changes > should not be > _too_ painful for others to rebase branches based on these > files > Any objections if I create and push this trivial (if invasive) > patch? > > Cheers, > > Zach > ___ > Openocd-development mailing list > Openocd-development@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/openocd-development > ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] policy vs. mechanism
Hi all,
Part of my impetus to restructure the command set is to see more
separation of policy and mechanism in the code. The JTAG layer shows
how this can be done: a tcl.c file contains all of the command handlers,
while core.c contains the low-level functions that do the work. It
might be worth considering a cmd.c file with the high-level command
handlers, if they can become fully independent of the Jim APIs.
After the command cleanup that I have started, I believe this type of
factoring deserves to be pursued in the other modules. I propose making
these changes in the following order:
- svf, xsvf, pld: simple core/tcl separation: */core.c and */tcl.c
- flash/nor, flash/nand: likewise, if renamed; otherwise *_{core,tcl}.c
- target.c: split into target/core.c and target/tcl.c
- split drivers similarly: .c and _tcl.c
This suggestion helps show why it would be nice to split the flash/
directory contents into subdirectories. While it paves the way for
future types of flash, it allows us to provide them with their own
{core,tcl}.c files and provide normalized names for all modules' layers.
This plan would transform each OpenOCD library module to have the same
file structure in this way, creating a clear division between the
low-level model (in core.c) and the view/controller (in tcl.c). This
division is blurred too often today, with the result that a lot of code
does not promote (or practice) re-use as widely or often as it can.
It also becomes conceivable to provide a '--disable-tcl' option to build
a version of the libraries that do not contain this high-level code.
I have said this before, but I feel it is an imperative to pursue this
strictly for the purpose of improving OpenOCD's architectural integrity.
Cheers,
Zach
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 2/4] produce stack traces on segfaults
On Tue, Dec 1, 2009 at 11:50 PM, Zach Welch wrote: > On Tue, 2009-12-01 at 23:09 +0100, Andreas Fritiofson wrote: >> On Tue, Dec 1, 2009 at 11:08 PM, Andreas Fritiofson >> wrote: >> > On Tue, Dec 1, 2009 at 10:23 PM, Zach Welch wrote: >> >> On Tue, 2009-12-01 at 21:57 +0100, Andreas Fritiofson wrote: >> >>> On Tue, Dec 1, 2009 at 10:32 AM, Zach Welch >> >>> wrote: >> >>> > On Tue, 2009-12-01 at 10:25 +0100, Øyvind Harboe wrote: >> >>> >> On Tue, Dec 1, 2009 at 10:17 AM, Zach Welch >> >>> >> 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 t
Re: [Openocd-development] split flash/* into flash/nor/* and flash/nand/*
Aargh, darn school! I can't keep up with these patches, but do it! This leaves some room for work I want to do when I have time again :). // Dean Glazeski On Tue, Dec 1, 2009 at 5:30 PM, Zach Welch wrote: > Hi all, > > I want to clean up our flash directory, moving the files into > subdirectories and simplifying the nand filenames. This paves the way > for future types of flash technologies, drivers for which seem like they > could be imminent. It simplifies another proposal of mine appreciably, > so I want to see this work done before putting it up for discussion. > > Git seems pretty smart about moved files, so this changes should not be > _too_ painful for others to rebase branches based on these files > Any objections if I create and push this trivial (if invasive) patch? > > Cheers, > > Zach > ___ > Openocd-development mailing list > Openocd-development@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/openocd-development > ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] split flash/* into flash/nor/* and flash/nand/*
Hi all, I want to clean up our flash directory, moving the files into subdirectories and simplifying the nand filenames. This paves the way for future types of flash technologies, drivers for which seem like they could be imminent. It simplifies another proposal of mine appreciably, so I want to see this work done before putting it up for discussion. Git seems pretty smart about moved files, so this changes should not be _too_ painful for others to rebase branches based on these files Any objections if I create and push this trivial (if invasive) patch? Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 2/4] produce stack traces on segfaults
On Tue, 2009-12-01 at 10:08 -0800, David Brownell wrote: > On Tuesday 01 December 2009, Øyvind Harboe wrote: > > Zach made a good point that there are bug reports we are not receiving > > today. Those are the ones he's after here I think. > > I'm sure this project loses more potential bug reports by requiring > folk to subscribe to Yet Another Mailing List than we lose by somehow > preventing them from including stack dumps. > > If the list were not closed, it would be trivial to send in reports > like "if I do then , what's up?". For any type > of bug, not just segfaults. > > As it is, there's extra work that needs doing before even such a > one-shot report could be *sent* ... and that extra work is rarely > getting done. > > Think about how many "it segfaults" reports we actually see... > I don't recall seeing one, they're not exactly a common type of > bug. (And shouldn't be.) Subject to change of course. Considering how many NULL pointer checks are missing after routines that might return such a value, I am surprised that we do not see more. I do remember seeing one recently (exactly the scenario I described...), though I think that bug related to my refactoring efforts. Still, I recall it being intractable at first glance, whereas these patches might have given us a small clue about the problem as part of the output log that the user provided for us. In any case, this will point us to the places where we need such tests, and these bugs are more likely to be exposed in production-line (i.e. user) environments rather than on developer machines with gigs of RAM. Your points about the mailing list continue to be valid, regardless. --Z ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [rfc] improving 'help'... volunteers?
On Tue, 2009-12-01 at 14:28 -0800, David Brownell wrote: > On Tuesday 01 December 2009, Zach Welch wrote: > > > > > > The use of angle brackets intends to distinguish parameter names from > > > > literal arguments. Thus [] means an optional thing which > > > > semantically will be used as a "foo", whereas [foo|bar] means you can > > > > optionally provide the 'foo' or 'bar' options (literally). If the > > > > parameter is required, I used (foo|bar) or depending on > > > > whether the parameter should be literal or figurative, respectively. > > > > > > I've seen it used in places where it's optional ... e.g. the typical > > > "if no parameter, just dump current state" stuff. > > > > Okay, but how could you then distinguish constant and variable tokens? > > BNF uses quotes: > > 'literal' variable Heh, see why I suggested you improve the docs? :) --Z ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 2/4] produce stack traces on segfaults
On Tue, 2009-12-01 at 23:09 +0100, Andreas Fritiofson wrote: > On Tue, Dec 1, 2009 at 11:08 PM, Andreas Fritiofson > wrote: > > On Tue, Dec 1, 2009 at 10:23 PM, Zach Welch wrote: > >> On Tue, 2009-12-01 at 21:57 +0100, Andreas Fritiofson wrote: > >>> On Tue, Dec 1, 2009 at 10:32 AM, Zach Welch > >>> wrote: > >>> > On Tue, 2009-12-01 at 10:25 +0100, Øyvind Harboe wrote: > >>> >> On Tue, Dec 1, 2009 at 10:17 AM, Zach Welch > >>> >> 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
Re: [Openocd-development] [rfc] improving 'help'... volunteers?
On Tuesday 01 December 2009, Zach Welch wrote: > > > > The use of angle brackets intends to distinguish parameter names from > > > literal arguments. Thus [] means an optional thing which > > > semantically will be used as a "foo", whereas [foo|bar] means you can > > > optionally provide the 'foo' or 'bar' options (literally). If the > > > parameter is required, I used (foo|bar) or depending on > > > whether the parameter should be literal or figurative, respectively. > > > > I've seen it used in places where it's optional ... e.g. the typical > > "if no parameter, just dump current state" stuff. > > Okay, but how could you then distinguish constant and variable tokens? BNF uses quotes: 'literal' variable ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [rfc] improving 'help'... volunteers?
On Sat, 2009-11-28 at 15:26 -0800, David Brownell wrote: > On Saturday 28 November 2009, Zach Welch wrote: > > On Sat, 2009-11-28 at 14:07 -0800, David Brownell wrote: > > > On Saturday 28 November 2009, Zach Welch wrote: > > > > Next, we should consider updating all help messages to full sentences, > > > > so the new command mode information will follow the final period. > > > > > > And make sure the "usage" is all strict BNF. I see angle brackets "<...>" > > > and have no idea what's meant; I've seen both: > > > > > > - one-or-the-other ... BNF writes as "( ... | ... )" > > > > > > - none-or-one-of ... BNF writes as "[ ... | ... ]" > > > > > > and so on. > > > > The use of angle brackets intends to distinguish parameter names from > > literal arguments. Thus [] means an optional thing which > > semantically will be used as a "foo", whereas [foo|bar] means you can > > optionally provide the 'foo' or 'bar' options (literally). If the > > parameter is required, I used (foo|bar) or depending on > > whether the parameter should be literal or figurative, respectively. > > I've seen it used in places where it's optional ... e.g. the typical > "if no parameter, just dump current state" stuff. Okay, but how could you then distinguish constant and variable tokens? > > By the end of my work, I intended for the usage follow these rules, but > > it was a long process and I did not have them formulated this clearly. > > The use of angle brackets may be non-standard for BNF, but it was based > > on the practices for usage information in most command line utilities. > > Command line utility docs I've seen rely on fonts to distinguish > stuff like that ... '<' and '>' and '|' are shell metacharacters! What about using them for notational purposes as I suggested, then parsing them and displaying proper fonts if possible. Of course, that would mean escaping them if you needed them literally, but these tokens should be _highly_ unlikely to show up as literal command arguments. I'd almost say "never", but I am feeling wise enough today to avoid making such laughable claims. > > For now, I think it would be helpful for us to add a section to the new > > command API documentation to record the desired rules. That should give > > the standard for writing and registering command handlers in OpenOCD. > > doc/manual/style.txt says: > >- Use BNF style regular expressions to define parameters: > brackets around zero-or-one choices, parentheses around > exactly-one choices. I guess this requires more detail (and suggests that I should remember to re-read our style guide on occasion). Can we have Extended BNF? ;) > > Would you mind taking a stab at this documentation task? It might also > > give you a chance to touch up that API information (or remark about > > possible omissions). As the author of both the code and the docs, it's > > likely that I have missed something therein that you will spot when > > making new changes. > > Yeah, I know *that* phenomonon well. IN the same vein, one wants > people really *new* to things as reviewers/testers ... everyone > else has applied blinders they don't even know about. The fresh perspective at the point of first working on a project can never be recovered after gaining some experience. Although, I suppose rotating teams of development would help this. If someone goes away from an active project for a year, things should have changed enough to cause them to induce a similar state again by the time they return. ;) Everyone needs to use this logic to get themselves a paid 1 month sabbatical every year: you need keep yourself from "going native" with your projects. :) --Z ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 2/4] produce stack traces on segfaults
On Tue, Dec 1, 2009 at 11:08 PM, Andreas Fritiofson
wrote:
> On Tue, Dec 1, 2009 at 10:23 PM, Zach Welch wrote:
>> On Tue, 2009-12-01 at 21:57 +0100, Andreas Fritiofson wrote:
>>> On Tue, Dec 1, 2009 at 10:32 AM, Zach Welch wrote:
>>> > On Tue, 2009-12-01 at 10:25 +0100, Øyvind Harboe wrote:
>>> >> On Tue, Dec 1, 2009 at 10:17 AM, Zach Welch
>>> >> 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
/* 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
Re: [Openocd-development] [PATCH 2/4] produce stack traces on segfaults
On Tue, Dec 1, 2009 at 10:23 PM, Zach Welch wrote: > On Tue, 2009-12-01 at 21:57 +0100, Andreas Fritiofson wrote: >> On Tue, Dec 1, 2009 at 10:32 AM, Zach Welch wrote: >> > On Tue, 2009-12-01 at 10:25 +0100, Øyvind Harboe wrote: >> >> On Tue, Dec 1, 2009 at 10:17 AM, Zach Welch >> >> 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 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FT4232H support
On Mon, 2009-11-30 at 16:38 -0600, Austin, Alex wrote: > Hello, > > I’ve built a JTAG adapter (Very similar to oocdlink-h) using the > FT4232H instead of the FT2232H. Due to the lack of ACBUS on the 4232, > I’ve routed the reset lines to the same pins on BDBUS. CDBUS and DDBUS > both go to serial ports. > > > > What would be the best way to support that? Should I manually open the > 2nd port on jtag_init in bit-bang mode and use it for reset events, or > is there a better way to do that? I am not sure My suggestion would be to start with those parts of the driver that will not cause controversy, saving anything that you have questions about for later patches. Once the "noise" of the basic implementation has been put into place, it will be easier to see how you need to build on top of that to provide the support you require. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH 4/7] add stack_assert for an improved assert macro
Adds backtraces to all assert messages, so developers receive the
context of the problem. After all, finding the problem often requires
knowing how the code managed to reach the call that contains the
assertion that has failed.
Signed-off-by: Zachary T Welch
---
NOTE: The complete series is available in my mirror on repo.or.cz
in the 'stack' branch:
git://repo.or.cz/openocd/ztw.git
---
src/helper/stack.c | 10 ++
src/helper/stack.h | 16
src/helper/system.h |3 +++
3 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/src/helper/stack.c b/src/helper/stack.c
index 599b983..fc1e038 100644
--- a/src/helper/stack.c
+++ b/src/helper/stack.c
@@ -181,3 +181,13 @@ int stack_walk(unsigned depth, stack_walker_t walker,
intptr_t data)
};
return stack_dump(depth, &stack_walk_dumper, (intptr_t)&walk);
}
+
+void stack_assert(const char *file, unsigned line,
+ const char *function, const char *condition)
+{
+ LOG_ERROR("Assertion failed:\n\t%s\n\tFunc:\t%s\n"
+ "\tLine:\t%u:\n\tFile:\t%s",
+ condition, function, line, file);
+ stack_walk(100, &stack_log_walker, 0);
+ exit(1);
+}
diff --git a/src/helper/stack.h b/src/helper/stack.h
index e18be14..6155f34 100644
--- a/src/helper/stack.h
+++ b/src/helper/stack.h
@@ -105,4 +105,20 @@ int stack_log_walker(struct stack_walk_state *state,
intptr_t cmd_ctx);
*/
int stack_walk(unsigned depth, stack_walker_t walker, intptr_t data);
+#ifndef NDEBUG
+
+void stack_assert(const char *file, unsigned line,
+ const char *function, const char *condition);
+
+// remove assert macro from namespace
+#undef assert
+// replace assert with call to inline and original version (C9x-portable)
+#define assert(__x) \
+ ((__x) \
+? (void)(0) \
+: stack_assert(__FILE__, __LINE__, __func__, stringify(__x)))
+
+#endif // NDEBUG
+
+
#endif // HELPER_STACK_H
diff --git a/src/helper/system.h b/src/helper/system.h
index 169df1c..e15dbef 100644
--- a/src/helper/system.h
+++ b/src/helper/system.h
@@ -30,6 +30,9 @@
#include
#include
+// for stack_assert()
+#include "stack.h"
+
// +++ AC_HEADER_TIME +++
#ifdef TIME_WITH_SYS_TIME
# include
--
1.6.4.4
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 2/4] produce stack traces on segfaults
On Tue, 2009-12-01 at 21:57 +0100, Andreas Fritiofson wrote: > On Tue, Dec 1, 2009 at 10:32 AM, Zach Welch wrote: > > On Tue, 2009-12-01 at 10:25 +0100, Øyvind Harboe wrote: > >> On Tue, Dec 1, 2009 at 10:17 AM, Zach Welch 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 Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH 7/7] target: factor init to 'target init'
Adds 'target init' command handler, called as part of 'init'.
Signed-off-by: Zachary T Welch
---
src/openocd.c |7 ++-
src/target/target.c | 23 +++
2 files changed, 25 insertions(+), 5 deletions(-)
diff --git a/src/openocd.c b/src/openocd.c
index 79a30e7..12bcf44 100644
--- a/src/openocd.c
+++ b/src/openocd.c
@@ -111,11 +111,9 @@ COMMAND_HANDLER(handle_init_command)
initialized = 1;
- command_context_mode(CMD_CTX, COMMAND_EXEC);
-
- if (target_init(CMD_CTX) != ERROR_OK)
+ retval = command_run_line(CMD_CTX, "target init");
+ if (ERROR_OK != retval)
return ERROR_FAIL;
- LOG_DEBUG("target init complete");
if ((retval = jtag_interface_init(CMD_CTX)) != ERROR_OK)
{
@@ -126,7 +124,6 @@ COMMAND_HANDLER(handle_init_command)
/* Try to initialize & examine the JTAG chain at this point, but
* continue startup regardless */
- command_context_mode(CMD_CTX, COMMAND_CONFIG);
if (command_run_line(CMD_CTX, "jtag init") == ERROR_OK)
{
command_context_mode(CMD_CTX, COMMAND_EXEC);
diff --git a/src/target/target.c b/src/target/target.c
index abf8bfd..4013442 100644
--- a/src/target/target.c
+++ b/src/target/target.c
@@ -787,6 +787,23 @@ int target_init(struct command_context *cmd_ctx)
return ERROR_OK;
}
+COMMAND_HANDLER(handle_target_init_command)
+{
+ if (CMD_ARGC != 0)
+ return ERROR_COMMAND_SYNTAX_ERROR;
+
+ static bool target_initialized = false;
+ if (target_initialized)
+ {
+ LOG_INFO("'target init' has already been called");
+ return ERROR_OK;
+ }
+ target_initialized = true;
+
+ LOG_DEBUG("Initializing targets...");
+ return target_init(CMD_CTX);
+}
+
int target_register_event_callback(int (*callback)(struct target *target, enum
target_event event, void *priv), void *priv)
{
struct target_event_callback **callbacks_p = &target_event_callbacks;
@@ -4787,6 +4804,12 @@ COMMAND_HANDLER(handle_fast_load_command)
static const struct command_registration target_command_handlers[] = {
{
+ .name = "init",
+ .mode = COMMAND_CONFIG,
+ .handler = &handle_target_init_command,
+ .help = "initialize targets",
+ },
+ {
.name = "targets",
.handler = &handle_targets_command,
.mode = COMMAND_ANY,
--
1.6.4.4
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH 6/7] target: factor target_init() into pieces
Moves body of target initialization loop into a helper function,
cleaning up its visual flow in the process.
Signed-off-by: Zachary T Welch
---
src/target/target.c | 153 ---
1 files changed, 84 insertions(+), 69 deletions(-)
diff --git a/src/target/target.c b/src/target/target.c
index 88931b5..abf8bfd 100644
--- a/src/target/target.c
+++ b/src/target/target.c
@@ -681,94 +681,109 @@ err_write_phys_memory(struct target *target, uint32_t
address,
static int handle_target(void *priv);
-int target_init(struct command_context *cmd_ctx)
+static int target_init_one(struct command_context *cmd_ctx,
+ struct target *target)
{
- struct target *target;
- int retval;
+ target_reset_examined(target);
- for (target = all_targets; target; target = target->next) {
- struct target_type *type = target->type;
+ struct target_type *type = target->type;
+ if (type->examine == NULL)
+ type->examine = default_examine;
- target_reset_examined(target);
- if (target->type->examine == NULL)
- {
- target->type->examine = default_examine;
- }
+ int retval = type->init_target(cmd_ctx, target);
+ if (ERROR_OK != retval)
+ {
+ LOG_ERROR("target '%s' init failed", target_name(target));
+ return retval;
+ }
- if ((retval = target->type->init_target(cmd_ctx, target)) !=
ERROR_OK)
- {
- LOG_ERROR("target '%s' init failed",
target_name(target));
- return retval;
- }
+ /**
+* @todo get rid of those *memory_imp() methods, now that all
+* callers are using target_*_memory() accessors ... and make
+* sure the "physical" paths handle the same issues.
+*/
+ /* a non-invasive way(in terms of patches) to add some code that
+* runs before the type->write/read_memory implementation
+*/
+ type->write_memory_imp = target->type->write_memory;
+ type->write_memory = target_write_memory_imp;
+ type->read_memory_imp = target->type->read_memory;
+ type->read_memory = target_read_memory_imp;
- /**
-* @todo get rid of those *memory_imp() methods, now that all
-* callers are using target_*_memory() accessors ... and make
-* sure the "physical" paths handle the same issues.
-*/
+ type->soft_reset_halt_imp = target->type->soft_reset_halt;
+ type->soft_reset_halt = target_soft_reset_halt_imp;
- /* a non-invasive way(in terms of patches) to add some code that
-* runs before the type->write/read_memory implementation
-*/
- target->type->write_memory_imp = target->type->write_memory;
- target->type->write_memory = target_write_memory_imp;
- target->type->read_memory_imp = target->type->read_memory;
- target->type->read_memory = target_read_memory_imp;
- target->type->soft_reset_halt_imp =
target->type->soft_reset_halt;
- target->type->soft_reset_halt = target_soft_reset_halt_imp;
- target->type->run_algorithm_imp = target->type->run_algorithm;
- target->type->run_algorithm = target_run_algorithm_imp;
-
- /* Sanity-check MMU support ... stub in what we must, to help
-* implement it in stages, but warn if we need to do so.
-*/
- if (type->mmu) {
- if (type->write_phys_memory == NULL) {
- LOG_ERROR("type '%s' is missing %s",
- type->name,
- "write_phys_memory");
- type->write_phys_memory = err_write_phys_memory;
- }
- if (type->read_phys_memory == NULL) {
- LOG_ERROR("type '%s' is missing %s",
- type->name,
- "read_phys_memory");
- type->read_phys_memory = err_read_phys_memory;
- }
- if (type->virt2phys == NULL) {
- LOG_ERROR("type '%s' is missing %s",
- type->name,
- "virt2phys");
- type->virt2phys = identity_virt2phys;
- }
+ type->run_algorithm_imp = target->type->run_algorithm;
+ type->run_algorithm = target_run_algorithm_imp;
+ /* Sanity-check MMU support ... stub in what we must, to help
+* implement it in stages, b
[Openocd-development] [PATCH 0/7] split the 'init' command
Hi all, This series makes most of the individual steps in 'init' accessible to direct invocation. The changes should allow recovery in cases when OpenOCD is run interactively and (for example) you fail to specify an interface before trying to to run 'init'. These new subcommands help with the transition to fine-grained, context-sensitive commands. It also includes one patch to refactor target_init, whose previous monolithic form bugged me more than I could stand. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH 1/7] pld: factor init to 'pld init'
Split PLD initialization into 'pld init', which gets called from 'init'.
Signed-off-by: Zachary T Welch
---
src/openocd.c |5 +++--
src/pld/pld.c | 23 +++
2 files changed, 26 insertions(+), 2 deletions(-)
diff --git a/src/openocd.c b/src/openocd.c
index 44e0292..777e630 100644
--- a/src/openocd.c
+++ b/src/openocd.c
@@ -147,9 +147,10 @@ COMMAND_HANDLER(handle_init_command)
return ERROR_FAIL;
LOG_DEBUG("NAND init complete");
- if (pld_init(CMD_CTX) != ERROR_OK)
+ command_context_mode(CMD_CTX, COMMAND_CONFIG);
+ if (command_run_line(CMD_CTX, "pld init") != ERROR_OK)
return ERROR_FAIL;
- LOG_DEBUG("pld init complete");
+ command_context_mode(CMD_CTX, COMMAND_EXEC);
/* initialize telnet subsystem */
gdb_target_add_all(all_targets);
diff --git a/src/pld/pld.c b/src/pld/pld.c
index 24afd07..df7ac0d 100644
--- a/src/pld/pld.c
+++ b/src/pld/pld.c
@@ -213,6 +213,23 @@ int pld_init(struct command_context *cmd_ctx)
return register_commands(cmd_ctx, parent, pld_exec_command_handlers);
}
+COMMAND_HANDLER(handle_pld_init_command)
+{
+ if (CMD_ARGC != 0)
+ return ERROR_COMMAND_SYNTAX_ERROR;
+
+ static bool pld_initialized = false;
+ if (pld_initialized)
+ {
+ LOG_INFO("'pld init' has already been called");
+ return ERROR_OK;
+ }
+ pld_initialized = true;
+
+ LOG_DEBUG("Initializing PLDs...");
+ return pld_init(CMD_CTX);
+}
+
static const struct command_registration pld_config_command_handlers[] = {
{
.name = "device",
@@ -221,6 +238,12 @@ static const struct command_registration
pld_config_command_handlers[] = {
.help = "configure a PLD device",
.usage = " ...",
},
+ {
+ .name = "init",
+ .mode = COMMAND_CONFIG,
+ .handler = &handle_pld_init_command,
+ .help = "initialize PLD devices",
+ },
COMMAND_REGISTRATION_DONE
};
static const struct command_registration pld_command_handler[] = {
--
1.6.4.4
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH 5/7] jtag: factor init into 'jtag init'
Adds 'jtag init' command handler, which can be called as part of a
fine-grained 'init' process.
Signed-off-by: Zachary T Welch
---
src/jtag/tcl.c | 23 +++
src/openocd.c | 16 +---
2 files changed, 32 insertions(+), 7 deletions(-)
diff --git a/src/jtag/tcl.c b/src/jtag/tcl.c
index 68bb21e..cc89080 100644
--- a/src/jtag/tcl.c
+++ b/src/jtag/tcl.c
@@ -808,8 +808,31 @@ static int jim_jtag_names(Jim_Interp *interp, int argc,
Jim_Obj *const *argv)
return JIM_OK;
}
+COMMAND_HANDLER(handle_jtag_init_command)
+{
+ if (CMD_ARGC != 0)
+ return ERROR_COMMAND_SYNTAX_ERROR;
+
+ static bool jtag_initialized = false;
+ if (jtag_initialized)
+ {
+ LOG_INFO("'jtag init' has already been called");
+ return ERROR_OK;
+ }
+ jtag_initialized = true;
+
+ LOG_DEBUG("Initializing jtag devices...");
+ return jtag_init(CMD_CTX);
+}
+
static const struct command_registration jtag_subcommand_handlers[] = {
{
+ .name = "init",
+ .mode = COMMAND_CONFIG,
+ .handler = &handle_jtag_init_command,
+ .help = "initialize jtag scan chain",
+ },
+ {
.name = "interface",
.mode = COMMAND_ANY,
.jim_handler = &jim_jtag_interface,
diff --git a/src/openocd.c b/src/openocd.c
index aaa4531..79a30e7 100644
--- a/src/openocd.c
+++ b/src/openocd.c
@@ -126,16 +126,18 @@ COMMAND_HANDLER(handle_init_command)
/* Try to initialize & examine the JTAG chain at this point, but
* continue startup regardless */
- if (jtag_init(CMD_CTX) == ERROR_OK)
+ command_context_mode(CMD_CTX, COMMAND_CONFIG);
+ if (command_run_line(CMD_CTX, "jtag init") == ERROR_OK)
{
- LOG_DEBUG("jtag init complete");
- if (target_examine() == ERROR_OK)
- {
- LOG_DEBUG("jtag examine complete");
- }
+ command_context_mode(CMD_CTX, COMMAND_EXEC);
+ LOG_DEBUG("Examining targets...");
+ if (target_examine() != ERROR_OK)
+ LOG_DEBUG("target examination failed");
+ command_context_mode(CMD_CTX, COMMAND_CONFIG);
}
+ else
+ LOG_WARNING("jtag initialization failed; try 'jtag init'
again.");
- command_context_mode(CMD_CTX, COMMAND_CONFIG);
if (command_run_line(CMD_CTX, "flash init") != ERROR_OK)
return ERROR_FAIL;
--
1.6.4.4
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH 4/7] flash: factor init to 'flash init'
Split flash initialiation into 'flash init', called from 'init'.
Signed-off-by: Zachary T Welch
---
src/flash/flash.c | 23 +++
src/openocd.c |5 ++---
2 files changed, 25 insertions(+), 3 deletions(-)
diff --git a/src/flash/flash.c b/src/flash/flash.c
index 7023ef9..1e5ac9a 100644
--- a/src/flash/flash.c
+++ b/src/flash/flash.c
@@ -1375,6 +1375,23 @@ int flash_init_drivers(struct command_context *cmd_ctx)
return register_commands(cmd_ctx, parent, flash_exec_command_handlers);
}
+COMMAND_HANDLER(handle_flash_init_command)
+{
+ if (CMD_ARGC != 0)
+ return ERROR_COMMAND_SYNTAX_ERROR;
+
+ static bool flash_initialized = false;
+ if (flash_initialized)
+ {
+ LOG_INFO("'flash init' has already been called");
+ return ERROR_OK;
+ }
+ flash_initialized = true;
+
+ LOG_DEBUG("Initializing flash devices...");
+ return flash_init_drivers(CMD_CTX);
+}
+
static const struct command_registration flash_config_command_handlers[] = {
{
.name = "bank",
@@ -1387,6 +1404,12 @@ static const struct command_registration
flash_config_command_handlers[] = {
"using the specified NOR flash driver.",
},
{
+ .name = "init",
+ .mode = COMMAND_CONFIG,
+ .handler = &handle_flash_init_command,
+ .help = "initialize flash devices",
+ },
+ {
.name = "banks",
.mode = COMMAND_ANY,
.jim_handler = &jim_flash_banks,
diff --git a/src/openocd.c b/src/openocd.c
index ff35f87..aaa4531 100644
--- a/src/openocd.c
+++ b/src/openocd.c
@@ -135,11 +135,10 @@ COMMAND_HANDLER(handle_init_command)
}
}
- if (flash_init_drivers(CMD_CTX) != ERROR_OK)
+ command_context_mode(CMD_CTX, COMMAND_CONFIG);
+ if (command_run_line(CMD_CTX, "flash init") != ERROR_OK)
return ERROR_FAIL;
- LOG_DEBUG("flash init complete");
- command_context_mode(CMD_CTX, COMMAND_CONFIG);
if (command_run_line(CMD_CTX, "mflash init") != ERROR_OK)
return ERROR_FAIL;
--
1.6.4.4
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH 2/7] nand: factor init to 'nand init'
Split NAND initialization into 'nand init', which gets called from
the main 'init' command.
Signed-off-by: Zachary T Welch
---
src/flash/nand.c | 26 ++
src/openocd.c|5 ++---
2 files changed, 28 insertions(+), 3 deletions(-)
diff --git a/src/flash/nand.c b/src/flash/nand.c
index 94cec8d..1c8c0c8 100644
--- a/src/flash/nand.c
+++ b/src/flash/nand.c
@@ -281,6 +281,9 @@ COMMAND_HANDLER(handle_nand_device_command)
return CALL_COMMAND_HANDLER(handle_nand_list_drivers);
}
+
+COMMAND_HANDLER(handle_nand_init_command);
+
static const struct command_registration nand_config_command_handlers[] = {
{
.name = "device",
@@ -294,6 +297,12 @@ static const struct command_registration
nand_config_command_handlers[] = {
.mode = COMMAND_ANY,
.help = "lists available NAND drivers",
},
+ {
+ .name = "init",
+ .mode = COMMAND_CONFIG,
+ .handler = &handle_nand_init_command,
+ .help = "initialize NAND devices",
+ },
COMMAND_REGISTRATION_DONE
};
static const struct command_registration nand_command_handlers[] = {
@@ -1794,3 +1803,20 @@ int nand_init(struct command_context *cmd_ctx)
struct command *parent = command_find_in_context(cmd_ctx, "nand");
return register_commands(cmd_ctx, parent, nand_exec_command_handlers);
}
+
+COMMAND_HANDLER(handle_nand_init_command)
+{
+ if (CMD_ARGC != 0)
+ return ERROR_COMMAND_SYNTAX_ERROR;
+
+ static bool nand_initialized = false;
+ if (nand_initialized)
+ {
+ LOG_INFO("'nand init' has already been called");
+ return ERROR_OK;
+ }
+ nand_initialized = true;
+
+ LOG_DEBUG("Initializing NAND devices...");
+ return nand_init(CMD_CTX);
+}
diff --git a/src/openocd.c b/src/openocd.c
index 777e630..1026379 100644
--- a/src/openocd.c
+++ b/src/openocd.c
@@ -143,11 +143,10 @@ COMMAND_HANDLER(handle_init_command)
return ERROR_FAIL;
LOG_DEBUG("mflash init complete");
- if (nand_init(CMD_CTX) != ERROR_OK)
+ command_context_mode(CMD_CTX, COMMAND_CONFIG);
+ if (command_run_line(CMD_CTX, "nand init") != ERROR_OK)
return ERROR_FAIL;
- LOG_DEBUG("NAND init complete");
- command_context_mode(CMD_CTX, COMMAND_CONFIG);
if (command_run_line(CMD_CTX, "pld init") != ERROR_OK)
return ERROR_FAIL;
command_context_mode(CMD_CTX, COMMAND_EXEC);
--
1.6.4.4
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH 3/7] mflash: factor init to 'mflash init'
Splits mflash initialiation to 'mflash init', called from 'init'.
Signed-off-by: Zachary T Welch
---
src/flash/mflash.c | 23 +++
src/openocd.c |5 ++---
2 files changed, 25 insertions(+), 3 deletions(-)
diff --git a/src/flash/mflash.c b/src/flash/mflash.c
index 03a56e2..8f42aa6 100644
--- a/src/flash/mflash.c
+++ b/src/flash/mflash.c
@@ -1304,6 +1304,23 @@ int mflash_init_drivers(struct command_context *cmd_ctx)
return register_commands(cmd_ctx, NULL, mflash_exec_command_handlers);
}
+COMMAND_HANDLER(handle_mflash_init_command)
+{
+ if (CMD_ARGC != 0)
+ return ERROR_COMMAND_SYNTAX_ERROR;
+
+ static bool mflash_initialized = false;
+ if (mflash_initialized)
+ {
+ LOG_INFO("'mflash init' has already been called");
+ return ERROR_OK;
+ }
+ mflash_initialized = true;
+
+ LOG_DEBUG("Initializing mflash devices...");
+ return mflash_init_drivers(CMD_CTX);
+}
+
COMMAND_HANDLER(mg_bank_cmd)
{
struct target *target;
@@ -1352,6 +1369,12 @@ static const struct command_registration
mflash_config_command_handlers[] = {
.help = "configure a mflash device bank",
.usage = " ",
},
+ {
+ .name = "init",
+ .mode = COMMAND_CONFIG,
+ .handler = &handle_mflash_init_command,
+ .help = "initialize mflash devices",
+ },
COMMAND_REGISTRATION_DONE
};
static const struct command_registration mflash_command_handler[] = {
diff --git a/src/openocd.c b/src/openocd.c
index 1026379..ff35f87 100644
--- a/src/openocd.c
+++ b/src/openocd.c
@@ -139,11 +139,10 @@ COMMAND_HANDLER(handle_init_command)
return ERROR_FAIL;
LOG_DEBUG("flash init complete");
- if (mflash_init_drivers(CMD_CTX) != ERROR_OK)
+ command_context_mode(CMD_CTX, COMMAND_CONFIG);
+ if (command_run_line(CMD_CTX, "mflash init") != ERROR_OK)
return ERROR_FAIL;
- LOG_DEBUG("mflash init complete");
- command_context_mode(CMD_CTX, COMMAND_CONFIG);
if (command_run_line(CMD_CTX, "nand init") != ERROR_OK)
return ERROR_FAIL;
--
1.6.4.4
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] flyswatter and beagleboard
Doh! Working now. I had the beagle board adapter plugged into the beagle instead of the flyswatter. On Tue, Dec 1, 2009 at 1:49 PM, John Rigby wrote: > I already tried that: > > $ telnet localhost > Trying ::1... > Trying 127.0.0.1... > Connected to localhost. > Escape character is '^]'. > Open On-Chip Debugger >> reset halt > RCLK not supported - fallback to 1000 kHz > JTAG scan chain interrogation failed: all ones > Check JTAG interface, timings, target power, etc. > error: -100 > Command handler execution failed > in procedure 'reset' called at file "command.c", line 637 > called at file "command.c", line 352 >> > > Its like I've got the jtag connector connected wrong. I'm using the > beagle board adapter that I got from tincantools. And I have all the > pin 1s matched up. > > On Tue, Dec 1, 2009 at 1:41 PM, David Brownell wrote: >> On Tuesday 01 December 2009, John Rigby wrote: >>> I'm trying to use OpenOCD with a Flyswatter and a beagleboard and I get >>> this: >>> >>> # openocd -f ./tcl/interface/flyswatter.cfg -f >>> ./tcl/board/ti_beagleboard.cfg >>> Open On-Chip Debugger 0.4.0-dev-00740-ga65e75e (2009-12-01-12:05) >>> For bug reports, read >>> http://openocd.berlios.de/doc/doxygen/bugs.html >>> RCLK - adaptive >>> Warn : omap3530.dsp: huge IR length 38 >>> RCLK - adaptive >>> trst_only separate trst_push_pull >>> Info : RCLK (adaptive clock speed) not supported - fallback to 1000 kHz >>> Error: JTAG scan chain interrogation failed: all ones >>> Error: Check JTAG interface, timings, target power, etc. >>> Error: JTAG scan chain interrogation failed: all ones >>> Error: Check JTAG interface, timings, target power, etc. >>> >>> Any ideas? >> >> "reset halt" should make things work OK. >> >> I don't know what causes that startup glitch, but things seem to >> behave OK after an explicit reset. >> >> >> > ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 2/4] produce stack traces on segfaults
On Tue, Dec 1, 2009 at 10:32 AM, Zach Welch wrote: > On Tue, 2009-12-01 at 10:25 +0100, Øyvind Harboe wrote: >> On Tue, Dec 1, 2009 at 10:17 AM, Zach Welch 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. /Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] flyswatter and beagleboard
I already tried that: $ telnet localhost Trying ::1... Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. Open On-Chip Debugger > reset halt RCLK not supported - fallback to 1000 kHz JTAG scan chain interrogation failed: all ones Check JTAG interface, timings, target power, etc. error: -100 Command handler execution failed in procedure 'reset' called at file "command.c", line 637 called at file "command.c", line 352 > Its like I've got the jtag connector connected wrong. I'm using the beagle board adapter that I got from tincantools. And I have all the pin 1s matched up. On Tue, Dec 1, 2009 at 1:41 PM, David Brownell wrote: > On Tuesday 01 December 2009, John Rigby wrote: >> I'm trying to use OpenOCD with a Flyswatter and a beagleboard and I get this: >> >> # openocd -f ./tcl/interface/flyswatter.cfg -f ./tcl/board/ti_beagleboard.cfg >> Open On-Chip Debugger 0.4.0-dev-00740-ga65e75e (2009-12-01-12:05) >> For bug reports, read >> http://openocd.berlios.de/doc/doxygen/bugs.html >> RCLK - adaptive >> Warn : omap3530.dsp: huge IR length 38 >> RCLK - adaptive >> trst_only separate trst_push_pull >> Info : RCLK (adaptive clock speed) not supported - fallback to 1000 kHz >> Error: JTAG scan chain interrogation failed: all ones >> Error: Check JTAG interface, timings, target power, etc. >> Error: JTAG scan chain interrogation failed: all ones >> Error: Check JTAG interface, timings, target power, etc. >> >> Any ideas? > > "reset halt" should make things work OK. > > I don't know what causes that startup glitch, but things seem to > behave OK after an explicit reset. > > > ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] flyswatter and beagleboard
On Tuesday 01 December 2009, John Rigby wrote: > I'm trying to use OpenOCD with a Flyswatter and a beagleboard and I get this: > > # openocd -f ./tcl/interface/flyswatter.cfg -f ./tcl/board/ti_beagleboard.cfg > Open On-Chip Debugger 0.4.0-dev-00740-ga65e75e (2009-12-01-12:05) > For bug reports, read > http://openocd.berlios.de/doc/doxygen/bugs.html > RCLK - adaptive > Warn : omap3530.dsp: huge IR length 38 > RCLK - adaptive > trst_only separate trst_push_pull > Info : RCLK (adaptive clock speed) not supported - fallback to 1000 kHz > Error: JTAG scan chain interrogation failed: all ones > Error: Check JTAG interface, timings, target power, etc. > Error: JTAG scan chain interrogation failed: all ones > Error: Check JTAG interface, timings, target power, etc. > > Any ideas? "reset halt" should make things work OK. I don't know what causes that startup glitch, but things seem to behave OK after an explicit reset. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] flyswatter and beagleboard
I'm trying to use OpenOCD with a Flyswatter and a beagleboard and I get this: # openocd -f ./tcl/interface/flyswatter.cfg -f ./tcl/board/ti_beagleboard.cfg Open On-Chip Debugger 0.4.0-dev-00740-ga65e75e (2009-12-01-12:05) For bug reports, read http://openocd.berlios.de/doc/doxygen/bugs.html RCLK - adaptive Warn : omap3530.dsp: huge IR length 38 RCLK - adaptive trst_only separate trst_push_pull Info : RCLK (adaptive clock speed) not supported - fallback to 1000 kHz Error: JTAG scan chain interrogation failed: all ones Error: Check JTAG interface, timings, target power, etc. Error: JTAG scan chain interrogation failed: all ones Error: Check JTAG interface, timings, target power, etc. Any ideas? Thanks John ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 2/4] produce stack traces on segfaults
On Tuesday 01 December 2009, Øyvind Harboe wrote: > Zach made a good point that there are bug reports we are not receiving > today. Those are the ones he's after here I think. I'm sure this project loses more potential bug reports by requiring folk to subscribe to Yet Another Mailing List than we lose by somehow preventing them from including stack dumps. If the list were not closed, it would be trivial to send in reports like "if I do then , what's up?". For any type of bug, not just segfaults. As it is, there's extra work that needs doing before even such a one-shot report could be *sent* ... and that extra work is rarely getting done. Think about how many "it segfaults" reports we actually see... I don't recall seeing one, they're not exactly a common type of bug. (And shouldn't be.) Subject to change of course. - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 2/4] produce stack traces on segfaults
On Tue, Dec 1, 2009 at 1:49 PM, Michael Schwingen wrote: > Zach Welch wrote: >> To be fair, these extra steps also moot my Heisenbug argument; however, >> these are still activities that could be expected by these platforms' >> users. Running GDB is not a user activity, except _possibly_ when using >> it _with_ OpenOCD. Remember, not everyone uses OpenOCD with GDB. >> >> I consider our "users" to include those developers who want to use >> OpenOCD as a replacement for an off-the-shelf tool. Such users do not >> want to be told to debug OpenOCD with GDB, but they might be convinced >> to install a debugging version of it (e.g. from Git). Too many users >> might give up when they hear that they need to run GDB to debug the >> feature that causes a crash for them. That goes for any package where >> They Just Wanted To Use It. >> > I don't see why starting gdb to generate a bug report is such a big > problem - especially if we provide step-by-step instructions or even a > script that does the dirty work. Zach made a good point that there are bug reports we are not receiving today. Those tare the ones he's after here I think. I don't view the two methods as mutually exclusive, but I wonder if creating some end-user debug scripts might be lower hanging fruit... -- Øyvind Harboe US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 2/4] produce stack traces on segfaults
Zach Welch wrote: > To be fair, these extra steps also moot my Heisenbug argument; however, > these are still activities that could be expected by these platforms' > users. Running GDB is not a user activity, except _possibly_ when using > it _with_ OpenOCD. Remember, not everyone uses OpenOCD with GDB. > > I consider our "users" to include those developers who want to use > OpenOCD as a replacement for an off-the-shelf tool. Such users do not > want to be told to debug OpenOCD with GDB, but they might be convinced > to install a debugging version of it (e.g. from Git). Too many users > might give up when they hear that they need to run GDB to debug the > feature that causes a crash for them. That goes for any package where > They Just Wanted To Use It. > I don't see why starting gdb to generate a bug report is such a big problem - especially if we provide step-by-step instructions or even a script that does the dirty work. If you expect the user to install (or even build) a debug-version of openocd, I see no problem to tell the user "run the report-bug script" which then internally starts openocd from gdb and provides the necessary information (backtrace, variables etc.). Installing gdb is easier on most systems than installing/building a debug version of openocd, so I can't see where this fear of using gdb comes from. cu Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 2/4] produce stack traces on segfaults
On Tue, 2009-12-01 at 11:27 +0100, Michael Schwingen wrote: > Zach Welch 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. > >> > > > > You clearly missed the part where I say it will be selectable, and > > "none" would also be an option. *poof* It could disappear. > > > But then "none" would have to be the default for distributions - which > means you would gain nothing for user-submitted crash reports. Well, none could still mean glibc, which is all that is used now. I do not see a reason to strip out any glibc-based functionality on systems using it, unless a particular platform lacks those features. IIRC, the actual checks right now would be for dlfcn.h and execinfo.h. Eventually, the 'none' option would be for only those platforms that lack an equivalent native solution that requires no new dependencies. To be perfectly honestly, the actual reason we might gain nothing is that most distributions strip their binaries of debugging symbols, so not even GDB would be able to do much with them in the default case. There are usually ways around that, including rebuilding OpenOCD unstripped using the native package manager (e.g. Gentoo) or installing a separate package that contains the debugging information (e.g. OpenEmbedded, Debian). To be fair, these extra steps also moot my Heisenbug argument; however, these are still activities that could be expected by these platforms' users. Running GDB is not a user activity, except _possibly_ when using it _with_ OpenOCD. Remember, not everyone uses OpenOCD with GDB. I consider our "users" to include those developers who want to use OpenOCD as a replacement for an off-the-shelf tool. Such users do not want to be told to debug OpenOCD with GDB, but they might be convinced to install a debugging version of it (e.g. from Git). Too many users might give up when they hear that they need to run GDB to debug the feature that causes a crash for them. That goes for any package where They Just Wanted To Use It. As challenging as this work can be at times, they may give up for other reasons later anyway... why make bug reporting any harder for users than it absolutely needs to be? Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 2/4] produce stack traces on segfaults
On Tue, 2009-12-01 at 11:14 +0100, Øyvind Harboe wrote: > > Again, you have missed the point. This is about users and our releases. > > I cannot make that point more clearly. It is not about developers who > > are willing to use GDB. It's about users who aren't. > > I haven't done the statistics, but are we not seing SEGFAULT's > in development builds mostly? Mostly. Without built-in stack traces, we may not be getting good reports even from casual developers, as they decide it's too much work to track down a random bug. If the stack trace makes the bug reporting process a little bit easier, right there, it's a win for us And this shows how we need to take selection bias when accounting for the present state of affairs. We can't assume that the lack of segfault reports means a lack of segfaults. It could show unwillingness to track down odd crashes that users experience only now and again. Personally, I won't work very hard to reproduce a random crash, but a stack trace would give me an potential fast-path to the means of investigating it immediately. Some bugs require a set of such traces before their cause becomes apparent, and I'm am a little surprised we haven't had more of them with Jim. I sure could have used this feature when working on the 'unknown' command handler. I could have completely skipped using GDB at all, but I had to break down when I hit some trouble with recursion. The new stack facilities offer the ability to add an algorithm that spots endless recursion in Jim by looking for a pattern of N repeating k-frames (where N is fairly big). Or, it could be used to find a high-water mark for our stack usage, and simply warn when it exceeds that by some threshold. That shows how this code could be used to improve our deployed runtime resilience, putting aside symbol lookup. For the relative complexity of its interpreted language, Jim seems to cause us comparatively little grief as far as bug reports go. That's another reason that I see it as daunting to tackle a clean-up; it's likely to only cause regressions. ;) > I'm interested in your solution, but I don't want to see it pushed *soon*. > > Is there a particular urgency to get this resolved *now* or do I > have time? (a week or two). It's not high pressure, and I need to implement no-op versions that can be used by platforms that lack their own implementation. With such facilities in place, others can add support for these (presently) optional APIs at their own leisure. This will make it easy to phase in loadable module support later, which -- of course -- will be a completely optional feature too. --Z ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 2/4] produce stack traces on segfaults
Zach Welch 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. >> > > You clearly missed the part where I say it will be selectable, and > "none" would also be an option. *poof* It could disappear. > But then "none" would have to be the default for distributions - which means you would gain nothing for user-submitted crash reports. cu Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 2/4] produce stack traces on segfaults
> Again, you have missed the point. This is about users and our releases. > I cannot make that point more clearly. It is not about developers who > are willing to use GDB. It's about users who aren't. I haven't done the statistics, but are we not seing SEGFAULT's in development builds mostly? I'm interested in your solution, but I don't want to see it pushed *soon*. Is there a particular urgency to get this resolved *now* or do I have time? (a week or two). -- Øyvind Harboe US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 2/4] produce stack traces on segfaults
On Tue, 2009-12-01 at 11:06 +0100, Øyvind Harboe wrote: > On Tue, Dec 1, 2009 at 11:02 AM, Zach Welch wrote: > > On Tue, 2009-12-01 at 10:36 +0100, Øyvind Harboe wrote: > >> >> > 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? > >> > >> You're not answering the question: > > > > You're not seeing my point. > > > >> How is your solution better than writing a script "openocd" that launches > >> openocd from GDB by default? > > > > You want to _force_ me to _always_ run GDB, to catch random segfaults? > > Explain what's so bad about that, at least for non-releases. Again, you have missed the point. This is about users and our releases. I cannot make that point more clearly. It is not about developers who are willing to use GDB. It's about users who aren't. > A bt + dumping local variables would be superior to your code > in terms of information provided, right? But not in usability. Right? > > Please tell me (justly) I'm wrong. > > I have not tried your patches, I assume they work and do what > you describe. > > I'm not *against* your patches, I'm just trying to tie up some loose > ends in alternatives we don't seem to have considered yet. There really is no alternative that provides this level of usability, or I would not have bothered to write this code. --Z ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 2/4] produce stack traces on segfaults
On Tue, Dec 1, 2009 at 11:02 AM, Zach Welch wrote: > On Tue, 2009-12-01 at 10:36 +0100, Øyvind Harboe wrote: >> >> > 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? >> >> You're not answering the question: > > You're not seeing my point. > >> How is your solution better than writing a script "openocd" that launches >> openocd from GDB by default? > > You want to _force_ me to _always_ run GDB, to catch random segfaults? Explain what's so bad about that, at least for non-releases. A bt + dumping local variables would be superior to your code in terms of information provided, right? > Please tell me (justly) I'm wrong. I have not tried your patches, I assume they work and do what you describe. I'm not *against* your patches, I'm just trying to tie up some loose ends in alternatives we don't seem to have considered yet. -- Øyvind Harboe US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 2/4] produce stack traces on segfaults
On Tue, 2009-12-01 at 10:36 +0100, Øyvind Harboe wrote: > >> > 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? > > You're not answering the question: You're not seeing my point. > How is your solution better than writing a script "openocd" that launches > openocd from GDB by default? You want to _force_ me to _always_ run GDB, to catch random segfaults? If you agree that such would be _unreasonable_ to ask, then when I get a segfault out-of-the-blue after working interactively, you expect me to reproduce it? What if I can't? And you could ask *users* to do that, and keep a straight face? The very notion should cause embarrassment. We have seen reports from users where the last line is "Segmentation Fault" and that's all they did. Your theory about asking people to do extra work has been shown to be ineffective at best, and it's downright annoying to consider the lack of respect that excluding this type of feature shows our _users_. > This script could run a bt automatically and create a "bug" file. To boot > we could add a circular debug_level 3 memory buffer that is dumped > at the same time... > > In releases we could default to running without gdb/debug_level 3 all the > time. How is this better than built-in, automatic stack traces? Exactly? I have code that works, adds value, and I will address and shortcomings regarding portability and selectability. Now, show me your solution. The burden is on _you_ to explain how your solution is better, because I do not buy the crap you guys are slinging tonight. I have explained repeatedly and clearly how this will benefit _users_, and it's really irritating me to see resistance to this idea -- when I bet most of you haven't even tried my patches yet. Please tell me (justly) I'm wrong. --Z ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 2/4] produce stack traces on segfaults
On Tue, 2009-12-01 at 01:52 -0800, David Brownell wrote: > On Tuesday 01 December 2009, Zach Welch wrote: > > On Tue, 2009-12-01 at 01:23 -0800, David Brownell 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. > > > > > > Any developer who's not willing to run GDB to catch a fault ... > > > take them out back behind the woodshed and "bugfix" them! ;) > > > > If they _can_ catch it, sure. However, you're now talking about doing > > harm to the messengers. That's highly counterproductive. Asking > > someone to do extra work that could have been avoided is crap attitude. > > I'm actually talking hyperbole. And as for "extra work" ... it's > something of a question about *who* does the work. Person seeing > a problem? Motivated to resolve it. Everyone else? ... not. It's demotivational to consider this feature being excluded, when it would save work for developers with little to no cost. And it's wrong to ask users to do any extra work that we could have done for them. I am a user, and it's wrong for anyone to ask me to keep running GDB to produce stack traces when I am offering to provide patches that will provide this support in-tree in a portable and selectable manner. Wrong, I tell's ya'. > > > No end user should ever see segfaults, or any other flavor of > > > rude/unexpected exit. If they see one that's quite a major > > > bug in the code. > > > > I reiterate my principle point: heisenbugs. The code is not yet pretty > > enough for me to feel that this handler will never be exercised in > > unpredictable contexts, nor do I feel our processes have yet reached a > > point where we can prevent adding such triggers in the future. > > And what better way to make sure we improve our processes than > to stop buying band-aids to apply over spurting wounds? :) > (Hyperbole again, it's late.) No, it's called "belated triage". :) --Z ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 1/3] command: the Jim interpreter can now be provided rather than created
> For OpenOCD, it is not nearly as hard as you make it seem: > > 1) Rename ecosboard.c as openocd_ecos.c > 2) Add openocd_common.c, openocd_linux.c, openocd_win32.c, etc. > 3) Declare stuff in openocd.h and define them in all files. Some files > will declare only stubs... others will OK. This sounds like a reasonable direction to go in + the assert you mentioned. It is separate from knocking jim into shape, which is good. -- Øyvind Harboe US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 2/4] produce stack traces on segfaults
On Tuesday 01 December 2009, Zach Welch wrote: > On Tue, 2009-12-01 at 01:23 -0800, David Brownell 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. > > > > Any developer who's not willing to run GDB to catch a fault ... > > take them out back behind the woodshed and "bugfix" them! ;) > > If they _can_ catch it, sure. However, you're now talking about doing > harm to the messengers. That's highly counterproductive. Asking > someone to do extra work that could have been avoided is crap attitude. I'm actually talking hyperbole. And as for "extra work" ... it's something of a question about *who* does the work. Person seeing a problem? Motivated to resolve it. Everyone else? ... not. > > No end user should ever see segfaults, or any other flavor of > > rude/unexpected exit. If they see one that's quite a major > > bug in the code. > > I reiterate my principle point: heisenbugs. The code is not yet pretty > enough for me to feel that this handler will never be exercised in > unpredictable contexts, nor do I feel our processes have yet reached a > point where we can prevent adding such triggers in the future. And what better way to make sure we improve our processes than to stop buying band-aids to apply over spurting wounds? :) (Hyperbole again, it's late.) ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 2/4] produce stack traces on segfaults
On Tuesday 01 December 2009, Øyvind Harboe wrote: > > The src/openocd invocation is usually preceded by a comment > > > > # gdb --args \ > > this script does not work when some of the args have a space > in them, but yes, a script pretty much like that one. :-) The args get quoted. GDB understands all that. The "#" gets removed if I've got to chase any of the wierd things which sometimes appear, but which usually aren't present. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 1/3] command: the Jim interpreter can now be provided rather than created
On Tue, 2009-12-01 at 10:24 +0100, Øyvind Harboe wrote: > On Tue, Dec 1, 2009 at 10:19 AM, Zach Welch wrote: > > On Tue, 2009-12-01 at 10:16 +0100, Øyvind Harboe wrote: > >> > The patch to ecosboard.c always gives a non-NULL value, and we always > >> > pass in NULL from openocd.c. The #if is entirely redundant when you > >> > take a moment to look at the big picture. > >> > >> Except it doesn't build, it's that messy bit with difference build modes > >> for > >> Jim. > >> > >> I'm kinda hopeful that the #if can be removed eventually if Jim improves > >> to have a less obtuse way to handle embedded vs. using in include files... > > > > I have been meaning to produce a series that seriously cleans up the #if > > madness that we have going on. This nonsense drives me insane. I have > > a solution for this particular problem, so maybe it's time to start it. > > W.r.t. Jim Tcl there be dragons. Btw, Jim Tcl is is trying to recruit > a new maintainer... If I took it over, I would fork and start on a new major revision. The current version appears to be unmaintainable... which, incidentally, might be why it needs a new maintainer. ;) > Are you sure you it's a good idea to start this now? Yes, but you are verily confused about my direction. > To truly tackle this you would have to handle different cases: jim tcl > in shared library, jim tcl statically linked, jim tcl created by someone > else than OpenOCD... For OpenOCD, it is not nearly as hard as you make it seem: 1) Rename ecosboard.c as openocd_ecos.c 2) Add openocd_common.c, openocd_linux.c, openocd_win32.c, etc. 3) Declare stuff in openocd.h and define them in all files. Some files will declare only stubs... others will This would allow us to get rid of most Win32, eCos, and other platform-related #if's throughout the tree, perhaps all of them. However, the original patch from $SUBJECT could still be improved: that #if block can be moved to openocd.c, which has the effect today as the plan above would accomplish. Thus, we can add 'assert(interp)' at the top of the command_init routine, as both callers pass it in. --Z ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 2/4] produce stack traces on segfaults
>> > 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? You're not answering the question: How is your solution better than writing a script "openocd" that launches openocd from GDB by default? This script could run a bt automatically and create a "bug" file. To boot we could add a circular debug_level 3 memory buffer that is dumped at the same time... In releases we could default to running without gdb/debug_level 3 all the time. -- Øyvind Harboe US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 2/4] produce stack traces on segfaults
On Tue, 2009-12-01 at 10:25 +0100, Øyvind Harboe wrote: > On Tue, Dec 1, 2009 at 10:17 AM, Zach Welch 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? --Z ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 2/4] produce stack traces on segfaults
On Tue, 2009-12-01 at 01:23 -0800, David Brownell 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. > > Any developer who's not willing to run GDB to catch a fault ... > take them out back behind the woodshed and "bugfix" them! ;) If they _can_ catch it, sure. However, you're now talking about doing harm to the messengers. That's highly counterproductive. Asking someone to do extra work that could have been avoided is crap attitude. > No end user should ever see segfaults, or any other flavor of > rude/unexpected exit. If they see one that's quite a major > bug in the code. I reiterate my principle point: heisenbugs. The code is not yet pretty enough for me to feel that this handler will never be exercised in unpredictable contexts, nor do I feel our processes have yet reached a point where we can prevent adding such triggers in the future. --Z ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 2/4] produce stack traces on segfaults
2009/12/1 David Brownell : > On Tuesday 01 December 2009, Ųyvind Harboe wrote: >> How about adding an option to statically link with GDB or create >> a script that launched OpenOCD via GDB as default? > > I have shell scripts that start up OpenOCD and points it > at a particular board. > > The src/openocd invocation is usually preceded by a comment > > # gdb --args \ this script does not work when some of the args have a space in them, but yes, a script pretty much like that one. :-) > so it's trivial to start GDB if I need it. No need for > anything as part of the source tree... Less is more... generally I don't want to start recreating valgrind inside OpenOCD either... -- Øyvind Harboe US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 2/4] produce stack traces on segfaults
On Tuesday 01 December 2009, Øyvind Harboe wrote: > How about adding an option to statically link with GDB or create > a script that launched OpenOCD via GDB as default? I have shell scripts that start up OpenOCD and points it at a particular board. The src/openocd invocation is usually preceded by a comment # gdb --args \ so it's trivial to start GDB if I need it. No need for anything as part of the source tree... ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] arm: dcc_downloads and fast_memory_access are now enabled by default
On Tue, 2009-12-01 at 09:18 +0100, Øyvind Harboe wrote: > On Tue, Dec 1, 2009 at 9:03 AM, Zach Welch wrote: > > On Tue, 2009-12-01 at 08:52 +0100, Øyvind Harboe wrote: > >> > How about a warning when it's _not_ explicitly enabled or disabled by > >> > the user? Specifically, tell the users to try enabling those features > >> > or to add explicit commands to stop the warnings. Scripts for boards > >> > where that feature will be safe by default could add the required > >> > commands, and users for others will be able to read the documentation > >> > for those commands decide for themselves. > >> > > >> > This keeps the default safe while giving users the nudge in the > >> > direction that you feel they will want to be headed -- eventually. > >> > >> I think this is a good way to go forward. > >> > >> Here is a though on implementation: each target defines a default > >> post-reset script, there is some suitable event that exists currently > >> I'm sure. This post reset script does checks and prints out > >> hints and warnings. > > > > Anything that requires defining a new default gets a frown of > > disapproval from me. That breaks backwards-compatibility, which is > > another reason not to change the default without more consideration and > > wide-spread testing. A warning in the C code should be enough to induce > > that desired outcome, if you also tell users to report their results in > > order to help us decide whether to enable it by default. > > You misunderstand. I would like to see a default tcl handler added > that can be overridden. This tcl handler would not change anything, > just do checks and print warnings. > > No change in defaults. That does not seem like the right approach for this particular problem, though a handler might be useful to have in other contexts. If it checks for more than one error, then overriding that method eliminates them all. The technique I propose lets the user eliminate one warning at a time through explicit actions. If you want a 'go_fast' wrapper that does all of them at once, that's your policy to decide. --Z ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 2/4] produce stack traces on segfaults
On Tue, Dec 1, 2009 at 10:17 AM, Zach Welch 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... -- Øyvind Harboe US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 1/3] command: the Jim interpreter can now be provided rather than created
On Tue, Dec 1, 2009 at 10:19 AM, Zach Welch wrote: > On Tue, 2009-12-01 at 10:16 +0100, Øyvind Harboe wrote: >> > The patch to ecosboard.c always gives a non-NULL value, and we always >> > pass in NULL from openocd.c. The #if is entirely redundant when you >> > take a moment to look at the big picture. >> >> Except it doesn't build, it's that messy bit with difference build modes for >> Jim. >> >> I'm kinda hopeful that the #if can be removed eventually if Jim improves >> to have a less obtuse way to handle embedded vs. using in include files... > > I have been meaning to produce a series that seriously cleans up the #if > madness that we have going on. This nonsense drives me insane. I have > a solution for this particular problem, so maybe it's time to start it. W.r.t. Jim Tcl there be dragons. Btw, Jim Tcl is is trying to recruit a new maintainer... Are you sure you it's a good idea to start this now? To truly tackle this you would have to handle different cases: jim tcl in shared library, jim tcl statically linked, jim tcl created by someone else than OpenOCD... -- Øyvind Harboe US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 2/4] produce stack traces on segfaults
> > > 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. Any developer who's not willing to run GDB to catch a fault ... take them out back behind the woodshed and "bugfix" them! ;) No end user should ever see segfaults, or any other flavor of rude/unexpected exit. If they see one that's quite a major bug in the code. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 1/3] command: the Jim interpreter can now be provided rather than created
On Tue, 2009-12-01 at 10:16 +0100, Øyvind Harboe wrote: > > The patch to ecosboard.c always gives a non-NULL value, and we always > > pass in NULL from openocd.c. The #if is entirely redundant when you > > take a moment to look at the big picture. > > Except it doesn't build, it's that messy bit with difference build modes for > Jim. > > I'm kinda hopeful that the #if can be removed eventually if Jim improves > to have a less obtuse way to handle embedded vs. using in include files... I have been meaning to produce a series that seriously cleans up the #if madness that we have going on. This nonsense drives me insane. I have a solution for this particular problem, so maybe it's time to start it. --Z ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 2/4] produce stack traces on segfaults
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. --Z ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 1/3] command: the Jim interpreter can now be provided rather than created
> The patch to ecosboard.c always gives a non-NULL value, and we always > pass in NULL from openocd.c. The #if is entirely redundant when you > take a moment to look at the big picture. Except it doesn't build, it's that messy bit with difference build modes for Jim. I'm kinda hopeful that the #if can be removed eventually if Jim improves to have a less obtuse way to handle embedded vs. using in include files... -- Øyvind Harboe US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 2/4] produce stack traces on segfaults
On Tue, 2009-12-01 at 09:37 +0100, Michael Schwingen wrote: > 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. You clearly missed the part where I say it will be selectable, and "none" would also be an option. *poof* It could disappear. > > 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? Have you never had a Heisenbug before? --Z ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 1/3] command: the Jim interpreter can now be provided rather than created
On Tue, 2009-12-01 at 09:17 +0100, Øyvind Harboe wrote: > >> #if !BUILD_ECOSBOARD > > > > It is now safe to kill this #if logic too. It's like a bonus prize. ;) > > Almost, but not quite. I tried before I remembered that > Jim is embedded into the athttpd server... You know the > slightly messy and awkward jump tables that Jim uses... That's not true. It _can_ be removed. If interp is NULL, then we dang well had better create it right then and there, or the code will crash. The patch to ecosboard.c always gives a non-NULL value, and we always pass in NULL from openocd.c. The #if is entirely redundant when you take a moment to look at the big picture. --Z ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 2/4] produce stack traces on segfaults
> 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? -- Øyvind Harboe US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 2/4] produce stack traces on segfaults
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
Re: [Openocd-development] [PATCH] arm: dcc_downloads and fast_memory_access are now enabled by default
On Tue, Dec 1, 2009 at 9:03 AM, Zach Welch wrote: > On Tue, 2009-12-01 at 08:52 +0100, Øyvind Harboe wrote: >> > How about a warning when it's _not_ explicitly enabled or disabled by >> > the user? Specifically, tell the users to try enabling those features >> > or to add explicit commands to stop the warnings. Scripts for boards >> > where that feature will be safe by default could add the required >> > commands, and users for others will be able to read the documentation >> > for those commands decide for themselves. >> > >> > This keeps the default safe while giving users the nudge in the >> > direction that you feel they will want to be headed -- eventually. >> >> I think this is a good way to go forward. >> >> Here is a though on implementation: each target defines a default >> post-reset script, there is some suitable event that exists currently >> I'm sure. This post reset script does checks and prints out >> hints and warnings. > > Anything that requires defining a new default gets a frown of > disapproval from me. That breaks backwards-compatibility, which is > another reason not to change the default without more consideration and > wide-spread testing. A warning in the C code should be enough to induce > that desired outcome, if you also tell users to report their results in > order to help us decide whether to enable it by default. You misunderstand. I would like to see a default tcl handler added that can be overridden. This tcl handler would not change anything, just do checks and print warnings. No change in defaults. -- Øyvind Harboe US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 1/3] command: the Jim interpreter can now be provided rather than created
>> #if !BUILD_ECOSBOARD > > It is now safe to kill this #if logic too. It's like a bonus prize. ;) Almost, but not quite. I tried before I remembered that Jim is embedded into the athttpd server... You know the slightly messy and awkward jump tables that Jim uses... I'll push the two patches soonish. -- Øyvind Harboe US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 1/3] command: the Jim interpreter can now be provided rather than created
Only one minor suggested improvement, below. Otherwise, these both look
okay to me.
On Tue, 2009-12-01 at 08:48 +0100, Øyvind Harboe wrote:
> In embedded hosts, the Jim interpreter can come from the
> existing context rather than be created by OpenOCD.
>
> Signed-off-by: Øyvind Harboe
> ---
> src/helper/command.c | 18 +++---
> src/helper/command.h |6 --
> src/openocd.c|6 +++---
> 3 files changed, 18 insertions(+), 12 deletions(-)
>
> diff --git a/src/helper/command.c b/src/helper/command.c
> index dcad6a1..d657668 100644
> --- a/src/helper/command.c
> +++ b/src/helper/command.c
> @@ -1272,7 +1272,7 @@ static const struct command_registration
> command_builtin_handlers[] = {
> COMMAND_REGISTRATION_DONE
> };
>
> -struct command_context* command_init(const char *startup_tcl)
> +struct command_context* command_init(const char *startup_tcl, Jim_Interp
> *interp)
> {
> struct command_context* context = malloc(sizeof(struct
> command_context));
> const char *HostOs;
> @@ -1284,14 +1284,18 @@ struct command_context* command_init(const char
> *startup_tcl)
> context->output_handler_priv = NULL;
>
> #if !BUILD_ECOSBOARD
It is now safe to kill this #if logic too. It's like a bonus prize. ;)
> - Jim_InitEmbedded();
> - /* Create an interpreter */
> - context->interp = Jim_CreateInterp();
> - /* Add all the Jim core commands */
> - Jim_RegisterCoreCommands(context->interp);
> + /* Create a jim interpreter if we were not handed one */
> + if (interp == NULL)
> + {
> + Jim_InitEmbedded();
> + /* Create an interpreter */
> + interp = Jim_CreateInterp();
> + /* Add all the Jim core commands */
> + Jim_RegisterCoreCommands(interp);
> + }
> #endif
> + context->interp = interp;
>
> - Jim_Interp *interp = context->interp;
> #if defined(_MSC_VER)
> /* WinXX - is generic, the forward
>* looking problem is this:
> diff --git a/src/helper/command.h b/src/helper/command.h
> index 611db87..8d68c18 100644
> --- a/src/helper/command.h
> +++ b/src/helper/command.h
> @@ -323,9 +323,11 @@ void command_set_output_handler(struct command_context*
> context,
> int command_context_mode(struct command_context *context, enum command_mode
> mode);
>
> /**
> - * Creates a new command context using the startup TCL provided.
> + * Creates a new command context using the startup TCL provided and
> + * the existing Jim interpreter, if any. If interp == NULL, then command_init
> + * creates a command interpreter.
> */
> -struct command_context* command_init(const char *startup_tcl);
> +struct command_context* command_init(const char *startup_tcl, Jim_Interp
> *interp);
> /**
> * Creates a copy of an existing command context. This does not create
> * a deep copy of the command list, so modifications in one context will
> diff --git a/src/openocd.c b/src/openocd.c
> index 22d4582..44e0292 100644
> --- a/src/openocd.c
> +++ b/src/openocd.c
> @@ -188,14 +188,14 @@ static const struct command_registration
> openocd_command_handlers[] = {
> struct command_context *global_cmd_ctx;
>
> /* NB! this fn can be invoked outside this file for non PC hosted builds */
> -struct command_context *setup_command_handler(void)
> +struct command_context *setup_command_handler(Jim_Interp *interp)
> {
> log_init();
> LOG_DEBUG("log_init: complete");
>
> struct command_context *cmd_ctx;
>
> - global_cmd_ctx = cmd_ctx = command_init(openocd_startup_tcl);
> + global_cmd_ctx = cmd_ctx = command_init(openocd_startup_tcl, interp);
>
> register_commands(cmd_ctx, NULL, openocd_command_handlers);
> /* register subsystem commands */
> @@ -242,7 +242,7 @@ int openocd_main(int argc, char *argv[])
> /* initialize commandline interface */
> struct command_context *cmd_ctx;
>
> - cmd_ctx = setup_command_handler();
> + cmd_ctx = setup_command_handler(NULL);
>
> #if BUILD_IOUTIL
> if (ioutil_init(cmd_ctx) != ERROR_OK)
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] arm: dcc_downloads and fast_memory_access are now enabled by default
On Tue, 2009-12-01 at 08:52 +0100, Øyvind Harboe wrote: > > How about a warning when it's _not_ explicitly enabled or disabled by > > the user? Specifically, tell the users to try enabling those features > > or to add explicit commands to stop the warnings. Scripts for boards > > where that feature will be safe by default could add the required > > commands, and users for others will be able to read the documentation > > for those commands decide for themselves. > > > > This keeps the default safe while giving users the nudge in the > > direction that you feel they will want to be headed -- eventually. > > I think this is a good way to go forward. > > Here is a though on implementation: each target defines a default > post-reset script, there is some suitable event that exists currently > I'm sure. This post reset script does checks and prints out > hints and warnings. Anything that requires defining a new default gets a frown of disapproval from me. That breaks backwards-compatibility, which is another reason not to change the default without more consideration and wide-spread testing. A warning in the C code should be enough to induce that desired outcome, if you also tell users to report their results in order to help us decide whether to enable it by default. --Z ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
