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: Re: Any developments in thread-aware JTAG debugging?


Grant Edwards wrote:
> On 2008-10-08, Jonathan Larmour <jifl@eCosCentric.com> wrote:
> 
>>>> 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 so long ago I've now forgotten! I definitely remember
>> using it with a parallel interface, but that doesn't mean it
>> may not have been serial too.
> 
> IIRC, the parallel port was unidirectional (host->ICE).  You
> could write commands (and more importantly download records) to
> the parallel port, but you had to read responses from the
> serial port.

Hmm, that doesn't sound familiar. Maybe that was the EmbeddedICE rather
than the MultiICE? I never used the former, only the latter.

>>> Maybe an eCos-aware daemon that sits betwen openocd (or any
>>> other gdb server) and gdb?
>> I've advocated doing something like that in the past.
> 
> Just like gdb's process table support, such a daemon would
> depend on the eCos kernel's thread data structures being
> well-defined.  If you can't count on the data structures being
> known, then a daemon isn't going to be any more feasible than
> building support into gdb itself.

That's where qSymbol can come in. You can put all sorts of stuff in the
symbol table; or use a specially named structure with well-defined symbol
name, and be able to get needed information (such as field offsets) from
within that (not all that painful since such a table would be constant and
could therefore live in ROM); or, like the multi-ICE and V850-ICE support,
play special tricks allowing the target to run and stop so that it does all
the querying itself.

>> Not feasibly - the eCos internal thread structures are 
>> configuration-dependent and thus mutable. On the other hand,
>> it's possible to set up a different sort of data structure
>> which would never change.
> 
> If eCos won't provide some sort of stable process table
> structures for debuggers to use, then providing thread-aware
> debugging is going to continue to be pretty tough regardless of
> whether it's in a separate daemon or integrated into gdb.

It's also been advocated to patch GDB itself, since it also has access to
the full debug data, including direct access to various thread fields etc.
 In the same way as the Lauterbach does.

Jifl
-- 
eCosCentric Limited      http://www.eCosCentric.com/     The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.       Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
------["Si fractum non sit, noli id reficere"]------       Opinions==mine

-- 
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]