This is the mail archive of the ecos-devel@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]

virtual vectors problem


There is a problem with the current virtual vectors code and there are
two obvious ways of resolving it. I have a personal preference, but
some people may disagree.

In hal/common/current/src/hal_if.c we have the following code:

    //----------------------------------
    // Cache functions
    #ifdef CYGSEM_HAL_VIRTUAL_VECTOR_CLAIM_CACHE
    
    static void
    flush_icache(void *__p, int __nbytes)
    {
        CYGARC_HAL_SAVE_GP();
    #ifdef HAL_ICACHE_FLUSH
        HAL_ICACHE_FLUSH( __p , __nbytes );
    #elif defined(HAL_ICACHE_INVALIDATE)
        HAL_ICACHE_INVALIDATE();
    #endif
        CYGARC_HAL_RESTORE_GP();
    }
    
    static void
    flush_dcache(void *__p, int __nbytes)
    {
        CYGARC_HAL_SAVE_GP();
    #ifdef HAL_DCACHE_FLUSH
        HAL_DCACHE_FLUSH( __p , __nbytes );
    #elif defined(HAL_DCACHE_INVALIDATE)
        HAL_DCACHE_INVALIDATE();
    #endif
        CYGARC_HAL_RESTORE_GP();
    }
    #endif

These functions are the default implementations of the virtual vector
macros CYGACC_CALL_IF_FLUSH_ICACHE() and
CYGACC_CALL_IF_FLUSH_ICACHE(). Superficially this code might look
reasonable but actually it is completely bogus. HAL_ICACHE_FLUSH() is
not one of the standard cache macros. HAL_ICACHE_INVALIDATE() and
HAL_DCACHE_INVALIDATE() take base/length arguments. It would appear
that this code has never actual been compiled.

The reason why this has not been a problem before is that hal_if.c
does not #include <cyg/hal/hal_cache.h>, explicitly or implicitly.
Hence none of the cache macros are ever defined while compiling this
file, and the flush functions are always no-ops. I discovered this
recently while doing a processor port where hal_intr.h needed
hal_cache.h, and suddenly some of the macros were defined but this
code invoked them with the wrong number of arguments.

There are two obvious ways of fixing this situation. The first is to
make the functions work, requiring some very simple changes. The
second is to get rid of them completely. There is no eCos code which
uses these virtual vector calls, and any such code would be better off
#include'ing hal_cache.h and invoking the proper HAL macros directly.
The only problem is if there is any non-eCos code, e.g. something in
the libgloss/newlib world, that sits on top of RedBoot and expects
these virtual vector functions to exist. Any such non-eCos code will
never have worked properly in the past, but if we consider this to be
part of the supported API then we should fix it.

My personal preference is to get rid of these functions and save a bit
of memory. I would also eliminate the CYGACC_ macros and the
configuration option CYGSEM_HAL_VIRTUAL_VECTOR_CLAIM_CACHE. There
should be no effect on any eCos packages. Theoretically there could be
some eCos applications which currently use the CYGACC_ macros and
which would stop compiling, but hopefully the affected developers
would appreciate knowing that these macros have never worked properly.
However it could also cause problems for non-eCos code. If those
indirect through the virtual vector without checking then they'll
suddenly crash'n'burn.

What do other people think? Is anybody aware of non-eCos uses of these
virtual vector entries?

Bart


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