Thread awareness with eCos problem

Thread awareness with eCos problem

[Stanislav Meduna]

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

Re: [OpenOCD-devel] Thread awareness with eCos problem

[Paul Fertser]

Hi,

On Sat, May 19, 2012 at 02:50:30PM +0200, Stanislav Meduna wrote:
> (it depends on what symbols the OpenOCD has an access to),

Basically, if you can load the elf file in gdb and you can "print" the
needed variable, then OpenOCD has access to it too (because it
basically asks gdb for the offset of a variable it needs).

HTH
-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercerpav@gmail.com

Re: [OpenOCD-devel] Thread awareness with eCos problem

[Stanislav Meduna]

On 19.05.2012 16:49, Paul Fertser wrote:

> Basically, if you can load the elf file in gdb and you can "print" the
> needed variable, then OpenOCD has access to it too (because it
> basically asks gdb for the offset of a variable it needs).

Hm, correct me if I'm wrong: I investigated a bit and I'm afraid
that the OpenOCD has an easy access to symbols, but the symbols
won't help me to get an offset of a field in a structure. One
would need either to also get the debug info into OpenOCD or
a way to ask the gdb to evaluate a command, which is not supported
and the idea was frowned upon some time ago - see the thread
at http://sourceware.org/ml/gdb/2008-10/msg00011.html


eCos folks: would it be an idea to add a few extra symbols
to the scheduler exporting the neded information for
the OpenOCD? I'm probably going to implement it anyway, but
it would be nice to get the patches accepted into both eCos
and OpenOCD.


Regards
-- 
                                    Stano

Re: [OpenOCD-devel] Thread awareness with eCos problem

[Paul Fertser]

Hi,

On Mon, May 28, 2012 at 05:04:54PM +0200, Stanislav Meduna wrote:
> On 19.05.2012 16:49, Paul Fertser wrote:
> > Basically, if you can load the elf file in gdb and you can "print" the
> > needed variable, then OpenOCD has access to it too (because it
> > basically asks gdb for the offset of a variable it needs).
> 
> Hm, correct me if I'm wrong: I investigated a bit and I'm afraid
> that the OpenOCD has an easy access to symbols, but the symbols
> won't help me to get an offset of a field in a structure.

So true :( a field of a structure is not a symbol ("variable") indeed,
i haven't thought about it enough when i was answering, sorry.

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercerpav@gmail.com