Re: [ECOS] Tracing and Debug

[Jonathan Larmour <jlarmour@redhat.co.uk>]

[ Please remember to CC the list. I don't do one-to-one support for free
:-) ]

Fabrice Gautier wrote:
> 
> > (gdb) c
> > Continuing.
> > Hello, eCos world!
> 
> ?? Where is the Trace Output?

There was no trace output because I was using buffered tracing and
everything worked fine.
 
> Here is a part of my output after typing 'c':
> 
> ------
> Init device '/dev/ttydiag'
> Init tty channel: 27E6C
> Init device '/dev/haldiag'
> HAL/diag SERIAL init
> Init device '/dev/ser0'
> Set output buffer - buf: 296C4 len: 512
> Set input buffer - buf: 298C4 len: 512
> ASSERT FAIL: <1>intr.cxx            [ 426] void Cyg_Interrupt::attach()
> Interrupt vector not free.

And here is your problem. The serial drivers have been enabled, but this is
conflicting with the external break support because both want to put
interrupt handlers on the serial line. You cannot have both.

Admittedly, it shouldn't have been possible to do this without the
configuration whinging at you.

Jesper/Gary, do we have any CDL now that should prevent this? I can't find
any, but I didn't get the assertion above when I tried it so is there some
other mechanism? I suspect the platform CDL for the debug serial port (now
CYGNUM_HAL_VIRTUAL_VECTOR_DEBUG_CHANNEL in the new world) should require
!CYGDBG_HAL_DEBUG_GDB_CTRLC_SUPPORT && !CYGDBG_HAL_DEBUG_GDB_BREAK_SUPPORT

What do you two think? Presumably this should be done for all platforms
(erk!). I don't have the time to fix this so if either of you don't either,
I'll probably just submit a CR. Let me know.

> > But for me it works in the default configuration anyway -
> > i.e. without GDB
> > stubs included, but using GDB external break support when no
> > stubs. But as
> > I said, my sources correspond to the anonymous CVS repository.
> 
> With the default configuration + tracing enabled I don't have any tracing
> output, nor I have threads support, nor I can interrupt the program with
> GDB.

It's definitely working in anon CVS, but a lot has been changing in that
area recently admittedly.
 
> > > 2/ I tried the same config without the Buffered Tracing: In
> > > this case the
> > > examples programs don't build : lots of undefined references to
> > > cyg_assert_fail, cyg_tracemsg, cyg_tracemsg2 and so on....
> >
> > You probably forget to recompile the example programs
> > themselves rather
> > than just relink them (at a guess). Do a "make clean ; make" instead.
> 
> Nop, I checked twice, and I did the clean. I fact I cleaned both the ecos
> build and the example build. I checked the .ecc files and they seemed
> correct. I even tried with default config + tracing (not buffered) and there
> is the same unresolved symbols problems.

In the eCos build tree, do a "make clean" *and* then delete everything in
the install/lib subdirectory.
 
> I may have something wrong in the tracing configuration. But there is
> something that sound strange to me: There are three trace ouput modules
> (Null, Simple and Fancy) but we can choose none of these or the three and
> the config tools doesn't complain while it seemed to me we should choose One
> and one only. Same thing for behaviour of the trace buffer when it is full:
> there are the Wrap, Halt and Print options that can be all cheched without
> conflict.
> Is this normal ?

It's an oversight in the CDL (and there are even FIXMEs in there). Care to
submit a patch? It should be reworked with CDL interfaces really.

Jifl
-- 
Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS  Tel: +44 (1223) 728762
"Plan to be spontaneous tomorrow."  ||  These opinions are all my own fault