[ECOS] Stack access violations in eCos

Bart Veer bartv@ecoscentric.com
Thu Mar 20 11:56:00 GMT 2003


>>>>> "Larice" == Larice Robert <larice@vidisys.de> writes:
    <snip>

    >> Let's not start adding alignment directives to every testcase and
    >> program without first considering alternatives.

    Larice> there are not only stackspaces broken.
    Larice> for example there are code sniplets which look like this
    Larice>   char intr[sizeof(class Cyg_Int_something)];
    Larice> and elsewhere this thing is recast to the actual class object

    Larice> there are some gobal char arrays which are obviously used
    Larice> as mempool for something.

    Larice> the basic issue here is to learn that one can't request a
    Larice> char array from any c compiler, and then to expect its
    Larice> suitabilty for anything else than a char array.

Sure, updating e.g. HAL_THREAD_INIT_CONTEXT() won't fix all the
problems but it should eliminate most of the patch. Other problem
areas like:

    cyg_uint8 thread_obj[sizeof(Cyg_Thread)];

in posix/pprivate.h could be handed by e.g.:

    #include <kapidata.h>
    struct cyg_thread thread_obj;

That would still avoid a static constructor being called at an
inconvenient time, but the code now accurately reflects what that
memory will get used for and the compiler should have enough
information to do the right thing.

There may still be a few places where an alignment attribute cannot be
avoided, but hopefully only a few.

Bart

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

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



More information about the Ecos-discuss mailing list