[ECOS] A couple of CDL questions...

["Patrick Doyle" <wpd at delcomsys dot com>]

1) in debugging.cdl, the stanza for CYGDBG_HAL_DEBUG_GDB_CTRLC_SUPPORT
reads:

cdl_option CYGDBG_HAL_DEBUG_GDB_CTRLC_SUPPORT {
    display       "Include GDB external break support when no stubs"
    requires      !CYGDBG_HAL_DEBUG_GDB_BREAK_SUPPORT
    active_if     { CYGSEM_HAL_USE_ROM_MONITOR ||
CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS }
    active_if     { CYGINT_HAL_DEBUG_GDB_CTRLC_UNSUPPORTED == 0 }
    default_value { !CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS }
...

This says to me that CTRLC support is active if we are using a ROM monitor
(and the ROM monitor supports CTRLC).  By default, CTRLC support in my eCos
application is enabled, but I can disable it if I want.

That all makes sense.

Now, I am trying to figure out what the !CYGDBG_HAL_DEBUG_GDB_BREAK_SUPPORT
and
|| CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS parts are trying to accomplish.  This
seems to say to me that, if we build an application that includes GDB stubs
in it, and if, for whatever reason, we disable BREAK support in the stubs
part, we can still enable CTRLC support in the application part.  When I
search through the code, I see that, whereever CTRLC is supported, BREAK is
supported as well, but there are a bunch of pieces of the stub code that are
disabled when BREAK is not supported.

So, I am curious... why would I ever want to include GDB stubs without BREAK
support in an application that had CTRLC support?  It feels like that
wouldn't work, but the CDL goes through some specific contortions to make it
possible.

2) And for my second question... :-)
in redboot.cdl, we have:

cdl_component CYGBLD_BUILD_REDBOOT {
    display "Build Redboot ROM ELF image"
    default_value 0
    requires CYGPKG_INFRA
    requires CYGPKG_ISOINFRA
# Someday the tools will handle this
#    requires { CYGINT_HAL_DEBUG_GDB_STUBS implies
CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS }
#    requires { CYGINT_HAL_DEBUG_GDB_STUBS implies
CYGDBG_HAL_DEBUG_GDB_BREAK_SUPPORT }
#
    requires { !CYGINT_HAL_DEBUG_GDB_STUBS ||
CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS }
    requires { !CYGINT_HAL_DEBUG_GDB_STUBS ||
CYGDBG_HAL_DEBUG_GDB_BREAK_SUPPORT }
#
...
This says to me that RedBoot requires that, if the platform supports GDB
stubs, then GDB stubs _must_ be included in RedBoot and that the platform
_must_ support BREAK.  Once again, it makes sense to me that, if the
platform supports GDB stubs, RedBoot would require that it support a flavor
with BREAK support, but why is it required that GDB stubs be included just
because the platform supports it?  Shouldn't it be possible to build a
useful RedBoot with xyzmodem, TCP/IP, etc... that didn't include GDB stubs?

There is an easy answer to this question... modify redboot.cdl and try it!
So, I tried the easy answer, and found that one of the files in the i386
architecture didn't build with that combination of options, but that the
PowerPC mbx platform did.

Mainly, I am curious about the rationale behind this.  It is not getting in
the way, I am just curious why a RedBoot requires that a platformt that
supports GDB stubs requires that GDB stubs be included.

--wpd