headers
Stanislav Meduna | 18 May 2012 23:15
Favicon

OpenOCD, Cortex-M3 and threads - any success?

Hi,

anyone has any success with the eCos thread support in OpenOCD?

I am using the current snapshot of OpenOCD with -rtos auto,
a TI Stellaris Cortex-M3 processor and a gdb 7.4.
This combination is able to successfully detect the eCos
but then probably tries to access invalid memory
and is not able to show the threads.

Setting CYGDBG_HAL/KERNEL_DEBUG_GDB_THREAD_SUPPORT
has no effect.

The OpenOCD shows

Open On-Chip Debugger 0.6.0-dev-00571-g0644754 (2012-05-18-10:41)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
3000 kHz
Info : clock speed 3000 kHz
Info : JTAG tap: lm3s9b9x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b,
part: 0xba00, ver: 0x4)
Info : lm3s9b9x.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : accepting 'gdb' connection from 3333
Warn : acknowledgment received, but no packet pending
undefined debug reason 6 - target needs reset
Auto-detected RTOS: eCos
Error: JTAG-DP STICKY ERROR
(Continue reading)

Permalink | Reply | 1 comment |
headers
Stanislav Meduna | 19 May 2012 14:25
Favicon

Re: OpenOCD, Cortex-M3 and threads - any success?

On 18.05.2012 23:15, Stanislav Meduna wrote:

> anyone has any success with the eCos thread support in OpenOCD?

OK.. this can't work. OpenOCD uses fixed offsets in the
Cyg_Thread structure for its magic. With eCos the exact
offsets of course depend on configuration offsets used.

I'll report the issue to the OpenOCD list - this approach
is plain wrong.

Regards
--

-- 
                                  Stano
Permalink | Reply | 0 comments |
headers
Stanislav Meduna | 19 May 2012 14:50
Favicon

Thread awareness with eCos problem

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
(Continue reading)

Permalink | Reply | 3 comments |
headers
Paul Fertser | 19 May 2012 16:49
Picon

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

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 <at> gmail.com
Permalink | Reply | 2 comments |
headers
Stanislav Meduna | 28 May 2012 17:04
Favicon

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

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
Permalink | Reply | 1 comment |
headers
Paul Fertser | 28 May 2012 17:55
Picon

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

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 <at> gmail.com
Permalink | Reply | 0 comments |
headers
Bernard Fouché | 31 May 2012 10:37
Favicon

eCos GNU tools 4.6.3-20120315 and link time optimization

Hi,

I did some testing of 4.6.3 on my Cortex-M3 LPC1765 based app, using the 
eCos CVS repo code.

I use -Os and my goal is to reduce the code size:

4.3.2: 153172 bytes
4.6.3: 144556 bytes
4.6.3, app only compiled with -flto: 136404 bytes

The improvement is significant and the app still works ;-)

However I wasn't able to link with eCos compiled with -flto and 
-Wl,--allow-multiple-definition, the linker fails with:
target.a: could not read symbols: Bad value

I could link adding '-fno-use-linker-plugin' but then I'm back to 144028 
bytes!

Did anyone succeeded in compiling/linking an application and eCos with 
-flto??

Thanks,

      Bernard
Permalink | Reply | 0 comments |

Gmane