Re: [Openocd-development] New patch to review for openocd: 7067428 Revert Evaluate 'script' in the global scope
On Fri, Oct 21, 2011 at 1:36 PM, Freddie Chopin freddie_cho...@op.pl wrote: On 2011-10-21 19:09, Øyvind Harboe (Code Review) wrote: Please look up the discussion of why this code was modified to use uplevel and amend the commit with an explanation of why we should use the proposed behaviour instead. I cannot comment on Gerrit... The discussion - https://lists.berlios.de/pipermail/openocd-development/2011-August/020462.html - not easy to find (links to list are links to NEW and EMPTY sourceforge forum) so I had to google that up. There is absolutely no discussion or reasoning there, this change was introduced just because and based on why not?. Or maybe there's another discussion I cannot find. This is the first email of the discussion: https://lists.berlios.de/pipermail/openocd-development/2011-July/020359.html Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Jim Tcl problems
On Fri, Sep 2, 2011 at 10:58 AM, Øyvind Harboe oyvind.har...@zylin.com wrote: Jim_Eval_Named is a macro. I don't know why it's not substituted when preprocessing. Maybe make clean will help you. Maybe you need to remove the ccache cache and try again. I've tried what I can think of: rm -rf ~/.ccache git clean -f -x -d ./bootstrap ./configure --enable-dummy --enable-maintainer-mode I have no jim-tclcompat.c nor jim-glob.c in my jimtcl/ . Maybe your jimtcl is not new enough? Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Remove qP from rtos code?
Ping. Jie On Sat, Aug 27, 2011 at 11:01 AM, Jie Zhang jzhang...@gmail.com wrote: Hi Evan, If qThreadExtraInfo is not implemented, qP will be used. But since qThreadExtraInfo has now been implemented, qP should not be needed any more. GDB added qThreadExtraInfo more than 10 years ago. All GDB releases since 5.0 will not send out qP packet if the stub supports qThreadExtraInfo. So I think it's safe for OpenOCD to remove qP support and only keep qThreadExtraInfo. This will make code clean and reduce maintenance effort. Regards, Jie On Thu, Aug 25, 2011 at 8:50 PM, Evan Hunter e...@ozhiker.com wrote: Backward compatibility is the reason - When I was testing with GDB+eclipse I found that OpenOCD received qP packets sometimes, and I think I implemented it first, before reading that same quotation you mentioned. Then when I implemented qThreadExtraInfo, I figured it was nicer to keep qP compatibility too. Regards, Evan Quoting Jie Zhang jzhang...@gmail.com: Hi Evan, GDB manual says about qP: Don't use this packet; use the `qThreadExtraInfo' query instead (see below). Since qThreadExtraInfo is already supported in rtos.c, why qP is still needed? Regards, Jie ___ 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
Re: [Openocd-development] Coding style plan
On Tue, Aug 30, 2011 at 5:26 AM, Øyvind Harboe oyvind.har...@zylin.com wrote: Goal: switch OpenOCD to use the Kernel coding style Plan: a) get all outstanding patches merged b) do wholesale automated(hopefully) code style fix d) patch w/documentation and scripts to enforce the new coding style. Resources: Does anyone want to do this? I think first is to set a date for the conversion so everyone can prepare for this conversion. Item a is everyone's job. If he/she does not want to reformat all his/her patches after conversion, he/she should push out the patches to be merged before the conversion date. I can do Item b and c if we set the conversion date to the end of this year. I think I should have some spare time at that time. Regards, Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Coding style
On Mon, Aug 29, 2011 at 7:35 AM, Øyvind Harboe oyvind.har...@zylin.com wrote: I don't mind picking the kernel style, if nothing else because we then can get scripts to check for the style. It seems people like Linux kernel coding style. It's widely used and well documented. So I think it will be good. How about make a plan to do the coding style switch? We cannot do now immediately since it will break all patches in people's local trees. We need to set a roughly date so people can prepare for it. The end of this year or the beginning of the next year will be a good point time for me. I think I will have already pushed out all my patches at that time. And at that time, people will be in Christmas and New year holidays. There might be less development activities. So the impact will be likely less than other times of a year. What's your thought? Regards, Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Remove qP from rtos code?
Hi Evan, If qThreadExtraInfo is not implemented, qP will be used. But since qThreadExtraInfo has now been implemented, qP should not be needed any more. GDB added qThreadExtraInfo more than 10 years ago. All GDB releases since 5.0 will not send out qP packet if the stub supports qThreadExtraInfo. So I think it's safe for OpenOCD to remove qP support and only keep qThreadExtraInfo. This will make code clean and reduce maintenance effort. Regards, Jie On Thu, Aug 25, 2011 at 8:50 PM, Evan Hunter e...@ozhiker.com wrote: Backward compatibility is the reason - When I was testing with GDB+eclipse I found that OpenOCD received qP packets sometimes, and I think I implemented it first, before reading that same quotation you mentioned. Then when I implemented qThreadExtraInfo, I figured it was nicer to keep qP compatibility too. Regards, Evan Quoting Jie Zhang jzhang...@gmail.com: Hi Evan, GDB manual says about qP: Don't use this packet; use the `qThreadExtraInfo' query instead (see below). Since qThreadExtraInfo is already supported in rtos.c, why qP is still needed? Regards, Jie ___ 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
Re: [Openocd-development] Coding style
2011/8/26 Michel Catudal michelcatu...@gmail.com:
Le 25/08/2011 15:18, Jie Zhang a écrit :
Hi,
There are a lot of coding style mismatch in the current OpenOCD code.
I'd like suggest setting a rule that asks fixing all coding style
issues before a patch is merged.
And there are still something missing on
http://openocd.berlios.de/doc/doxygen/html/stylec.html , like
* how to deal with long list of arguments, which cannot fix in one line?
* how to place { }? I saw
if (...) {
} else {
}
if (...)
{
}
else
{
}
* should there be a white space after ( and before )? I saw code both.
If you change to much the diff files can get big.
I don't propose to fix all coding style issue right now. I propose to
do coding style check when reviewing patch from now. At some
appropriate point in future, we can fix coding style issues at once.
I do agree with you that your suggestion is more appropriate but you will
find people who prefer the other approach.
Personnally I just use the beautify in slickedit to fix that.
I'm not used to the current coding style of OpenOCD. I'm more used to
GNU coding style. But I can use the established coding style in
OpenOCD without a problem. A consistent coding style is important for
the readability and maintenance of software.
Regards,
Jie
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Errors encountered programming an FPGA using 13MB SVF file
On Fri, Aug 26, 2011 at 2:18 PM, Andreas Fritiofson andreas.fritiof...@gmail.com wrote: The ftdi driver is a real mess. I've been trying to clean in up the past days but I'm beginning to think a complete rewrite would be better. Maybe making OpenOCD use UrJTAG as a library is more worth the effort than just rewriting ftdi driver. Regards, Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Coding style
On Sat, Aug 27, 2011 at 1:40 PM, Øyvind Harboe oyvind.har...@zylin.com wrote: As a maintainer I'm interested in this subject from the point of view of how it can be used to *save* time of the maintainers. E.g. if we had a script committed that checked that a patch sequence was acceptable, then that report could be amended to the patch sequence. Thus maintainers would not have to check the patches and give feedback, this would happen before the patches were posted. My experience is such a script is better than nothing, but it cannot check everything in coding style and developer ofter forget to check the patch with it. I can volunteer to review patch for coding style. But before that we need to set the rule about those issues I raised, since current documentation does not say anything about them. Regards, Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Coding style
On Sat, Aug 27, 2011 at 5:49 PM, j. m. norris u17...@att.net wrote: There is a tool that has been around for a long time that can address this issue. It's called indent. It has numerous options that can generate just about any type of coding style. I don't know if indent can check in-line coding style. Regards, Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Next release
On Thu, Aug 25, 2011 at 2:12 AM, Øyvind Harboe oyvind.har...@zylin.com wrote: Hi, is anyone out there working on something that they would like to see in the next release? I know Tomek has been working on SWD. Here we need resources to review, give feedback and look into what it would take to bring this to a state where the community is happy to take responsibility for it. Other things? I'm working on adding Blackfin support. But I'm not sure if it will be ready before the next release. Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Remove qP from rtos code?
Hi Evan, GDB manual says about qP: Don't use this packet; use the `qThreadExtraInfo' query instead (see below). Since qThreadExtraInfo is already supported in rtos.c, why qP is still needed? Regards, Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] threadid_t
Hi Evan, I'm wondering why threadid_t is int64_t. Is there any known RTOS needs int64_t for its thread id? Can it be long? Regards, Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Coding style
Hi,
There are a lot of coding style mismatch in the current OpenOCD code.
I'd like suggest setting a rule that asks fixing all coding style
issues before a patch is merged.
And there are still something missing on
http://openocd.berlios.de/doc/doxygen/html/stylec.html , like
* how to deal with long list of arguments, which cannot fix in one line?
* how to place { }? I saw
if (...) {
} else {
}
if (...)
{
}
else
{
}
* should there be a white space after ( and before )? I saw code both.
Regards,
Jie
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Remove target argument from gdb packet handling functions
On Wed, Aug 24, 2011 at 12:53 AM, Øyvind Harboe oyvind.har...@zylin.com wrote:
I'm OK with this.
Perhaps make a tiny static fn for:
+ struct gdb_service *gdb_service = connection-service-priv;
+ struct target *target = gdb_service-target;
I think this is a good idea. Ideally the function should be put in
gdb_server.c. But currently it needs to be in gdb_server.h. The new
patch is attached.
Regards,
Jie
From 8b73e67c7fcdfd0228d5cc2326bff47635daf84c Mon Sep 17 00:00:00 2001
From: Jie Zhang jie.zh...@analog.com
Date: Wed, 24 Aug 2011 11:23:04 -0400
Subject: [PATCH] remove target argument from gdb packet handling functions
---
src/rtos/rtos.c |8 +++-
src/rtos/rtos.h |4 +-
src/server/gdb_server.c | 106 --
src/server/gdb_server.h |6 +++
src/target/smp.c|6 ++-
src/target/smp.h|4 +-
6 files changed, 66 insertions(+), 68 deletions(-)
diff --git a/src/rtos/rtos.c b/src/rtos/rtos.c
index 263795c..74e8724 100644
--- a/src/rtos/rtos.c
+++ b/src/rtos/rtos.c
@@ -128,8 +128,10 @@ int rtos_create(Jim_GetOptInfo *goi, struct target * target)
-int gdb_thread_packet(struct connection *connection, struct target *target, char *packet, int packet_size)
+int gdb_thread_packet(struct connection *connection, char *packet, int packet_size)
{
+ struct target *target = get_target_from_connection(connection);
+
if (strstr(packet, qP))
{
#define TAG_THREADID 1 /* Echo the thread identifier */
@@ -501,8 +503,10 @@ int gdb_thread_packet(struct connection *connection, struct target *target, char
return GDB_THREAD_PACKET_NOT_CONSUMED;
}
-int rtos_get_gdb_reg_list(struct connection *connection, struct target *target, struct reg **reg_list[], int *reg_list_size)
+int rtos_get_gdb_reg_list(struct connection *connection, struct reg **reg_list[], int *reg_list_size)
{
+ struct target *target = get_target_from_connection(connection);
+
if ( ( target-rtos != NULL )
( current_threadid != -1 )
( current_threadid != 0 )
diff --git a/src/rtos/rtos.h b/src/rtos/rtos.h
index a6378c6..1a73bd7 100644
--- a/src/rtos/rtos.h
+++ b/src/rtos/rtos.h
@@ -99,8 +99,8 @@ struct rtos_register_stacking
int rtos_create(Jim_GetOptInfo *goi, struct target * target);
int rtos_generic_stack_read( struct target * target, const struct rtos_register_stacking* stacking, int64_t stack_ptr, char ** hex_reg_list );
int rtos_try_next( struct target * target );
-int gdb_thread_packet(struct connection *connection, struct target *target, char *packet, int packet_size);
-int rtos_get_gdb_reg_list(struct connection *connection, struct target *target, struct reg **reg_list[], int *reg_list_size);
+int gdb_thread_packet(struct connection *connection, char *packet, int packet_size);
+int rtos_get_gdb_reg_list(struct connection *connection, struct reg **reg_list[], int *reg_list_size);
int rtos_update_threads( struct target *target );
#endif // RTOS_H
diff --git a/src/server/gdb_server.c b/src/server/gdb_server.c
index b6921ff..5eb6cac 100644
--- a/src/server/gdb_server.c
+++ b/src/server/gdb_server.c
@@ -944,8 +944,9 @@ static void gdb_send_error(struct connection *connection, uint8_t the_error)
}
static int gdb_last_signal_packet(struct connection *connection,
- struct target *target, char* packet, int packet_size)
+ char* packet, int packet_size)
{
+ struct target *target = get_target_from_connection(connection);
char sig_reply[4];
int signal_var;
@@ -1029,8 +1030,9 @@ static void gdb_target_to_reg(struct target *target,
}
static int gdb_get_registers_packet(struct connection *connection,
- struct target *target, char* packet, int packet_size)
+ char* packet, int packet_size)
{
+ struct target *target = get_target_from_connection(connection);
struct reg **reg_list;
int reg_list_size;
int retval;
@@ -1044,7 +1046,7 @@ static int gdb_get_registers_packet(struct connection *connection,
#endif
if ( ( target-rtos != NULL )
- ( ERROR_FAIL != rtos_get_gdb_reg_list( connection, target, reg_list, reg_list_size) ) )
+ ( ERROR_FAIL != rtos_get_gdb_reg_list( connection, reg_list, reg_list_size) ) )
{
return ERROR_OK;
}
@@ -1088,8 +1090,9 @@ static int gdb_get_registers_packet(struct connection *connection,
}
static int gdb_set_registers_packet(struct connection *connection,
- struct target *target, char *packet, int packet_size)
+ char *packet, int packet_size)
{
+ struct target *target = get_target_from_connection(connection);
int i;
struct reg **reg_list;
int reg_list_size;
@@ -1147,8 +1150,9 @@ static int gdb_set_registers_packet(struct connection *connection,
}
static int gdb_get_register_packet(struct connection *connection,
- struct target *target, char *packet, int packet_size)
+ char *packet, int packet_size)
{
+ struct target *target = get_target_from_connection(connection);
char *reg_packet;
int reg_num = strtoul(packet + 1, NULL, 16);
struct reg
[Openocd-development] [PATCH] Remove target argument from gdb packet handling functions
Hi,
In OpenOCD, all gdb packet handling functions look like:
gdb_xxx_packet(connection, target, packet, packet_size);
I'm wondering if we can remove target from the argument list and just
calculate it from connection in each handling function. The patch is
attached.
I like this patch since I think the code is clearer with it and the
big switch in gdb_input_inner will be more generic. The cons is the
code size will be a little larger, on x86_64, it's from 1295167B to
1295343B. But I think it's not a real issue. What's your opinion?
Regards,
Jie
From 9d7c77df0ba54d659bc995b997d74411f433eb3e Mon Sep 17 00:00:00 2001
From: Jie Zhang jie.zh...@analog.com
Date: Tue, 23 Aug 2011 17:29:29 -0400
Subject: [PATCH] remove target argument from gdb packet handling functions
---
src/rtos/rtos.c | 10 +++-
src/rtos/rtos.h |4 +-
src/server/gdb_server.c | 118 +++
src/target/smp.c|8 ++-
src/target/smp.h|4 +-
5 files changed, 76 insertions(+), 68 deletions(-)
diff --git a/src/rtos/rtos.c b/src/rtos/rtos.c
index 263795c..12a944f 100644
--- a/src/rtos/rtos.c
+++ b/src/rtos/rtos.c
@@ -128,8 +128,11 @@ int rtos_create(Jim_GetOptInfo *goi, struct target * target)
-int gdb_thread_packet(struct connection *connection, struct target *target, char *packet, int packet_size)
+int gdb_thread_packet(struct connection *connection, char *packet, int packet_size)
{
+ struct gdb_service *gdb_service = connection-service-priv;
+ struct target *target = gdb_service-target;
+
if (strstr(packet, qP))
{
#define TAG_THREADID 1 /* Echo the thread identifier */
@@ -501,8 +504,11 @@ int gdb_thread_packet(struct connection *connection, struct target *target, char
return GDB_THREAD_PACKET_NOT_CONSUMED;
}
-int rtos_get_gdb_reg_list(struct connection *connection, struct target *target, struct reg **reg_list[], int *reg_list_size)
+int rtos_get_gdb_reg_list(struct connection *connection, struct reg **reg_list[], int *reg_list_size)
{
+ struct gdb_service *gdb_service = connection-service-priv;
+ struct target *target = gdb_service-target;
+
if ( ( target-rtos != NULL )
( current_threadid != -1 )
( current_threadid != 0 )
diff --git a/src/rtos/rtos.h b/src/rtos/rtos.h
index a6378c6..1a73bd7 100644
--- a/src/rtos/rtos.h
+++ b/src/rtos/rtos.h
@@ -99,8 +99,8 @@ struct rtos_register_stacking
int rtos_create(Jim_GetOptInfo *goi, struct target * target);
int rtos_generic_stack_read( struct target * target, const struct rtos_register_stacking* stacking, int64_t stack_ptr, char ** hex_reg_list );
int rtos_try_next( struct target * target );
-int gdb_thread_packet(struct connection *connection, struct target *target, char *packet, int packet_size);
-int rtos_get_gdb_reg_list(struct connection *connection, struct target *target, struct reg **reg_list[], int *reg_list_size);
+int gdb_thread_packet(struct connection *connection, char *packet, int packet_size);
+int rtos_get_gdb_reg_list(struct connection *connection, struct reg **reg_list[], int *reg_list_size);
int rtos_update_threads( struct target *target );
#endif // RTOS_H
diff --git a/src/server/gdb_server.c b/src/server/gdb_server.c
index b6921ff..3509b93 100644
--- a/src/server/gdb_server.c
+++ b/src/server/gdb_server.c
@@ -944,8 +944,10 @@ static void gdb_send_error(struct connection *connection, uint8_t the_error)
}
static int gdb_last_signal_packet(struct connection *connection,
- struct target *target, char* packet, int packet_size)
+ char* packet, int packet_size)
{
+ struct gdb_service *gdb_service = connection-service-priv;
+ struct target *target = gdb_service-target;
char sig_reply[4];
int signal_var;
@@ -1029,8 +1031,10 @@ static void gdb_target_to_reg(struct target *target,
}
static int gdb_get_registers_packet(struct connection *connection,
- struct target *target, char* packet, int packet_size)
+ char* packet, int packet_size)
{
+ struct gdb_service *gdb_service = connection-service-priv;
+ struct target *target = gdb_service-target;
struct reg **reg_list;
int reg_list_size;
int retval;
@@ -1044,7 +1048,7 @@ static int gdb_get_registers_packet(struct connection *connection,
#endif
if ( ( target-rtos != NULL )
- ( ERROR_FAIL != rtos_get_gdb_reg_list( connection, target, reg_list, reg_list_size) ) )
+ ( ERROR_FAIL != rtos_get_gdb_reg_list( connection, reg_list, reg_list_size) ) )
{
return ERROR_OK;
}
@@ -1088,8 +1092,10 @@ static int gdb_get_registers_packet(struct connection *connection,
}
static int gdb_set_registers_packet(struct connection *connection,
- struct target *target, char *packet, int packet_size)
+ char *packet, int packet_size)
{
+ struct gdb_service *gdb_service = connection-service-priv;
+ struct target *target = gdb_service-target;
int i;
struct reg **reg_list;
int reg_list_size;
@@ -1147,8 +1153,10 @@ static int gdb_set_registers_packet(struct connection *connection,
}
static int
[Openocd-development] target number
Hi, I saw this int target_number; /* DO NOT USE! field to be removed in 2010 */ in the definition of struct target. I don't know the reason to remove it. Maybe it's just useless? I I need a way to identify each target. I think target_number is good for this purpose. Regards, Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] target number
On Thu, Aug 18, 2011 at 4:18 PM, Øyvind Harboe oyvind.har...@zylin.com wrote: target_number should be retired. Patches gladly accepted. The only slight hickup is to get rid of current_target, near as I can tell. Targets are identified only by strings from tcl. But if we treat each target as a thread, we will need something as thread id. target_number is good for this purpose. Does keeping target_number hurt? Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] Remove white space before TAB
Hi, This is a trivial patch. Please help me merge it. Thank you. Regards, Jie From 852d698ba7237908c44a335a5efbe08e1dfdef6d Mon Sep 17 00:00:00 2001 From: Jie Zhang jie.zh...@analog.com Date: Wed, 17 Aug 2011 11:21:22 -0400 Subject: [PATCH] remove white space before TAB --- src/target/Makefile.am |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/target/Makefile.am b/src/target/Makefile.am index 27ad054..9f7e5e9 100644 --- a/src/target/Makefile.am +++ b/src/target/Makefile.am @@ -84,7 +84,7 @@ ARM_DEBUG_SRC = \ arm_simulator.c \ arm_semihosting.c \ arm_adi_v5.c \ - adi_v5_jtag.c \ + adi_v5_jtag.c \ adi_v5_swd.c \ embeddedice.c \ trace.c \ -- 1.7.5.4 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] A fix (was Re: Git revision string missing from banner)
On Mon, Aug 15, 2011 at 6:21 PM, Andreas Fritiofson andreas.fritiof...@gmail.com wrote: +if test -f $srcdir/guess-rev.sh ; then Great, but you should probably check if it's executable instead of just a regular file. I considered if we should check this. But I finally decided it would be better to just check if it's a regular file. my reason is: We decide if we are building for release or not by the existence of guess-rev.sh, not by the existence of an executable guess-rev.sh. So 1. guess-rev.sh exists and is executable: checking regular file is same as checking executable file. 2. guess-rev.sh does not exist: checking regular file is same as checking executable file. 3. guess-rev.sh exists but is not executable: there must be something wrong. If we check regular file, user will be given an error when guess-rev.sh is going to be executed on compiler time. If we check executable file, building for release is assumed and user will notice it only in run time. Regards, Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Build error with mingw32
On Sun, Aug 14, 2011 at 6:39 AM, Steve Bennett ste...@workware.net.au wrote: I pushed a change to jimtcl git which will use Sleep() if usleep() is unavailable on mingw32. Now building OpenOCD with latest jimtcl with mingw32 works for me. Thank you! Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] A fix (was Re: Git revision string missing from banner)
On Mon, Aug 15, 2011 at 9:35 AM, Spencer Oliver s...@spen-soft.co.uk wrote: On 15 August 2011 14:22, Eric Wetzel thewet...@gmail.com wrote: if test $cross_compiling = no; then # guess-rev.sh only exists in the repository, not in the released archives AC_CHECK_FILE($srcdir/guess-rev.sh, has_guess_rev=yes, has_guess_rev=no) We automatically assume that if we are cross-compiling that we are building a release. This section was last modified in July 2009, back in the SVN days, but the commit is here: http://repo.or.cz/w/openocd.git/commitdiff/00fad24996d6642c6a820cc951c197dddef5734a Actually it was introduced earlier http://repo.or.cz/w/openocd.git/commit/64e53c4fd8a5da944de57716b137a7dff5e67b63 This patch should fix it. Please review and merge if it's OK. Thank you! Jie From 281bc87c50fd108d43283b07ac1d3900767aba00 Mon Sep 17 00:00:00 2001 From: Jie Zhang jie.zh...@analog.com Date: Mon, 15 Aug 2011 10:52:11 -0400 Subject: [PATCH] show git commit number even when cross-compiling AC_CHECK_FILE will die when cross-compiling. So don't use it to test the existence of guess-rev.sh. --- configure.in | 16 +--- 1 files changed, 5 insertions(+), 11 deletions(-) diff --git a/configure.in b/configure.in index dfa1e8f..3c0056c 100644 --- a/configure.in +++ b/configure.in @@ -143,20 +143,14 @@ is_mingw=no is_win32=no is_darwin=no -if test $cross_compiling = no; then - # guess-rev.sh only exists in the repository, not in the released archives - AC_CHECK_FILE($srcdir/guess-rev.sh, has_guess_rev=yes, has_guess_rev=no) - - AC_MSG_CHECKING([whether to build a release]) - if test $has_guess_rev = no; then -build_release=yes - else -build_release=no - fi - AC_MSG_RESULT($build_release) +# guess-rev.sh only exists in the repository, not in the released archives +AC_MSG_CHECKING([whether to build a release]) +if test -f $srcdir/guess-rev.sh ; then + build_release=no else build_release=yes fi +AC_MSG_RESULT($build_release) # We are not *ALWAYS* being installed in the standard place. # We may be installed in a tool-build specific location. -- 1.7.5.4 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] Rename configure.in as configure.ac
configure.ac is now preferred. So rename configure.in to make OpenOCD project look modern. Please review and merge if it's OK. Thank you! Jie From 97ef0e24eeb752f88e521376f41b8e1321db52a0 Mon Sep 17 00:00:00 2001 From: Jie Zhang jie.zh...@analog.com Date: Mon, 15 Aug 2011 15:35:30 -0400 Subject: [PATCH] rename configure.in as configure.ac --- configure.in = configure.ac |0 1 files changed, 0 insertions(+), 0 deletions(-) rename configure.in = configure.ac (100%) diff --git a/configure.in b/configure.ac similarity index 100% rename from configure.in rename to configure.ac -- 1.7.5.4 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Add a configure option to enable/disable rtos support
On Mon, Aug 15, 2011 at 4:42 PM, Øyvind Harboe oyvind.har...@zylin.com wrote: On Mon, Aug 15, 2011 at 9:16 PM, Jie Zhang jzhang...@gmail.com wrote: On Mon, Aug 15, 2011 at 3:10 PM, Øyvind Harboe oyvind.har...@zylin.com wrote: Isn't there a way to make both live side-by-side? rtos w/BF561 is surely possible? Since both will use threads, they cannot be supported in the same time. To debug a rtos on BF561, users have to choose using thread in GDB as a core or as a thread in rtos. eCos is an RTOS that supports multiple CPUs. I think it is reasonable to enable/disable threads as a way to choose between CPUs and a way to choose between RTOS threads, but I think that choice should happen during configuration runtime in the scripts and not at build time. Thanks for your comment. Runtime is surely better than configure time. But it will also be more difficult, thus need more time, to implement. I will try and see if I can do it in my schedule. Regards, Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Build error with mingw32
The current HEAD cannot build with mingw32
libtool: link: i586-mingw32msvc-gcc -std=gnu99 -g -O2
-I/home/jie/installs/openocd/include -D__USE_MINGW_ANSI_STDIO -Wall
-Wstrict-prototypes -Wformat-security -Wshadow -Wextra
-Wno-unused-parameter -Wbad-function-cast -Wcast-align
-Wredundant-decls -Werror -o openocd.exe main.o
-L/home/jie/installs/openocd/lib ./.libs/libopenocd.a -lws2_32
../jimtcl/libjim.a
./.libs/libopenocd.a(libhelper_la-command.o): In function `process_jim_events':
/home/jie/sources/openocd/src/helper/command.c:1398: undefined
reference to `_Jim_ProcessEvents'
collect2: ld returned 1 exit status
make[4]: *** [openocd.exe] Error 1
make[4]: Leaving directory `/home/jie/sources/openocd/src'
Jim_ProcessEvents is defined in jimtcl/jim-eventloop.c.
set needs(eventloop) {expr {[have-feature select] || [have-feature usleep]}}
but
Checking for select...not found
Checking for usleep...not found
It build OK with mingw-w64 since
Checking for usleep...ok
Jie
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Build error with mingw32
On Fri, Aug 12, 2011 at 5:19 PM, Steve Bennett ste...@workware.net.au wrote:
On 13/08/2011, at 6:41 AM, Jie Zhang wrote:
The current HEAD cannot build with mingw32
libtool: link: i586-mingw32msvc-gcc -std=gnu99 -g -O2
-I/home/jie/installs/openocd/include -D__USE_MINGW_ANSI_STDIO -Wall
-Wstrict-prototypes -Wformat-security -Wshadow -Wextra
-Wno-unused-parameter -Wbad-function-cast -Wcast-align
-Wredundant-decls -Werror -o openocd.exe main.o
-L/home/jie/installs/openocd/lib ./.libs/libopenocd.a -lws2_32
../jimtcl/libjim.a
./.libs/libopenocd.a(libhelper_la-command.o): In function
`process_jim_events':
/home/jie/sources/openocd/src/helper/command.c:1398: undefined
reference to `_Jim_ProcessEvents'
collect2: ld returned 1 exit status
make[4]: *** [openocd.exe] Error 1
make[4]: Leaving directory `/home/jie/sources/openocd/src'
Jim_ProcessEvents is defined in jimtcl/jim-eventloop.c.
set needs(eventloop) {expr {[have-feature select] || [have-feature usleep]}}
but
Checking for select...not found
Checking for usleep...not found
Can you send me jimtcl/config.log
Attached.
This is on Linux, right?
Yes. Debian testing AMD64.
Jie
Invoked as: .././jimtcl/configure --with-jim-ext=nvp --disable-lineedit --disable-install-jim --disable-option-checking --prefix=/home/jie/installs/openocd --enable-maintainer-mode --host=i586-mingw32msvc host_alias=i586-mingw32msvc --cache-file=/dev/null --srcdir=.
Failed: ccache i586-mingw32msvc-cc -g -O2 -c conftest__.c -o conftest__.o
conftest__.c:1:24: error: sys/socket.h: No such file or directory
child process exited abnormally
The failed code was:
#include sys/socket.h
int main(void) {
return 0;
}
Failed: ccache i586-mingw32msvc-cc -g -O2 -c conftest__.c -o conftest__.o
conftest__.c:1:24: error: netinet/in.h: No such file or directory
child process exited abnormally
The failed code was:
#include netinet/in.h
int main(void) {
return 0;
}
Failed: ccache i586-mingw32msvc-cc -g -O2 -c conftest__.c -o conftest__.o
conftest__.c:1:23: error: arpa/inet.h: No such file or directory
child process exited abnormally
The failed code was:
#include arpa/inet.h
int main(void) {
return 0;
}
Failed: ccache i586-mingw32msvc-cc -g -O2 -c conftest__.c -o conftest__.o
conftest__.c:1:19: error: netdb.h: No such file or directory
child process exited abnormally
The failed code was:
#include netdb.h
int main(void) {
return 0;
}
Failed: ccache i586-mingw32msvc-cc -g -O2 -c conftest__.c -o conftest__.o
conftest__.c:1:20: error: sys/un.h: No such file or directory
child process exited abnormally
The failed code was:
#include sys/un.h
int main(void) {
return 0;
}
Failed: ccache i586-mingw32msvc-cc -g -O2 -c conftest__.c -o conftest__.o
conftest__.c:1:19: error: dlfcn.h: No such file or directory
child process exited abnormally
The failed code was:
#include dlfcn.h
int main(void) {
return 0;
}
Failed: ccache i586-mingw32msvc-cc -g -O2 -c conftest__.c -o conftest__.o
conftest__.c:1:25: error: crt_externs.h: No such file or directory
child process exited abnormally
The failed code was:
#include crt_externs.h
int main(void) {
return 0;
}
Failed: ccache i586-mingw32msvc-cc -g -O2 conftest__.c -o conftest__.o
/tmp/cca3kbgO.o: In function `main':
/home/jie/sources/openocd/jimtcl/conftest__.c:3: undefined reference to `_ualarm'
collect2: ld returned 1 exit status
child process exited abnormally
The failed code was:
extern void ualarm(void);
int main(void) {
ualarm();
return 0;
}
Failed: ccache i586-mingw32msvc-cc -g -O2 conftest__.c -o conftest__.o
/tmp/ccOSxm7T.o: In function `main':
/home/jie/sources/openocd/jimtcl/conftest__.c:3: undefined reference to `_sysinfo'
collect2: ld returned 1 exit status
child process exited abnormally
The failed code was:
extern void sysinfo(void);
int main(void) {
sysinfo();
return 0;
}
Failed: ccache i586-mingw32msvc-cc -g -O2 conftest__.c -o conftest__.o
/tmp/ccmzHPx4.o: In function `main':
/home/jie/sources/openocd/jimtcl/conftest__.c:3: undefined reference to `_lstat'
collect2: ld returned 1 exit status
child process exited abnormally
The failed code was:
extern void lstat(void);
int main(void) {
lstat();
return 0;
}
Failed: ccache i586-mingw32msvc-cc -g -O2 conftest__.c -o conftest__.o
conftest__.c:1: warning: conflicting types for built-in function 'fork'
/tmp/cckd557b.o: In function `main':
/home/jie/sources/openocd/jimtcl/conftest__.c:3: undefined reference to `_fork'
collect2: ld returned 1 exit status
child process exited abnormally
The failed code was:
extern void fork(void);
int main(void) {
fork();
return 0;
}
Failed: ccache i586-mingw32msvc-cc -g -O2 conftest__.c -o conftest__.o
/tmp/ccQGyG3k.o: In function `main':
/home/jie/sources/openocd/jimtcl
Re: [Openocd-development] Build error with mingw32
On Fri, Aug 12, 2011 at 9:27 PM, Xiaofan Chen xiaof...@gmail.com wrote: On Sat, Aug 13, 2011 at 9:00 AM, Jie Zhang jzhang...@gmail.com wrote: Another option is to drop mingw32 and require mingw-w64. Do not do that. usleep is fine with later version of MinGW.org Win32API package. This is probably because you have a very old version of MinGW and MinGW Win32-API. Seems to be a problem with Debian. http://sourceforge.net/projects/mingw/files/MinGW/BaseSystem/RuntimeLibrary/Win32-API/ Debian seems to ship a 3-year old MinGW Win32-API. http://packages.debian.org/search?searchon=sourcenameskeywords=mingw32 Hmm, good point. I have written an email to the mingw32-runtime package maintainer of Debian to see if he has any plan to update it to the latest version. Regards, Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] rebase vs. merge
On Wed, Aug 10, 2011 at 2:53 PM, Øyvind Harboe oyvind.har...@zylin.com wrote: Then when I pull to push to the repository, then without rebasing on my end I will not get a linear history. this is the key point linear history make is lose the information on which commit the code was bsed and tested before the merge. So for bisect point of view it's not good An objection I have to patches is that they do not contain any information about which commit they were tested against. git pull w/merge preserves that information. It is possible to make a linear history later on if required. All patches should be tested on the latest upstream before merge, shouldn't it? If we follow this rule, we can keep the linear history and know the patch has been tested just on the HEAD before it's committed. The commit they were tested against when they were being developed is not so important then. The developer, who develops the patches, might still want to remember that commit to debug bugs in his patches found later, but others can always make sure those patches have been tested on the HEAD when they are committed. For example, one developer has a branch which was branched off from upstream one month ago and asks for merging the branch to the upstream. But during the past month, something might have changed in upstream, which would cause break after merging his branch into the upstream. Tested against a one-month old commit does not guarantee that it should work as expected after merge. The developer surely should rebase his branch to the current HEAD of master to resolve any issues and do a testing to make sure his branch works as correctly on the current HEAD before ask for a pull to merge. I would like a clean, atomic, linear history in the upstream. Regards, Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 3/3] ft2232: Add casts to avoid warnings
On Thu, Aug 11, 2011 at 4:47 PM, Spencer Oliver s...@spen-soft.co.uk wrote: On 01/08/2011 10:05, Spencer Oliver wrote: On 29 July 2011 22:23, Andreas Fritiofsonandreas.fritiof...@gmail.com wrote: Another fix would be not trying to print the status as a numeric value. We can print it as an error message, so we don't need to handle this tricky situation. Like LOG_ERROR(FT_Write failed:%s\n, ftd2xx_status_string(status)); That sounds *way* better. And more helpful to the user, too. If it's available in all recent ftd2xx versions on all platforms, I'd say it's a go. Any takers for putting together the patch? /Andreas Anyone having a go at this - if not i may get a chance later on in the week? Cheers Spen I have merged a patch that should sort all these warnings out. Thanks. But it's on your git tree, not on the public one, right? Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.5.0 MinGW configure failure
On Wed, Aug 10, 2011 at 9:29 AM, Xiaofan Chen xiaof...@gmail.com wrote: On Tue, Aug 9, 2011 at 10:20 PM, Spencer Oliver s...@spen-soft.co.uk wrote: Just tested building native windoze under cygwin and working fine here. I used the release tarball and the following configure line: ./configure --build=i686-pc-cygwin --host=i686-pc-mingw32 --disable-shared --disable-werror --enable-ft2232_ftd2xx Yes --disable-werror is necessary. If not the following errors will come out. I remember Jie Zheng has some proposals to fix this. ../../../../src/jtag/drivers/ft2232.c: In function 'ft2232_write': ../../../../src/jtag/drivers/ft2232.c:518:3: error: format '%u' expects type 'unsigned int', but argument 6 has type 'FT_STATUS' Yes. And Spencer said he would fix it if he got a chance. Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Code review and git pull
Hi, Just to make sure that we still do code review with git pull, right? The developer still need to post all his/her patches for review before he/she asks for pull, right? Regards, Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Code review and git pull
On Wed, Aug 10, 2011 at 11:00 AM, Øyvind Harboe oyvind.har...@zylin.com wrote: On Wed, Aug 10, 2011 at 4:21 PM, Jie Zhang jzhang...@gmail.com wrote: Hi, Just to make sure that we still do code review with git pull, right? The developer still need to post all his/her patches for review before he/she asks for pull, right? I think inline for review and a pull request once all issues have been settled for patch series works well. Good. I was a little worried that patch would be pulled without review. Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] remove useless pxref to SMP subsection
Hi,
I believe that pxref is useless. Please review and merge if OK. Thank you!
Jie
From a78298da35c10a45136fdae0caede2860d30bbf5 Mon Sep 17 00:00:00 2001
From: Jie Zhang jie.zh...@analog.com
Date: Wed, 10 Aug 2011 15:32:09 -0400
Subject: [PATCH] remove useless pxref to SMP subsection
---
doc/openocd.texi |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/doc/openocd.texi b/doc/openocd.texi
index e3934e8..8b7e588 100644
--- a/doc/openocd.texi
+++ b/doc/openocd.texi
@@ -1677,7 +1677,7 @@ Again using the at91sam7 as an example, this can look like:
$_TARGETNAME configure -work-area-phys 0x0020 \
-work-area-size 0x4000 -work-area-backup 0
@end example
-@pxref{Define CPU targets working in SMP}
+
@anchor{Define CPU targets working in SMP}
@subsection Define CPU targets working in SMP
@cindex SMP
--
1.7.5.4
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Replace script with source
On Wed, Aug 10, 2011 at 8:27 PM, Steve Bennett ste...@workware.net.au wrote: On 09/08/2011, at 11:18 PM, Jie Zhang wrote: Hi, Since we are in merge window now, how about merge this patch to replace script with source: https://lists.berlios.de/pipermail/openocd-development/2011-July/020370.html If there is any issue, we still have enough time to revert this change. I don't see any advantage to removing 'script'. I think it is better to have script evaluate in global scope. Then could you make a patch and merge it. I have no strong opinion on this. Thank you! Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.5.0 MinGW configure failure
On Tue, Aug 9, 2011 at 7:52 AM, Vit Mares mares@gmail.com wrote: Attempt to build 0.5.0 with MinGW on Windows XP failed when running configure. Release 0.4.0 configured and built without problems. I downloaded 0.5.0 and built it with mingw-w64 on Debian testing. The build was successful. But I didn't try the resulted binary. Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Replace script with source
Hi, Since we are in merge window now, how about merge this patch to replace script with source: https://lists.berlios.de/pipermail/openocd-development/2011-July/020370.html If there is any issue, we still have enough time to revert this change. Regards, Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Better fixes for set but not used warnings
On Mon, Aug 1, 2011 at 10:18 AM, Spencer Oliver s...@spen-soft.co.uk wrote: On 29 July 2011 16:54, Jie Zhang jzhang...@gmail.com wrote: On Fri, Jul 29, 2011 at 11:41 AM, Spencer Oliver s...@spen-soft.co.uk wrote: On 29 July 2011 15:32, Jie Zhang jzhang...@gmail.com wrote: I happened to find that two previous fixes for set-but-not-used warnings are not correct or not good. This patch should be an improvement. Please review and merge if good. I am going to look into tis one, as one minute the code is there, next minute it was deleted - very strange. To ease your review, the related commits are f6315d5e5b7b71515ef051711e5f818a42d6b3b3 smp.c 1cfb2287a67c1f78b76583b2e5ed83ca3560b0d5 etb.c Cool you patch looks fine - i will commit. Thank you! Just for info this function was first broken in d7f71e7fe9645fa8c3f88cf6fc9ad438aa6708f3. The whitespace cleanup was a very strict indeed :) It has been broken for more than 2 years but no one noticed it. It seems no one use that piece of code. Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Reset fails LM3S Tempest C5 due to failure to read device class
On Sat, Jul 30, 2011 at 5:48 PM, B bbcu2...@gmail.com wrote: Using Open On-Chip Debugger 0.5.0-dev-00948-gd4cd6f0 (2011-07-30-15:55) LM3S3N26-C5 is not detected as a Tempest device and so uses the sysresetreq in place of the needed vectreset in stellaris.cfg. The device class appears to be set by: set device_class [expr (([mrw 0x400fe000] 16) 0xff)] This memory location contains the device class. Tempest is 0x04. There is an errata where LM3S3N26 misreports itself as 0x03. My attempt at a workaround was to define a variable: set DEVICECLASSIS 0x04 How did you define it? then call a modified stellaris.cfg: How did you call it? If you defined DEVICECLASSIS in a config file and used a -f option to add that config file and a -f to add stellaris.cfg, sellaris.cfg could not see DEVICECLASSIS because it was not a global variable. You will need to declare it as global explicitly. Weird? See the thread script vs source I started several days ago for an explanation. Regards, Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 3/3] ft2232: Add casts to avoid warnings
On Mon, Aug 1, 2011 at 5:05 AM, Spencer Oliver s...@spen-soft.co.uk wrote: On 29 July 2011 22:23, Andreas Fritiofson andreas.fritiof...@gmail.com wrote: Another fix would be not trying to print the status as a numeric value. We can print it as an error message, so we don't need to handle this tricky situation. Like LOG_ERROR(FT_Write failed:%s\n, ftd2xx_status_string(status)); That sounds *way* better. And more helpful to the user, too. If it's available in all recent ftd2xx versions on all platforms, I'd say it's a go. Any takers for putting together the patch? /Andreas Anyone having a go at this - if not i may get a chance later on in the week? Please, thank you! Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] script command
On Fri, Jul 29, 2011 at 12:10 AM, Steve Bennett ste...@workware.net.au wrote: On 29/07/2011, at 2:06 PM, Steve Bennett wrote: On 29/07/2011, at 1:40 PM, Jie Zhang wrote: Hi, Where is the script command defined? I greped in jimtcl and openocd source code, but could not find it. Thank you! Jie src/helper/startup.tcl line 57 And here's a trick for you. If you want to know when any Tcl procedure is defined, you can run a command like: info source [info body script] This will show where the proc 'script' is defined. Won't work for built-in commands, since there is no corresponding source location. Thank you! I have another question about script command. I will ask in a separate thread. Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] script vs source
Hi,
OpenOCD uses script command to execute config file passed through -f
option. script command is defined as a function
proc script {filename} {
source [find $filename]
}
Thus when executing the config file, global variables defined in that
config file is not global any more. If I define a global variable
set foo 1
in target config file, then trying to read its value by
obj = Jim_GetGlobalVariableStr (interp, foo, 0);
Jim_GetLong(interp, obj, foo);
in OpenOCD will fail because foo is not defined in global namespace.
And the following code in a target config file will not work as
expected:
set foo 1
proc test { } {
puts $::foo
}
test
It's counterintuitive.
Is this effect is by design or by accident? I can see that using
script command can avoid name conflicts between config files. But it
prevents config files from sharing global variables. It also prevents
OpenOCD from accessing global variables defined in config files by
Jim_GetGlobalVariableStr.
Regards,
Jie
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] script vs source
Let's me explain more on what I'm trying to do.
In Blackfin gdbproxy, I hardcoded memory maps in C source code. When
moving to OpenOCD, I'm trying to put them in the config files, which
is something in my TODO list for a long time. At that time I thought
about using an XML file for this purpose. But since OpenOCD has
builtin tcl, I'm trying to save some time by just using tcl. So I can
define
set sdram_start 0
set sdram_end 0x2000
in the target config file and then target create function can read
these variables to create a memory map.
I'm still considering using XML, since tcl is good for memory maps but
not good for MMRs when MMRs have different size. Do you think it's a
good idea to linked in expat library?
Jie
On Fri, Jul 29, 2011 at 7:12 AM, Øyvind Harboe oyvindhar...@gmail.com wrote:
Its historical. Perhaps it should be this way? Perhaps ot is better to pass
args as args to procs rathr than global variables? Perhaps we should retire
script?
On Jul 29, 2011 12:45 PM, Jie Zhang jzhang...@gmail.com wrote:
Hi,
OpenOCD uses script command to execute config file passed through -f
option. script command is defined as a function
proc script {filename} {
source [find $filename]
}
Thus when executing the config file, global variables defined in that
config file is not global any more. If I define a global variable
set foo 1
in target config file, then trying to read its value by
obj = Jim_GetGlobalVariableStr (interp, foo, 0);
Jim_GetLong(interp, obj, foo);
in OpenOCD will fail because foo is not defined in global namespace.
And the following code in a target config file will not work as
expected:
set foo 1
proc test { } {
puts $::foo
}
test
It's counterintuitive.
Is this effect is by design or by accident? I can see that using
script command can avoid name conflicts between config files. But it
prevents config files from sharing global variables. It also prevents
OpenOCD from accessing global variables defined in config files by
Jim_GetGlobalVariableStr.
Regards,
Jie
___
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
Re: [Openocd-development] script vs source
On Fri, Jul 29, 2011 at 7:34 AM, Spencer Oliver s...@spen-soft.co.uk wrote:
On 29 July 2011 11:45, Jie Zhang jzhang...@gmail.com wrote:
Hi,
OpenOCD uses script command to execute config file passed through -f
option. script command is defined as a function
proc script {filename} {
source [find $filename]
}
Thus when executing the config file, global variables defined in that
config file is not global any more. If I define a global variable
set foo 1
in target config file, then trying to read its value by
obj = Jim_GetGlobalVariableStr (interp, foo, 0);
Jim_GetLong(interp, obj, foo);
use global, eg.
global foo
set foo 1
This trick works, but not pretty. So I asked why we added script
wrapper for source command
Jie
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] script vs source
On Fri, Jul 29, 2011 at 7:12 AM, Øyvind Harboe oyvindhar...@gmail.com wrote: Its historical. Perhaps it should be this way? Perhaps ot is better to pass args as args to procs rathr than global variables? Perhaps we should retire script? It's really historical. It was in the first commit in the OpenOCD git repository. Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] Better fixes for set but not used warnings
I happened to find that two previous fixes for set-but-not-used
warnings are not correct or not good. This patch should be an
improvement. Please review and merge if good.
Regards,
Jie
diff --git a/src/target/etb.c b/src/target/etb.c
index 3cb2254..974ab2b 100644
--- a/src/target/etb.c
+++ b/src/target/etb.c
@@ -304,20 +304,32 @@ static int etb_write_reg(struct reg *reg, uint32_t value)
{
struct etb_reg *etb_reg = reg-arch_info;
uint8_t reg_addr = etb_reg-addr 0x7f;
+ struct scan_field fields[3];
LOG_DEBUG(%i: 0x%8.8 PRIx32 , (int)(etb_reg-addr), value);
etb_scann(etb_reg-etb, 0x0);
etb_set_instr(etb_reg-etb, 0xc);
+ fields[0].num_bits = 32;
uint8_t temp0[4];
+ fields[0].out_value = temp0;
buf_set_u32(temp0, 0, 32, value);
+ fields[0].in_value = NULL;
+ fields[1].num_bits = 7;
uint8_t temp1;
+ fields[1].out_value = temp1;
buf_set_u32(temp1, 0, 7, reg_addr);
+ fields[1].in_value = NULL;
+ fields[2].num_bits = 1;
uint8_t temp2;
+ fields[2].out_value = temp2;
buf_set_u32(temp2, 0, 1, 1);
+ fields[2].in_value = NULL;
+
+ jtag_add_dr_scan(etb_reg-etb-tap, 3, fields, TAP_IDLE);
return ERROR_OK;
}
diff --git a/src/target/smp.c b/src/target/smp.c
index f4adc8d..ec157d3 100644
--- a/src/target/smp.c
+++ b/src/target/smp.c
@@ -79,7 +79,7 @@ int gdb_read_smp_packet(struct connection *connection,
hex_buffer[2 * i + 1] = DIGITS[t 0xf];
}
- gdb_put_packet(connection, hex_buffer, len * 2);
+ retval = gdb_put_packet(connection, hex_buffer, len * 2);
free(hex_buffer);
}
@@ -95,6 +95,7 @@ int gdb_write_smp_packet(struct connection *connection,
{
char *separator;
int coreid = 0;
+ int retval = ERROR_OK;
/* skip command character */
if (target-smp)
@@ -104,13 +105,13 @@ int gdb_write_smp_packet(struct connection *connection,
packet+=2;
coreid = strtoul(packet, separator, 16);
target-gdb_service-core[1] = coreid;
- gdb_put_packet(connection, OK, 2);
+ retval = gdb_put_packet(connection, OK, 2);
}
}
else
{
- gdb_put_packet(connection,E01,3);
+ retval = gdb_put_packet(connection,E01,3);
}
- return ERROR_OK;
+ return retval;
}
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] script vs source
On Fri, Jul 29, 2011 at 8:16 AM, Steve Bennett ste...@workware.net.au wrote:
Makes sense to me to change it to:
proc script {filename} {
uplevel #0 source [find $filename]
}
The attached patch removes script command completely.
Jie
From f00a57d009fb713091b096521e82600a2e2401c2 Mon Sep 17 00:00:00 2001
From: Jie Zhang jie.zh...@analog.com
Date: Fri, 29 Jul 2011 10:45:10 -0400
Subject: [PATCH] remove script command
---
src/helper/configuration.c |2 +-
src/helper/options.c |2 +-
src/helper/startup.tcl |7 ---
3 files changed, 2 insertions(+), 9 deletions(-)
diff --git a/src/helper/configuration.c b/src/helper/configuration.c
index eedd8a1..752b338 100644
--- a/src/helper/configuration.c
+++ b/src/helper/configuration.c
@@ -116,7 +116,7 @@ int parse_config_file(struct command_context *cmd_ctx)
char **cfg;
if (!config_file_names) {
- command_run_line(cmd_ctx, script openocd.cfg);
+ command_run_line(cmd_ctx, source [find openocd.cfg]);
return ERROR_OK;
}
diff --git a/src/helper/options.c b/src/helper/options.c
index f8db2cd..0d77fde 100644
--- a/src/helper/options.c
+++ b/src/helper/options.c
@@ -150,7 +150,7 @@ int parse_cmdline_args(struct command_context *cmd_ctx, int argc, char *argv[])
break;
case 'f': /* --file | -f */
{
-snprintf(command_buffer, 128, script {%s}, optarg);
+snprintf(command_buffer, 128, source [find %s], optarg);
add_config_command(command_buffer);
break;
}
diff --git a/src/helper/startup.tcl b/src/helper/startup.tcl
index 2e2982c..dc43801 100644
--- a/src/helper/startup.tcl
+++ b/src/helper/startup.tcl
@@ -53,12 +53,5 @@ proc find {filename} {
add_usage_text find file
add_help_text find print full path to file according to OpenOCD search rules
-# Run script
-proc script {filename} {
- source [find $filename]
-}
-add_help_text script filename of OpenOCD script (tcl) to run
-add_usage_text script file
-
#
--
1.7.5.4
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] script vs source
On Fri, Jul 29, 2011 at 11:24 AM, Jie Zhang jzhang...@gmail.com wrote:
On Fri, Jul 29, 2011 at 8:16 AM, Steve Bennett ste...@workware.net.au wrote:
Makes sense to me to change it to:
proc script {filename} {
uplevel #0 source [find $filename]
}
The attached patch removes script command completely.
This is a newer version.
Jie
From cdf843cd871cbd42d54fe548d5c5cb146b5b4c12 Mon Sep 17 00:00:00 2001
From: Jie Zhang jie.zh...@analog.com
Date: Fri, 29 Jul 2011 11:17:54 -0400
Subject: [PATCH] remove script command
---
src/ecosboard.c |2 +-
src/helper/configuration.c|2 +-
src/helper/options.c |2 +-
src/helper/startup.tcl|7 ---
tcl/interface/calao-usb-a9260-c01.cfg |4 ++--
tcl/interface/calao-usb-a9260-c02.cfg |4 ++--
6 files changed, 7 insertions(+), 14 deletions(-)
diff --git a/src/ecosboard.c b/src/ecosboard.c
index 0805e6f..a522160 100644
--- a/src/ecosboard.c
+++ b/src/ecosboard.c
@@ -1123,7 +1123,7 @@ int main(int argc, char *argv[])
command_run_line(cmd_ctx, debug_level 3);
}
- command_run_linef(cmd_ctx, script /rom/openocd.cfg);
+ command_run_linef(cmd_ctx, source [find /rom/openocd.cfg]);
int ret;
ret = server_init(cmd_ctx);
diff --git a/src/helper/configuration.c b/src/helper/configuration.c
index eedd8a1..752b338 100644
--- a/src/helper/configuration.c
+++ b/src/helper/configuration.c
@@ -116,7 +116,7 @@ int parse_config_file(struct command_context *cmd_ctx)
char **cfg;
if (!config_file_names) {
- command_run_line(cmd_ctx, script openocd.cfg);
+ command_run_line(cmd_ctx, source [find openocd.cfg]);
return ERROR_OK;
}
diff --git a/src/helper/options.c b/src/helper/options.c
index f8db2cd..0d77fde 100644
--- a/src/helper/options.c
+++ b/src/helper/options.c
@@ -150,7 +150,7 @@ int parse_cmdline_args(struct command_context *cmd_ctx, int argc, char *argv[])
break;
case 'f': /* --file | -f */
{
-snprintf(command_buffer, 128, script {%s}, optarg);
+snprintf(command_buffer, 128, source [find %s], optarg);
add_config_command(command_buffer);
break;
}
diff --git a/src/helper/startup.tcl b/src/helper/startup.tcl
index 2e2982c..dc43801 100644
--- a/src/helper/startup.tcl
+++ b/src/helper/startup.tcl
@@ -53,12 +53,5 @@ proc find {filename} {
add_usage_text find file
add_help_text find print full path to file according to OpenOCD search rules
-# Run script
-proc script {filename} {
- source [find $filename]
-}
-add_help_text script filename of OpenOCD script (tcl) to run
-add_usage_text script file
-
#
diff --git a/tcl/interface/calao-usb-a9260-c01.cfg b/tcl/interface/calao-usb-a9260-c01.cfg
index c660671..a7ae26a 100644
--- a/tcl/interface/calao-usb-a9260-c01.cfg
+++ b/tcl/interface/calao-usb-a9260-c01.cfg
@@ -8,6 +8,6 @@ interface ft2232
ft2232_layout jtagkey
ft2232_device_desc USB-A9260
ft2232_vid_pid 0x0403 0x6010
-script interface/calao-usb-a9260.cfg
-script target/at91sam9260minimal.cfg
+source [find interface/calao-usb-a9260.cfg]
+source [find target/at91sam9260minimal.cfg]
diff --git a/tcl/interface/calao-usb-a9260-c02.cfg b/tcl/interface/calao-usb-a9260-c02.cfg
index 2461b70..073c9a3 100644
--- a/tcl/interface/calao-usb-a9260-c02.cfg
+++ b/tcl/interface/calao-usb-a9260-c02.cfg
@@ -8,6 +8,6 @@ interface ft2232
ft2232_layout jtagkey
ft2232_device_desc USB-A9260
ft2232_vid_pid 0x0403 0x6001
-script interface/calao-usb-a9260.cfg
-script target/at91sam9260minimal.cfg
+source [find interface/calao-usb-a9260.cfg]
+source [find target/at91sam9260minimal.cfg]
--
1.7.5.4
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Better fixes for set but not used warnings
On Fri, Jul 29, 2011 at 11:41 AM, Spencer Oliver s...@spen-soft.co.uk wrote: On 29 July 2011 15:32, Jie Zhang jzhang...@gmail.com wrote: I happened to find that two previous fixes for set-but-not-used warnings are not correct or not good. This patch should be an improvement. Please review and merge if good. I am going to look into tis one, as one minute the code is there, next minute it was deleted - very strange. To ease your review, the related commits are f6315d5e5b7b71515ef051711e5f818a42d6b3b3 smp.c 1cfb2287a67c1f78b76583b2e5ed83ca3560b0d5 etb.c Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 3/3] ft2232: Add casts to avoid warnings
On Fri, Jun 24, 2011 at 3:14 PM, Jie Zhang jzhang...@gmail.com wrote: On Mon, Jun 20, 2011 at 6:50 AM, Steve Bennett ste...@workware.net.au wrote: The default is -Werror, so warnings become errors and stop the build. Might be better to simply #define FT_STATUS instead. - LOG_ERROR(FT_Write returned: %lu, status); + LOG_ERROR(FT_Write returned: %lu, (unsigned long)status); The type of status is ULONG, which is unsigned long on Windows but is unsigned int on Linux in FTD2XX driver. So the problem is %lu is not right for status on Linux. If we don't want cast, I think we can do something like: #ifdef __WINDOWS_TYPES__ /* if FTD2XX WinTypes.h is included */ #define PRulong u #else #define PRulong lu #endif LOG_ERROR(FT_Write returned: %PRulong, status); Another fix would be not trying to print the status as a numeric value. We can print it as an error message, so we don't need to handle this tricky situation. Like LOG_ERROR(FT_Write failed:%s\n, ftd2xx_status_string(status)); UrJTAG uses this method. Regards, Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] script command
Hi, Where is the script command defined? I greped in jimtcl and openocd source code, but could not find it. Thank you! Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] Update doc about Jim
The commit log explains this patch.
Jie
From 00597ea44a60e70a86ef989acfb8193c15de811a Mon Sep 17 00:00:00 2001
From: Jie Zhang jie.zh...@analog.com
Date: Thu, 21 Jul 2011 11:16:50 -0400
Subject: [PATCH] Update doc about Jim since it's not a single .C file and a
single .H file any more
---
doc/openocd.texi |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/doc/openocd.texi b/doc/openocd.texi
index fd92d51..e9e32b8 100644
--- a/doc/openocd.texi
+++ b/doc/openocd.texi
@@ -526,7 +526,7 @@ OpenOCD mailing list.
@item @b{Jim vs. Tcl}
@* Jim-Tcl is a stripped down version of the well known Tcl language,
which can be found here: @url{http://www.tcl.tk}. Jim-Tcl has far
-fewer features. Jim-Tcl is a single .C file and a single .H file and
+fewer features. Jim-Tcl is several dozens of .C files and .H files and
implements the basic Tcl command set. In contrast: Tcl 8.6 is a
4.2 MB .zip file containing 1540 files.
--
1.7.5.4
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] Remove deprecated '-p' option from doc
The subject explains this patch.
Jie
From 26f44455cf1db6f2efb8531f5476ad2845e47f13 Mon Sep 17 00:00:00 2001
From: Jie Zhang jie.zh...@analog.com
Date: Thu, 21 Jul 2011 11:29:20 -0400
Subject: [PATCH] remove doc on the deprecated '-p' option
---
doc/openocd.texi |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/doc/openocd.texi b/doc/openocd.texi
index e9e32b8..7e99d5a 100644
--- a/doc/openocd.texi
+++ b/doc/openocd.texi
@@ -676,8 +676,6 @@ setting from within a telnet or gdb session using @command{debug_level
You can redirect all output from the daemon to a file using the
@option{-l logfile} switch.
-For details on the @option{-p} option. @xref{Connecting to GDB}.
-
Note! OpenOCD will launch the GDB telnet server even if it can not
establish a connection with the target. In general, it is possible for
the JTAG controller to be unresponsive until the target is set up
--
1.7.5.4
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] How to build openocd with debug symbols (-g)???
I noticed that: On Mon, Jul 18, 2011 at 10:41 PM, Brian Hutchinson b.hutch...@gmail.com wrote: GNU gdb (GDB) 7.1 This GDB was configured as i686-pc-linux-gnu. and hutch@neo:~/openocd/openocd/src$ file ./openocd ./openocd: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), So gdb is for i686-pc-linux-gnu, but your openocd is x86-64. Regards, Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] libswd drivers question
On Thu, Jul 14, 2011 at 8:58 AM, Tomek CEDRO tomek.ce...@gmail.com wrote: Hello! Sorry for cross-posting but this somehow touches both applications. LibSWD is a standalone library that can generate SWD operations, then flush them into device driver. This driver (some function set) is application specific, so it cannot be compiled in into libswd, but rather linked with libswd during application compilation. However libswd then complains about missing driver functions at linking time. For UrJTAG I have copied sources of libswd into application source tree and passed proper source file with driver functions to compile everything and then link with urjtag binary. This was fine until I included LibSWD as OpenOCD submodule, because now it requires its own empty drivers to compile, and those drivers override openocd's drivers. When I removed template drivers from libswd source tree so it can be linked with drivers already compiled and provided by openocd, there are some unresolved dependencies in libswd.la submodule. This is the only thing that keeps me from running libswd on openocd :-) Do you have a step by step instruction to reproduce this issue? Regards, Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Building local bootstrap jimsh0 failed
On Thu, Jul 14, 2011 at 8:57 AM, Spencer Oliver s...@spen-soft.co.uk wrote: I tell a lie, just discovered the noinst_SUBDIRS and that seems todo what we want Spoke to soon, does not work. So at the moment i am out of ideas It works for me. With the attached patch, make install does not install jimtcl any more. Regards, Jie diff --git a/Makefile.am b/Makefile.am index 1b19ba4..a02ed1b 100644 --- a/Makefile.am +++ b/Makefile.am @@ -13,12 +13,10 @@ nobase_dist_pkgdata_DATA = \ contrib/openocd.udev if INTERNAL_JIMTCL -SUBDIRS = jimtcl -else -SUBDIRS = +noinst_SUBDIRS = jimtcl endif -SUBDIRS += src doc +SUBDIRS = src doc EXTRA_DIST = \ BUGS \ ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Building local bootstrap jimsh0 failed
On Thu, Jul 14, 2011 at 10:57 AM, Spencer Oliver s...@spen-soft.co.uk wrote: On 14 July 2011 15:01, Jie Zhang jzhang...@gmail.com wrote: On Thu, Jul 14, 2011 at 8:57 AM, Spencer Oliver s...@spen-soft.co.uk wrote: I tell a lie, just discovered the noinst_SUBDIRS and that seems todo what we want Spoke to soon, does not work. So at the moment i am out of ideas It works for me. With the attached patch, make install does not install jimtcl any more. I thought that to, but do s distclean and check again. Simply using noinst_SUBDIRS means make never gets called in the jimtcl dir. You are right. Automake does not support noinst_SUBDIRS. It has noinst_PROGRAMS, noinst_LIBRARIES, and noinst_HEADERS. But they need to be used in jimctl/ . Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Building local bootstrap jimsh0 failed
On Thu, Jul 14, 2011 at 6:17 AM, Steve Bennett ste...@workware.net.au wrote: On 14/07/2011, at 7:19 PM, Spencer Oliver wrote: This is why i mentioned before about adding a configure option to jimtcl, something like --noinstall It seems weird to have a configure option which causes 'make install' to not install. Seems like it will just confuse other users of jimtcl. Maybe with a clear help documentation and a good default setting, it will not be so confusing. I think we can have --disable-install-jimtcl, default off, i.e, --enable-install-jimtcl, for jimtcl. Then turn it on in OpenOCD. The help documentation could be --disable-install-jimtcl controls installation of jimctl and related headers. usually used when jimctl is embeded in another program. I'm also wondering if it's a good idea to make jimtcl use automake, which should make implementing this easier. Regards, Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Building local bootstrap jimsh0 failed
On Thu, Jul 14, 2011 at 12:07 PM, Jie Zhang jzhang...@gmail.com wrote:
On Thu, Jul 14, 2011 at 6:17 AM, Steve Bennett ste...@workware.net.au wrote:
On 14/07/2011, at 7:19 PM, Spencer Oliver wrote:
This is why i mentioned before about adding a configure option to
jimtcl, something like --noinstall
It seems weird to have a configure option which causes 'make install'
to not install. Seems like it will just confuse other users of jimtcl.
Maybe with a clear help documentation and a good default setting, it
will not be so confusing. I think we can have
--disable-install-jimtcl, default off, i.e, --enable-install-jimtcl,
for jimtcl. Then turn it on in OpenOCD. The help documentation could
be
--disable-install-jimtcl controls installation of jimctl and related
headers.
usually used when jimctl is embeded in
another program.
I'm also wondering if it's a good idea to make jimtcl use automake,
which should make implementing this easier.
Jim uses autosetup instead of autoconf. So it does not make much sense
to use automake.
Anyway I think Spencer's idea about adding a configure option to
disable Jim installation is good. So I implemented it. I change the
option name to --disable-install-jim to save 3 characters.
Three patches are attached:
jim-configure-disable-install.diff is for upstream Jim
openocd-jim-configure-disable-install.diff is for Jim in OpenOCD
openocd-dont-install-jimtcl.diff makes OpenOCD to use the new added
configure option.
Regards,
Jie
diff --git a/Makefile.in b/Makefile.in
index 73c9cc8..0b031ae 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -7,6 +7,7 @@ STRIP = @STRIP@
# Configuration
jim_libtype := @JIM_LIBTYPE@
+install_jim := @INSTALL_JIM@
SH_CFLAGS ?= @SH_CFLAGS@
SH_LDFLAGS ?= @SH_LDFLAGS@
SHOBJ_CFLAGS ?= @SHOBJ_CFLAGS@
@@ -60,6 +61,7 @@ $(JIMSH): $(LIBJIM) jimsh.o _initjimsh.o
$(CC) $(CFLAGS) @SH_LINKFLAGS@ $(LDFLAGS) -o $@ jimsh.o _initjimsh.o $(LIBJIM) $(LDLIBS)
install: all docs $(EXTENSION_TCL) install-exec
+ifeq ($(install_jim),enable)
mkdir -p $(DESTDIR)$(prefix)/lib/jim
cp $(LIBJIM) $(DESTDIR)$(prefix)/lib
cp @srcdir@/README.extensions $(C_EXT_SHOBJS) $(EXTENSION_TCL) $(DESTDIR)$(prefix)/lib/jim
@@ -69,17 +71,22 @@ install: all docs $(EXTENSION_TCL) install-exec
cp jim-config.h $(DESTDIR)$(prefix)/include
mkdir -p $(DESTDIR)$(prefix)/doc/jim
cp Tcl.html $(DESTDIR)$(prefix)/doc/jim
+endif
install-exec: all
+ifeq ($(install_jim),enable)
mkdir -p $(DESTDIR)$(prefix)/bin
cp $(JIMSH) $(DESTDIR)$(prefix)/bin
+endif
uninstall:
+ifeq ($(install_jim),enable)
rm -f $(DESTDIR)$(prefix)/bin/$(JIMSH)
rm -f $(DESTDIR)$(prefix)/lib/$(LIBJIM)
for i in README.extensions $(C_EXT_SHOBJS) $(EXTENSION_TCL); do rm -f $(DESTDIR)$(prefix)/lib/jim/$$i; done
rm -f $(DESTDIR)$(prefix)/include/jim*.h
rm -f $(DESTDIR)$(prefix)/doc/jim/Tcl.html
+endif
test: $(JIMSH)
$(DEF_LD_PATH) $(MAKE) jimsh=`pwd`/jimsh -C @srcdir@/tests
diff --git a/auto.def b/auto.def
index 0ac4dde..6540562 100644
--- a/auto.def
+++ b/auto.def
@@ -11,7 +11,8 @@ options {
math= include support for math functions
ipv6= include ipv6 support in the aio extension
maintainer = {enable the [debug] command and JimPanic}
-full= Enable some optional features: ipv6, math, utf8, binary, oo, tree
+full= enable some optional features: ipv6, math, utf8, binary, oo, tree
+install-jim=1 = disable installation, useful when Jim is embedded in applications
with-jim-shared shared = build a shared library instead of a static library
jim-regexp = use the built-in (Tcl-compatible) regexp, even if POSIX regex is available
with-jim-ext: {with-ext:ext1 ext2 ...} = {
@@ -145,6 +146,12 @@ if {[opt-bool references]} {
msg-result Enabling references
define JIM_REFERENCES
}
+if {[opt-bool install-jim]} {
+define INSTALL_JIM enable
+} else {
+msg-result Disabling installation
+define INSTALL_JIM disable
+}
if {[opt-bool shared with-jim-shared]} {
msg-result Building shared library
define JIM_LIBTYPE shared
diff --git a/Makefile.in b/Makefile.in
index 80ea37f..ac709db 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -7,6 +7,7 @@ STRIP = @STRIP@
# Configuration
jim_libtype := @JIM_LIBTYPE@
+install_jim := @INSTALL_JIM@
SH_CFLAGS ?= @SH_CFLAGS@
SH_LDFLAGS ?= @SH_LDFLAGS@
SHOBJ_CFLAGS ?= @SHOBJ_CFLAGS@
@@ -56,6 +57,7 @@ $(JIMSH): $(LIBJIM) jimsh.o
$(CC) $(CFLAGS) @SH_LINKFLAGS@ $(LDFLAGS) -o $@ jimsh.o $(LIBJIM) $(LDLIBS)
install: all docs $(EXTENSION_TCL) install-exec
+ifeq ($(install_jim),enable)
mkdir -p $(DESTDIR)$(prefix)/lib/jim
cp $(LIBJIM) $(DESTDIR)$(prefix)/lib
cp @srcdir@/README.extensions $(EXTENSION_MODS) $(EXTENSION_TCL) $(DESTDIR)$(prefix)/lib/jim
@@ -65,17 +67,22 @@ install: all docs $(EXTENSION_TCL) install-exec
cp jim-config.h $(DESTDIR)$(prefix)/include
mkdir -p $(DESTDIR)$(prefix)/doc/jim
cp Tcl.html
Re: [Openocd-development] bootstrap wrarning under Ubuntu 11.04
On Wed, Jul 13, 2011 at 8:19 AM, Xiaofan Chen xiaof...@gmail.com wrote: I have seen some warnings when doing bootstrap. I am not so sure if this is a bug with Ubuntu autotools or with configure.in. The same problem exists in Ubuntu 10.10 and 10.04. mcuee@Ubuntu:~/Desktop/build/openocd/openocd$ ./bootstrap + aclocal configure.in:2: warning: AC_INIT: not a literal: OpenOCD Mailing List openocd-development@lists.berlios.de It's a bug of autoconf. It has been fixed in autoconf-2.68. See http://savannah.gnu.org/support/?107450 Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [OpenOCD] Defined but not used
On Wed, Jul 6, 2011 at 3:21 PM, Drasko DRASKOVIC drasko.drasko...@gmail.com wrote: I thought that there might be a method of leaving this stuff into the code but preceding it wit some macro NOT_USED, or something... You can use the following GCC attribute for your purpose. unused This attribute, attached to a function, means that the function is meant to be possibly unused. GCC will not produce a warning for this function. However, I don't think it's a good idea to leave unused function in source code. Such functions will soon rot and finally become useless and maintenance burden since it's not used anywhere. Regards, Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD 0.5.0-rc1 release
On Tue, Jun 28, 2011 at 12:26 PM, Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com wrote: Changelog What is this change against? Some commit on master? Regards, Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] RFC Release Cycle
On Tue, Jun 28, 2011 at 1:56 PM, Øyvind Harboe oyvind.har...@zylin.com wrote: On Tue, Jun 28, 2011 at 7:30 PM, Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com wrote: On 19:39 Tue 28 Jun , Øyvind Harboe wrote: but now all the maintainer will have their own fork/repository as done in the kernel Right. And you will pull merge from us and push the result to the master branch? exactly I'd have some reservations about only one person having write access, but not particularly the way of working. Call me old fashioned. It's not old fashioned. It's just how Linux works. Other projects have different release management processes. One kind of releasing process I know is (briefly): Multiple people have write access to the master branch. When the release manager think it's a good time to do a release, he/she will create a branch for that release. After that branch has been created, all new features will only go to the master branch. All fixes will go to the master branch as well as to the release branch if they are needed there. Developers can cherry-pick their fix from master to the release branch under approval of release manager, or the release manager can do the cherry-picking. When the release branch comes to a good status, the release manager roll out a release. Several very large projects use this kind of process. It works well. Btw, I don't think it's a good idea to put release branch in a separate git repository. Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] transport selection fix
On Sat, Jun 18, 2011 at 4:36 AM, Tomek CEDRO tomek.ce...@gmail.com wrote: On Thu, Jun 16, 2011 at 9:42 PM, Andreas Fritiofson andreas.fritiof...@gmail.com wrote: a ? : b is equivalent to a ? a : b, unless evaluating a has side-effects or if a is volatile, since it's only evaluated once in the former case and twice in the latter. Nice to know, thanks! Is that true for all compilers? It's a C language extension provided by GCC. I don't think all compilers support this. Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 3/3] ft2232: Add casts to avoid warnings
On Mon, Jun 20, 2011 at 6:50 AM, Steve Bennett ste...@workware.net.au wrote: The default is -Werror, so warnings become errors and stop the build. Might be better to simply #define FT_STATUS instead. - LOG_ERROR(FT_Write returned: %lu, status); + LOG_ERROR(FT_Write returned: %lu, (unsigned long)status); The type of status is ULONG, which is unsigned long on Windows but is unsigned int on Linux in FTD2XX driver. So the problem is %lu is not right for status on Linux. If we don't want cast, I think we can do something like: #ifdef __WINDOWS_TYPES__ /* if FTD2XX WinTypes.h is included */ #define PRulong u #else #define PRulong lu #endif LOG_ERROR(FT_Write returned: %PRulong, status); Just my $0.02. Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] bugfix for adapter_khz_to_speed
On Wed, May 25, 2011 at 6:32 PM, Kevin Kiningham kevi...@umich.edu wrote: adapter_khz_to_speed wasn't changing the speed variable passed to it if the jtag interface wasn't set up. Otherwise, if adapter_khz was called before openocd was done initializing, openocd would report a speed different than it was actually outputting. The latest git tree does not contains the code your patch tries to remove. Regards, Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Get register value if it's invalid in cache
On Wed, May 18, 2011 at 1:17 AM, Øyvind Harboe oyvind.har...@zylin.com wrote: Are you still comfortable with this patch? Yes. I think this patch provides targets freedom to choose when and how to read registers. And it should not affect existing targets. Any objections? Anyone did any testing on other targets? I didn't test it on the existing targets. But I think it should not do any harm to them. Regards, Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Unusual ARM chip
Hi Alex, On Tue, May 17, 2011 at 8:11 PM, Austin, Alex alex.aus...@spectrumdsi.com wrote: I am attempting to use OpenOCD with a cellular chipset with an ARM11 and an ARM7+DSP core. I can access it with the Lauterbach debugger, but I find the interface very difficult to use and would prefer OpenOCD. It looks like some sort of TAP controller, perhaps like an OMAP3. Has anyone seen anything like this? Any idea how to get past it? Upon a scan, OpenOCD shows me: alex@msp-clx-aaustin:~$ openocd -f interface/jtagkey2.cfg -c jtag_khz\ 1 Open On-Chip Debugger 0.5.0-dev-00219-g737c9b6-dirty (2010-05-06-14:21) Licensed under GNU GPL v2 For bug reports, read http://openocd.berlios.de/doc/doxygen/bugs.html 1 kHz Info : max TCK change to: 3 kHz Info : clock speed 1 kHz Warn : There are no enabled taps. AUTO PROBING MIGHT NOT WORK!! Warn : AUTO auto0.tap - use jtag newtap auto0 tap -expected-id 0x30180083 ... Warn : AUTO auto0.tap - use ... -irlen 8 Warn : gdb services need one or more targets defined I'm just starting working on OpenOCD and not familiar with it, so I don't know if it has a command with similar functionality, but the detect command in UrJTAG might give you more information about the TAPs in your target if you have not tried it yet. After you know the TAPs in your target, you can create a config file for your target for OpenOCD. Regards, Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch] partial support for dsp568013/568037
Hi Rosa, On Tue, May 17, 2011 at 10:58 PM, Rodrigo Rosa rodrigorosa...@gmail.com wrote: - flashing speed: currently i flush the jtag queue all the time, to make coding easy. flashing 4KB currently takes about 45secs, which is not acceptable. the algorithm i'm running requires openocd to check a register (written by the core) to see if it can send more data. if i queue commands on jtag, how can i keep this working? won't all the commands get shifted into jtag and eventually clog the system? If you need to check status often, you will need to flush JTAG often, that will slowdown the speed if you are using a USB JTAG cable. The method I use for Blackfin target I'm working on now is to add some waiting cycles instead of checking the status. The key is to find the minimal number of the required cycles. You will need experiments to find it out. I also used that method for UrJTAG/gdbproxy Blackfin target. It works very well. Regards, Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Confusion about reset
In startup.tcl, ocd_process_reset_inner calls init_reset with the following comment: # Use TRST or TMS/TCK operations to reset all the tap controllers. # TAP reset events get reported; they might enable some taps. So it seems init_reset should only reset TAP controllers. After that, ocd_process_reset_inner continues to assert SRST and then deassert SRST. But in startup.tcl, init_reset calls jim_jtag_arp_init_reset in tcl.c. (I'm not familiar with jim. I'm not sure if I'm right.) jim_jtag_arp_init_reset calls jtag_init_reset in core.c, which will also do SRST reset if RESET_HAS_SRST. So when RESET_HAS_SRST, SRST reset is done twice in one call to ocd_process_reset_inner. Is it redundant? From the comments in the source code, it's not necessary to do SRST reset in init_reset. Correct? Regards, Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] Remove useless MIPS code in avr32_ap7k.c
This is an trivial patch. I found this when looking at AVR32 target code.
Jie
From 30dc90988489f91c5599ee5af515d0574d4f7577 Mon Sep 17 00:00:00 2001
From: Jie Zhang jie.zh...@analog.com
Date: Tue, 3 May 2011 14:43:22 -0400
Subject: [PATCH] Remove useless MIPS code in avr32_ap7k.c.
---
src/target/avr32_ap7k.c |4
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/src/target/avr32_ap7k.c b/src/target/avr32_ap7k.c
index 70e5129..afac664 100644
--- a/src/target/avr32_ap7k.c
+++ b/src/target/avr32_ap7k.c
@@ -110,7 +110,6 @@ int avr32_ap7k_restore_context(struct target *target)
static int avr32_read_core_reg(struct target *target, int num)
{
uint32_t reg_value;
- struct avr32_core_reg *mips_core_reg;
/* get pointers to arch-specific information */
struct avr32_ap7k_common *ap7k = target_to_ap7k(target);
@@ -118,7 +117,6 @@ static int avr32_read_core_reg(struct target *target, int num)
if ((num 0) || (num = AVR32NUMCOREREGS))
return ERROR_INVALID_ARGUMENTS;
- mips_core_reg = ap7k-core_cache-reg_list[num].arch_info;
reg_value = ap7k-core_regs[num];
buf_set_u32(ap7k-core_cache-reg_list[num].value, 0, 32, reg_value);
ap7k-core_cache-reg_list[num].valid = 1;
@@ -130,7 +128,6 @@ static int avr32_read_core_reg(struct target *target, int num)
static int avr32_write_core_reg(struct target *target, int num)
{
uint32_t reg_value;
- struct avr32_core_reg *mips_core_reg;
/* get pointers to arch-specific information */
struct avr32_ap7k_common *ap7k = target_to_ap7k(target);
@@ -139,7 +136,6 @@ static int avr32_write_core_reg(struct target *target, int num)
return ERROR_INVALID_ARGUMENTS;
reg_value = buf_get_u32(ap7k-core_cache-reg_list[num].value, 0, 32);
- mips_core_reg = ap7k-core_cache-reg_list[num].arch_info;
ap7k-core_regs[num] = reg_value;
LOG_DEBUG(write core reg %i value 0x% PRIx32 , num , reg_value);
ap7k-core_cache-reg_list[num].valid = 1;
--
1.7.2.5
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] Get register value if it's invalid in cache
Hi,
Currently OpenOCD assumes that all targets read and save all registers
in context when stop, and restore them when resume. But for the target
I'm working on, the cost is too high to do that. My target has about
50 registers. Saving and restoring them needs much time. Usually GDB
and users are only interested in several registers. So I don't want
OpenOCD to save and restore all registers for my target. Instead, I
hope OpenOCD reads/writes registers only when necessary. To achieve
this, OpenOCD will invalidate all registers when target stops. If
OpenOCD is asked for a register value but it's invalid, it will then
read the register from the hardware and put them in the cache. When
resume the target, OpenOCD will write all dirty cached registers back
to hardware.
handle_reg_command already checks if the register is valid in the
cache and calls reg-type-get() to read the register if it's invalid.
This patch makes gdb_get_registers_packet and gdb_get_register_packet
do the same thing.
This patch should not affect existing targets.
Regards,
Jie
From 4fddaa909ac705a8bd5777a7121164f9aa1309b6 Mon Sep 17 00:00:00 2001
From: Jie Zhang jie.zh...@analog.com
Date: Tue, 3 May 2011 14:35:40 -0400
Subject: [PATCH] Get register value if it's invalid in cache.
---
src/server/gdb_server.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/src/server/gdb_server.c b/src/server/gdb_server.c
index 9c1d245..b29ee4f 100644
--- a/src/server/gdb_server.c
+++ b/src/server/gdb_server.c
@@ -1064,6 +1064,8 @@ static int gdb_get_registers_packet(struct connection *connection,
for (i = 0; i reg_list_size; i++)
{
+ if (!reg_list[i]-valid)
+ reg_list[i]-type-get(reg_list[i]);
gdb_str_to_target(target, reg_packet_p, reg_list[i]);
reg_packet_p += DIV_ROUND_UP(reg_list[i]-size, 8) * 2;
}
@@ -1168,6 +1170,9 @@ static int gdb_get_register_packet(struct connection *connection,
exit(-1);
}
+ if (!reg_list[reg_num]-valid)
+ reg_list[reg_num]-type-get(reg_list[reg_num]);
+
reg_packet = malloc(DIV_ROUND_UP(reg_list[reg_num]-size, 8) * 2);
gdb_str_to_target(target, reg_packet, reg_list[reg_num]);
--
1.7.2.5
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Get register value if it's invalid in cache
Hi Øyvind, On Tue, May 3, 2011 at 3:30 PM, Øyvind Harboe oyvind.har...@zylin.com wrote: I would like to have this patch regression tested against ARM targets before I commit it. Could you or someone else help me regression test it on ARM targets? Is there any documentation about regression test? I may want to run regression test on my target. Thank you! Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Get register value if it's invalid in cache
On Tue, May 3, 2011 at 3:30 PM, Øyvind Harboe oyvind.har...@zylin.com wrote: Which target are you working on btw? I'm working on Blackfin. Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Remove useless MIPS code in avr32_ap7k.c
On Tue, May 3, 2011 at 4:03 PM, Øyvind Harboe oyvind.har...@zylin.com wrote: Merged. Thanks! Thank you! Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Get register value if it's invalid in cache
On Tue, May 3, 2011 at 4:05 PM, Øyvind Harboe oyvind.har...@zylin.com wrote: Start with a smoketest. Would this improve performance on ARM targets you think? I'm not familiar with ARM targets. So I'm not very sure. My guess is this can also improve performance on ARM targets but they needs be adapted to this lazy read usage. Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Get register value if it's invalid in cache
On Tue, May 3, 2011 at 4:18 PM, Mathias K. kes...@freenet.de wrote: I think gdb will get the register list and then, maybe depending on used debug application, all register values. This is true for recent GDB versions. Unfortunately, we are still using an old version, 6.6, which uses packet 'p' to read single register if it's supported by the gdb stub program. But we should remember that some/all functions in the current implementation, that need a target register to work, simple doesn't check if a register already stored or not. They only check if a target is halted or not. If target independent code doesn't check, I can help adding check to them. Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Get register value if it's invalid in cache
On Tue, May 3, 2011 at 4:48 PM, Mathias K. kes...@freenet.de wrote: Am 03.05.2011 22:12, schrieb Jie Zhang: I'm not familiar with ARM targets. So I'm not very sure. My guess is this can also improve performance on ARM targets but they needs be adapted to this lazy read usage. Your blackfin is fast enough. This read usage only affect you if you rape the step command with some register output to find a bug in your application/kernel/bootloader. It's time to buy a faster Jtag-Adapter. This is awesome! We have very fast jtag adapters. But I want to squeeze as much as I can from the hardware. Regards, Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Read register using GDB
Hi, I encountered an issue when using OpenOCD with GDB. After GDB connects to OpenOCD and halt the target, info reg command returns all zeros for all registers. I took a look at the related code and found that when GDB requests register values from OpenOCD, OpenOCD does not read register from target, instead it just calls target_get_gdb_reg_list to create a register list without initializing it with real register value, and then just returns them to GDB. Is it a bug or by design? Regards, Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Read register using GDB
Thank you for your reply! I'm adding a new target to OpenOCD. But I think all existing targets in OpenOCD have this issue. Maybe I missed something... Jie On Mon, May 2, 2011 at 12:13 PM, Mathias K. kes...@freenet.de wrote: Hello, please tell us more about your target platform. Regards, Mathias Am 02.05.2011 18:06, schrieb Jie Zhang: Hi, I encountered an issue when using OpenOCD with GDB. After GDB connects to OpenOCD and halt the target, info reg command returns all zeros for all registers. I took a look at the related code and found that when GDB requests register values from OpenOCD, OpenOCD does not read register from target, instead it just calls target_get_gdb_reg_list to create a register list without initializing it with real register value, and then just returns them to GDB. Is it a bug or by design? Regards, Jie ___ 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
Re: [Openocd-development] Read register using GDB
This solves my problem. Thank you! I have another related issue, but I will start a new thread. Jie On Mon, May 2, 2011 at 12:33 PM, Mathias K. kes...@freenet.de wrote: If you stop the target you should store the target context into the local register cache and if you resume the target you need to restore the context. This is why the target registers never read again if the target already halted. Am 02.05.2011 18:22, schrieb Jie Zhang: Thank you for your reply! I'm adding a new target to OpenOCD. But I think all existing targets in OpenOCD have this issue. Maybe I missed something... Jie On Mon, May 2, 2011 at 12:13 PM, Mathias K. kes...@freenet.de mailto: kes...@freenet.de wrote: Hello, please tell us more about your target platform. Regards, Mathias Am 02.05.2011 18:06, schrieb Jie Zhang: Hi, I encountered an issue when using OpenOCD with GDB. After GDB connects to OpenOCD and halt the target, info reg command returns all zeros for all registers. I took a look at the related code and found that when GDB requests register values from OpenOCD, OpenOCD does not read register from target, instead it just calls target_get_gdb_reg_list to create a register list without initializing it with real register value, and then just returns them to GDB. Is it a bug or by design? Regards, Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de mailto: 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] Why not default halt the target when GDB connects to OpenOCD?
When GDB connects to OpenOCD, OpenOCD does not halt the target by default. To halt the target, users have to add halt to gdb-attach event hook in target configuration file or type the command monitor halt from GDB command line interface. The latter method caused some confusion for me. Since OpenOCD does not halt the target when GDB connects, it will return all zeros when GDB asks for register value. GDB cached such value internally. Then I typed monitor halt in GDB, OpenOCD halts the target. But when I ask GDB about the register value of the target, GDB still returns the cached all zeros to me without retrieving them again. This bacause GDB has no idea that the target is still running when it connects to OpenOCD and the target is halted by monitor halt. To get meaningful register values, I have to continue and ^C in GDB to cause GDB to retrieve register values again. Then my question is why not just halt the target when GDB connects to OpenOCD? In this way, GDB will get the correct register information when it connects to OpenOCD and show the correct stop address. Regards Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Why not default halt the target when GDB connects to OpenOCD?
On Mon, May 2, 2011 at 3:31 PM, Øyvind Harboe oyvind.har...@zylin.com wrote: Short story: creates other nasty problems. You can easily add a monitor halt + stepi to your gdb init sequence. Thank you for your reply. But what are the other nasty problems? Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Read register using GDB
On Mon, May 2, 2011 at 3:35 PM, Øyvind Harboe oyvind.har...@zylin.com wrote: After connecting GDB to OpenOCD, you need to issue a stepi to sync GDB and OpenOCD. This is not documented in the manual. The advantage of this approach is (amongst many other things) that attaching to the target does *nothing*. Via monitor commands, you can easily manipulate the target, e.g. issuing a monitor halt. I would say that this is confusing for a new user, like me, since it's different to the normal usage model of GDB. For example, when GDB attaches to a user application, it's expected that the application will be stopped. What are the other advantages? If they are important, we can consider changing GDB not to expect target halted when it connects to OpenOCD. Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Why not default halt the target when GDB connects to OpenOCD?
On Mon, May 2, 2011 at 3:52 PM, Michael Trensch mtren...@googlemail.com wrote: I often use openOCD and GDB/Insight to attach to a running target that I don't want to halt, or even cannot halt it during my debugging session. I just want to take to see the call stack and program counter when it crashes or when it reaches a special code line. I think you can still connect to the target to look at the call stack and PC after it crashes. When I want to look at the call stack and PC at a special code line, I usually set a breakpoint from GDB, that will requires to halt the target first. It's not a good idea to force everyone to halt their target when connecting, when there is the possibility to script this behavior. It might be your case that you want to halt it, but some other may not want that. Yes, it won't be a good idea to force everyone to halt their target if they usually don't. But it will also not be a good idea if people manually halt their target in most cases. GDB expects the target to be stopped when it connects to the target. But OpenOCD has this feature for several years, I think there must be some reasons. I'm trying to understand them. In your case I think it would be the best to write a gdb-attach event in your script and you can do whatever you want, like resetting the CPU, blink LED's in this script. This is what I'm currently doing. But I'm not sure if it's the correct thing to do since most of the board config files have reset init for their gdb-attach event, not halt, except u8500.cfg. Regards, Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
