This is the mail archive of the ecos-discuss@sources.redhat.com 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: A couple of CDL questions...


> We have both CTRLC and BREAK because of the way things used to work
> before (like, in the 1.2.1 days). Ideally, I'd rewrite the few HALs that
> still differentiate between these two configuration options, and flush
> one of them from the tree. But there never seems to be time enough...
>
OK, now I am very confused.  What is the difference between
CYGDBG_HAL_DEBUG_GDB_BREAK_SUPPORT and CYGDBG_HAL_DEBUG_GDB_CTRLC_SUPPORT?

Until your most recent email, I thought the following:

CTRLC_SUPPORT causes an application configured to run with a ROM monitor to
drop into the ROM monitor upon detection of ^C (assuming the ROM monitor
supported that).  I could build my application with or without ^C support,
but the default is to build it with ^C support if the ROM monitor supports
it.

If I build an application (including a ROM monitor application) with
GDB_STUBS included in it, then BREAK_SUPPORT controls whether or not ^C
drops into "communicate with a remote GDB" mode.

If I build an application with GDB_STUBS included in it and BREAK_SUPPORT
_disabled_, then I could enable CTRLC_SUPPORT (according to the CDL), but it
is unclear to me what this would accomplish.  Why does the CDL support this
and what does it mean?

Hmmm... is that one of those backwards compatibility things that those "few
HALS" still depend on?  I'll admit I have only been looking at the PowerPC
HALs when I have been sorting through this.  Perhaps they are new enough
that I wouldn't find a reason for the CDL to support this.

Regardless, if my understanding of the difference betweeen CTRLC_SUPPORT and
BREAK_SUPPORT is correct, it seems to me that you wouldn't want to flush one
of them from the tree, as they provide support for different (but related)
features.

>
> > Shouldn't it be possible to build a
> > useful RedBoot with xyzmodem, TCP/IP, etc... that didn't
> include GDB stubs?
>
> RedBoot was a replacement for stubs, so it was "born" with stubs (the
> requirement being a way to make libcdl enable the stubs). Nothing would
> prevent you from making some adjustments to RedBoot so it could be built
> without stubs. It's just not been a priority, is all.
>
OK, I see.  I have no use for such a feature right now, I was just trying to
understand the reasoning behind the CDL.  I suppose if I needed such a
feature, I would have to either patch redboot.cdl (and, possibly all of the
.ecm files to ensure that GDB_STUBS was included in all the configurations)
or I would have to define a new platform that didn't claim to implement
GDB_STUBS.  That makes sense.  Thanks.

--wpd


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