This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Any developments in thread-aware JTAG debugging?


On 2008-10-08, Jonathan Larmour <jifl@eCosCentric.com> wrote:
> Grant Edwards wrote:

>> The last time I checked, thread-aware debugging was only
>> available via the gdb-stubs in RedBoot and not via any of the
>> JTAG interfaces.
>> 
>> Is that still the case?
>> 
>> [I'm primarily interested in ARM and NIOS2 targets.]
>
> The Lauterbach debugger has something which passes for it,
> although I'm a bit sceptical of whether it's adaptable to some
> particular kernel configurations. Possibly unwarranted.
>
> eCos still has extensions to allow use of the ARM Multi-ICE
> (if you can still find one!). http://ecos.sourceware.org/multi-ice.html

Is that the one with the combination serial/parallel interface?
If so, I actually do know where I can find one.  It even worked
the last time I tried it (which, admittedly, was probably 8-9
years ago).

> It's probably only a matter of time before someone does
> something with openocd, probably involving the qSymbol remote
> protocol packet.

Since there are some cute (and cheap) little USB-JTAG adapters
supported by openOCD, it would be cool if openOCD did support
some fancy features like that.

Maybe an eCos-aware daemon that sits betwen openocd (or any
other gdb server) and gdb?

> I have been known to do horrible things with the output of (if I remember 
> right) something like for example: 
> *(*Cyg_Scheduler_Base::current_thread)->list_next->list_next->saved_context

Yea, I've messed with things like that too.  I convinced myself
that a) you could theoretically do some useful stuff, and b) I
couldn't keep track of enough things in my head to do so in
practice.

> For extra points, you then set $sp and $pc (and possibly any
> frame pointer or other necessary registers) in GDB to the
> values in that context and you can do a backtrace. Remember to
> put them back before you continue though :-).
>
> Oh yes, I've had to debug hard problems :-).
>
> It might be possible to do this in a GDB macro, but I haven't
> tried - not sure GDB's macro language is up to it.

Too bad gdb isn't scriptable in Python or Lua or Guile.  OTOH,
I was reading a description of debugging using gdb under
uClinux, and apparently all you had to do was tell gdb the base
address of the task table.  Apparently the Linux kernel's task
table format is known a-priori by gdb.  I thought there might
something similar for eCos.


-- 
Grant



-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]