Re: [ECOS] Running/building ecosconfig on latest Cygwin

[Bart Veer <bartv at ecoscentric dot com>]

>>>>> "Drew" == Moseley, Drew <drew.moseley@intel.com> writes:

    Drew> Just any default config that include hal_verde.cdl; eg
    Drew> "ecosconfig new iq80321"

    Drew> When run with the snapshotted version, ecos.ecc is created
    Drew> just fine. When run with my recently built version, no
    Drew> ecos.ecc file is created.

    Drew> At one point I inserted some debug code into ecosconfig and
    Drew> confirmed that it is a divide-by-zero but I was unable to
    Drew> determine when or why the value was being set to zero.

Initial investigation suggests this is a problem with cygwin/g++
rather than with libcdl. The issue arises with

        cdl_option CYGNUM_HAL_RTC_PERIOD {
            default_value 1000000/CYGNUM_HAL_RTC_DENOMINATOR
        }

It so happens that libcdl is evaluating the default_value for
CYGNUM_HAL_RTC_PERIOD before that of CYGNUM_HAL_RTC_DENOMINATOR. Hence
the value lookup code returns 0 for DENOMINATOR and the expression
evaluation code throws a C++ exception for an illegal expression. This
should get caught a bit higher up in the call chain and the property
marked accordingly. Then later on DENOMINATOR's default_value gets
evaluated, causing CYGNUM_HAL_RTC_PERIOD's default_value expression to
be marked as in need of an update. The second time around the
expression evaluates fine and everything is happy.

Granted, the current behaviour is not quite optimal. Expressions could
be sorted in various ways to avoid unnecessary reevaluations. But
typical configurations are not complicated enough to make that sort of
thing worthwhile,  The simple approach generally works fine.

Unfortunately throwing the C++ exception causes things to go wrong.
The backtrace is somewhat bogus. I can see apparently valid stack
frames for __cxa_throw(), check_exception_spec(), globals_key(), and
then it ends up in the cygwin pthread support code before SEGV'ing. I
do not know enough about cygwin or g++ exception internals to debug
this, and unfortunately I have not managed to produce a simple
testcase. You may want to ask on an appropriate cygwin list whether
there any known issues with C++ exceptions using the current
combination of g++ and cygwin.

Bart

-- 
Bart Veer                       eCos Configuration Architect
http://www.ecoscentric.com/     The eCos and RedBoot experts


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss