Please ignore patch it still contains bugs. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7f60c48bd6e0 (LWP 8992)] 0x00007f60c3fc3060 in strlen () from /lib/libc.so.6 (gdb) bt #0 0x00007f60c3fc3060 in strlen () from /lib/libc.so.6 #1 0x00007f60c3f8fe1a in vfprintf () from /lib/libc.so.6 #2 0x00007f60c3fb39ea in vsnprintf () from /lib/libc.so.6 #3 0x00007f60c3f95f73 in snprintf () from /lib/libc.so.6 #4 0x0000000000452547 in find_file (file=0x705890 "openocd.cfg") at configuration.c:77 #5 0x00000000004538d7 in jim_find (interp=0x6ec0d0, argc=<value optimized out>, argv=<value optimized out>) at command.c:544 #6 0x0000000000465792 in Jim_EvalObj (interp=0x6ec0d0, scriptObjPtr=<value optimized out>) at jim.c:8698 #7 0x0000000000465df0 in Jim_CatchCoreCommand (interp=0x6ec0d0, argc=3, argv=0x7fffcc8ed570) at jim.c:11403 #8 0x0000000000465792 in Jim_EvalObj (interp=0x6ec0d0, scriptObjPtr=<value optimized out>) at jim.c:8698 #9 0x0000000000469af9 in Jim_EvalExpression (interp=0x6ec0d0, exprObjPtr=0x706330, exprResultPtrPtr=0x7fffcc8ed728) at jim.c:6926 #10 0x000000000046a623 in Jim_GetBoolFromExpr (interp=0x21, exprObjPtr=0x4a98bd, boolPtr=0x7fffcc8ed774) at jim.c:7209 #11 0x000000000046a72e in Jim_IfCoreCommand (interp=0x6ec0d0, argc=3, argv=0x7fffcc8ed800) at jim.c:10287 #12 0x0000000000465792 in Jim_EvalObj (interp=0x6ec0d0, scriptObjPtr=<value optimized out>) at jim.c:8698 #13 0x0000000000467398 in JimCallProcedure (interp=0x6ec0d0, cmd=0x6fe8c0, argc=2, argv=0x7fffcc8ed960) at jim.c:8847 #14 0x0000000000465993 in Jim_EvalObj (interp=0x6ec0d0, scriptObjPtr=<value optimized out>) at jim.c:8704 #15 0x0000000000465557 in Jim_EvalObj (interp=0x6ec0d0, scriptObjPtr=<value optimized out>) at jim.c:8644 #16 0x0000000000467398 in JimCallProcedure (interp=0x6ec0d0, cmd=0x6feb70, argc=2, argv=0x7fffcc8edbb0) at jim.c:8847 #17 0x0000000000465993 in Jim_EvalObj (interp=0x6ec0d0, scriptObjPtr=<value optimized out>) at jim.c:8704 #18 0x00000000004670b2 in Jim_Eval_Named (interp=0x6ec0d0, script=<value optimized out>, filename=0x4a9ada "command.c", lineno=456) at jim.c:8891 #19 0x0000000000453bee in command_run_line (context=<value optimized out>, line=0x7054e0 "script openocd.cfg") at command.c:456 #20 0x0000000000452705 in parse_config_file (cmd_ctx=0x6ec0a0) at configuration.c:121 #21 0x0000000000402808 in openocd_main (argc=1, argv=0x7fffcc8edee8) at openocd.c:266 #22 0x00007f60c3f661c4 in __libc_start_main () from /lib/libc.so.6 #23 0x0000000000402529 in _start ()
On Mon, Jan 19, 2009 at 2:15 PM, Kees Jongenburger <[email protected]> wrote: > The following patch reverses the search order in witch it script paths > are searched > to allow users to override default configurations. > > The currrent openocd indeed searches the paths in the "wrong" order. > The patch attached fixes this problem but in a ugly way. > > The current configuration driver keeps 2 static variables: > script_search_dirs and num_script_dirs. > upon adding a new directory to the path a reallocation is performed > (to grow to be 1 element larger). > The new path is added at index-1 and the array is ended by a NULL > value. When needed > later in the code script_search_dirs it used as iterator and the NULL > value is used as condition to stop. > Because the patch reverses that order the NULL value can no longer be > used as terminator and the num_script_dirs > value it used to initialize the iterator. A proper fix need to do one > of the following > -stop using the NULL as terminator and use a combo of > script_search_dirs and num_script_dirs > or > -put the added paths to the start of the array. > > Greetings > > On Sat, Dec 13, 2008 at 12:41 PM, Øyvind Harboe <[email protected]> > wrote: >> On Sat, Dec 13, 2008 at 11:31 AM, Kees Jongenburger >> <[email protected]> wrote: >>> Hello >>> >>> OpenOCD offers the -s option to specify additional search paths for >>> configuration files. Currently the search order appears >>> to be first the global configuration and then only the local. For my >>> purposes it would be handy if the order would be reversed >>> so it is possible to overide some configuration files. what do you think? >> >> Sounds like you've found a bug. It should be possible to override >> the default files, that's the whole point. >> >> -- >> Øyvind Harboe >> http://www.zylin.com/zy1000.html >> ARM7 ARM9 XScale Cortex >> JTAG debugger and flash programmer >> > _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
