Re: [ECOS] Tracing and Debug

Re: [ECOS] Tracing and Debug

[Jonathan Larmour]

[ 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

Re: [ECOS] Tracing and Debug

[Jesper Skov]

>>>>> "Jonathan" == Jonathan Larmour <jlarmour@redhat.com> writes:

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

I guess we should put something in place to at least warn about this
conflict. The below contains the logic:

     cdl_option CYGNUM_HAL_VIRTUAL_VECTOR_DEBUG_CHANNEL {
        display          "Debug serial port"
        flavor data
        legal_values     0 to CYGNUM_HAL_VIRTUAL_VECTOR_COMM_CHANNELS-1
        default_value    0
        requires         !( ((CYGNUM_HAL_VIRTUAL_VECTOR_DEBUG_CHANNEL==0 &&\
                              CYGPKG_IO_SERIAL_ARM_PID_SERIAL0) || \
                             (CYGNUM_HAL_VIRTUAL_VECTOR_DEBUG_CHANNEL==1 &&\
                              CYGPKG_IO_SERIAL_ARM_PID_SERIAL1)) && \
                            (CYGDBG_HAL_DEBUG_GDB_CTRLC_SUPPORT || \
                             CYGDBG_HAL_DEBUG_GDB_BREAK_SUPPORT))
        description      "
            The PID board has only one serial port. This option
            chooses which port will be used to connect to a host
            running GDB."
     }


But:

 o It's rather nasty to look at
 o The warning/error would appear at the wrong location - it really
   belongs in the common HAL with the CTRLC/BREAK options.

Maybe it could be done with interfaces.

Jesper

RE: [ECOS] Tracing and Debug

[Fabrice Gautier]

> From: Jonathan Larmour [ mailto:jlarmour@redhat.co.uk ]
> Subject: Re: [ECOS] Tracing and Debug
> 
> [ Please remember to CC the list. I don't do one-to-one 
> support for free
> :-) ]

[Oups! sorry...] 

> Fabrice Gautier wrote:
> > 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.

Hum... 

So I shouldn't have HAL/diag serial device driver
enabled(CYGPKG_IO_SERIAL_HALDIAG) when i include the GDB stubs in HAL with
GDB external break support (CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS and
CYGDBG_HAL_DEBUG_GDB_BREAK_SUPPORT) ? 

But I don't see why the problem only occurs when I enable tracing? I seemed
to run fine before.  

I'm not sure I get the whole picture about the way the GDB, the GDB stub and
ecos manage the serial port.

But I understand that if I remove the HAL/diag serial driver I can't use the
standard IO functions in the C lib (CYGPKG_LIBC_STDIO require
CYGPKG_IO_SERIAL_HALDIAG) . So it should not be possible to use the same
serial port for both the eCos diag output and GDB stuf ?? But in the default
configuration of the ARM PID BOARD the Diagnostic Serial Port and the GDB
Serial Port are both set to 0. 

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

I'm not sure, it worked fine without tracing...

(I will check again for the other building problem - and perhaps will try
the cvs stuff once I found any good cvs tool for Windows)

Thanks

A+
-- 
Fabrice Gautier
fabrice_gautier@sdesigns.com 

Re: [ECOS] Tracing and Debug

[Jonathan Larmour]

Fabrice Gautier wrote:
> 
> > From: Jonathan Larmour [ mailto:jlarmour@redhat.co.uk ]
> > Fabrice Gautier wrote:
> > > 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.
> 
> Hum...
> 
> So I shouldn't have HAL/diag serial device driver
> enabled(CYGPKG_IO_SERIAL_HALDIAG) when i include the GDB stubs in HAL with
> GDB external break support (CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS and
> CYGDBG_HAL_DEBUG_GDB_BREAK_SUPPORT) ?

No, that HALDIAG driver should be enabled. But from the mention of
/dev/ser0 above, this indicates you have the "real" serial driver enabled,
and that is what conflicts with break support, i.e.
CYGPKG_IO_SERIAL_ARM_PID and CYGPKG_IO_SERIAL_ARM_PID_SERIAL0.

> But I don't see why the problem only occurs when I enable tracing? I seemed
> to run fine before.

It wasn't tracing that exposed this - it was assertions, which is default
enabled when tracing is enabled (although you can disable it).
 
> (I will check again for the other building problem - and perhaps will try
> the cvs stuff once I found any good cvs tool for Windows)

Don't forget to look at the links referenced from
http://sources.redhat.com/ecos/anoncvs.html if you haven't already.

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

[ECOS] Tracing and Debug

[Fabrice Gautier]

Hi,

I have some problems with tracing. I'm using a ARM PID board.

1/ I first build ecos with Asserts & Tracing and Buffered Tracing. I have
also enabled Source Level Debugging Support with external break and
multithreading to work with the GDB Stub.

I can build the examples fine when running them in the debuugger, there is
some tracing output and then gdb stay busy. When I try to interrupt the
program, I receive a message like "target not responding". I had the same
message before I enabled external break support.


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


Thanks 

-- 
Fabrice Gautier
fabrice_gautier@sdesigns.com 

Re: [ECOS] Tracing and Debug

[Jonathan Larmour]

Fabrice Gautier wrote:
> 
> Hi,
> 
> I have some problems with tracing. I'm using a ARM PID board.
> 
> 1/ I first build ecos with Asserts & Tracing and Buffered Tracing. I have
> also enabled Source Level Debugging Support with external break and
> multithreading to work with the GDB Stub.
> 
> I can build the examples fine when running them in the debuugger, there is
> some tracing output and then gdb stay busy. When I try to interrupt the
> program, I receive a message like "target not responding". I had the same
> message before I enabled external break support.

Does this happen even for the hello world example? All I can say is that it
works for me with the sources currently in anonymous CVS.
 
murgh:~/ecc/obj/arm/pid/examples$ arm-elf-gdb -b 38400 -nw hello
GNU gdb 4.18-ecos-99r1-991015
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.  This version of GDB is
supported
for customers of Cygnus Solutions.  Type "show warranty" for details.
This GDB was configured as "--host=i686-pc-linux-gnu --target=arm-elf"...
(gdb) tar rem /dev/ttyS0
Remote debugging using /dev/ttyS0
0x4000694 in ?? ()
(gdb) load
Loading section .rom_vectors, size 0x44 lma 0x8000
Loading section .text, size 0xdc34 lma 0x8044
Loading section .rodata, size 0x480 lma 0x15c78
Loading section .data, size 0x354 lma 0x160f8
Start address 0x8044 , load size 58444
Transfer rate: 22264 bits/sec.
(gdb) c
Continuing.
Hello, eCos world!
 
Program received signal SIGINT, Interrupt.
idle_thread_main (data=391828)
    at /home/jlarmour/ecc/ecc/kernel/current/src/common/thread.cxx:1134
1134            idle_thread_loops++;
Current language:  auto; currently c++
(gdb)

When you say you enabled "Source level debugging support" you meant
"Include GDB stubs in HAL", right? If not, then that's probably what you
need to do :-).

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.

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

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