From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5234 invoked by alias); 19 May 2012 12:51:04 -0000 Received: (qmail 5224 invoked by uid 22791); 19 May 2012 12:51:03 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from www.meduna.org (HELO meduna.org) (92.240.244.38) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 19 May 2012 12:50:45 +0000 Received: from dial-95-105-165-4-orange.orange.sk ([95.105.165.4] helo=[192.168.130.22]) by meduna.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1SVj7E-0003kq-0M; Sat, 19 May 2012 14:50:44 +0200 Message-ID: <4FB79716.9030101@meduna.org> Date: Sat, 19 May 2012 12:51:00 -0000 From: Stanislav Meduna User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: openocd-devel@lists.sourceforge.net CC: ecos-devel@ecos.sourceware.org Subject: Thread awareness with eCos problem Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Authenticated-User: stano@meduna.org X-Authenticator: dovecot_plain X-Spam-Score: -6.9 X-Spam-Score-Int: -68 X-Exim-Version: 4.72 (build at 12-May-2011 18:13:45) X-Date: 2012-05-19 14:50:44 X-Connected-IP: 95.105.165.4:50769 X-Message-Linecount: 57 X-Body-Linecount: 45 X-Message-Size: 1913 X-Body-Size: 1459 X-Received-Count: 1 X-Recipient-Count: 2 X-Local-Recipient-Count: 2 X-Local-Recipient-Defer-Count: 0 X-Local-Recipient-Fail-Count: 0 X-IsSubscribed: yes Mailing-List: contact ecos-devel-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-devel-owner@ecos.sourceware.org X-SW-Source: 2012-05/txt/msg00002.txt.bz2 Hi everybody, I'm afraid the current method of thread awareness for eCos cannot reliably work as implemented. The eCos_params_list in src/rtos/eCos.c contains fixed offsets for a few fields. const struct eCos_params eCos_params_list[] = { { "cortex_m3", /* target_name */ 4, /* pointer_width; */ 0x0c, /* thread_stack_offset; */ 0x9c, /* thread_name_offset; */ 0x3c, /* thread_state_offset; */ 0xa0, /* thread_next_offset */ 0x4c, /* thread_uniqueid_offset */ &rtos_eCos_Cortex_M3_stacking /* stacking_info */ } }; However, eCos is extensively configurable and the definition of the thread structure has quite a few of #ifdefs that enable or disable various structure members. I am not really an expert in OpenOCD internals - I just looked into the source trying to find why it does not work for me. I am not sure the following proposal is possible (it depends on what symbols the OpenOCD has an access to), but I'd say the correct way to implement the thread awareness would be to dynamically determine the offsets. I.e. to make an equivalent of (gdb) p /x (char *) &(Cyg_Scheduler_Base::current_thread[0]->unique_id) - (char *) Cyg_Scheduler_Base::current_thread[0] $21 = 0x58 In case this is not possible there has to be a way to specify the offsets from a configuration file. Best regards and thanks for a great software -- Stano