[ECOS] bug allert, variable alignment problem in ecos

[ECOS] bug allert, variable alignment problem in ecos

[Larice Robert]

Hello,

  some time ago, i've reported a CPU access alignment problem caused by
    static char idle_thread_stack[][]
  in
    packages/kernel/current/src/common/thread.cxx

  (see http://sources.redhat.com/ml/ecos-discuss/2002-05/msg00333.html)


  i've spend some time to track this down further.
  the following testfile.C was compiled with several different gcc's

     static char idle_thread_stack[1][2048];
     static char another_try[2048];
     
     void *preseve1 = idle_thread_stack;
     void *preseve2 = another_try;

  compilation is done with:
    gcc -c -S -o - testfile.C
  so you get the intermediate assembler output on stdout.

  the two dimensional array idle_thread_stack is compiled for
    1 byte alignment
  by the following gcc's:
    egcs-2.91.66      arm-unknown-coff-gcc, h8300-unknown-hms-gcc
    gcc-2.95.2        i960-intel-coff-gcc
    gcc-2.95.3        sh-elf-gcc, arm-elf-gcc, m32r-elf-gcc
    gcc-3.0.4         sh-elf-gcc
  most do so with the following asm line
    .comm	_idle_thread_stack,2048,1
  (third parameter is the alignment)

  the one dimensional array another_try is compiled for
    4 byte alignment
  by most of them, but for 
    1 byte alignment
  by the following gcc:
    gcc-2.95.3        arm-elf-gcc
   

  a grep search through the sources of ecos reveals numerous instances
  of one and two dimensional char arrays. lots of them are used for
    cyg_thread_create()
  to provide stack space. this function DOES NOT align the provided
  space to word boundaries. thus there is real danger.
  but there are non stack related problems too.
  for example in sched.cxx:
    CYG_BYTE cyg_sched_cpu_interrupt
      [CYGNUM_KERNEL_CPU_MAX][sizeof(Cyg_Interrupt)] 
    CYGBLD_ANNOTATE_VARIABLE_SCHED;
  which suffers the same problem.


  there is even a notion in ecos/packages/kernel/current/ChangeLog
	* tests/testaux.hxx: 
	thread_obj[][] and stack[][] are now 8-byte aligned like certain
	processors require; Cyg_Thread contains cyg_tick_count which is
	64-bit so any "standalone" C++ object would be so aligned.  These
	dynamically allocated ones should be too.

  in test/testaux.hxx the following is used instead of the popular
    static char []:

    static CYG_ALIGNMENT_TYPE thread_obj[NTHREADS] [
     (sizeof(Cyg_Thread)+sizeof(CYG_ALIGNMENT_TYPE)-1)
       / sizeof(CYG_ALIGNMENT_TYPE)                     ];
  
    static CYG_ALIGNMENT_TYPE stack[NTHREADS] [
     (STACKSIZE+sizeof(CYG_ALIGNMENT_TYPE)-1)
       / sizeof(CYG_ALIGNMENT_TYPE)                     ];


any comments ?

  Robert Larice

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

Re: [ECOS] bug allert, variable alignment problem in ecos

[Stephen Morgan]

Sorry for the slow reply.

I cheated.  For cases in which I found the problem -- luckily, there 
weren't all that many --, I told gcc to align the C and C++ fields on a 
large enough boundary that the layouts matched.  For example, I changed kapidata.h to align fields in the thread data structures.

First, I added a macro that allowed me to align a field using gcc's 
"attribute" capability for my platform (which I'll call "blech"):

        #ifdef CYGPKG_HAL_BLECH
        #define CYGPKG_HAL_ALIGNED __attribute__ ((aligned (8)))
        #else // ! CYGPKG_HAL_BLECH
        #define CYGPKG_HAL_ALIGNED
        #endif // CYKPKG_HAL_BLECH

Then, I used the macro to align fields that weren't otherwise properly 
aligned.  For example, I changed CYG_THREADTIMER_MEMBERS from:

        #define CYG_THREADTIMER_MEMBERS                 \
                CYG_ALARM_MEMBERS                                       \
                cyg_thread *thread;

to:

        #define CYG_THREADTIMER_MEMBERS                 \
                CYG_ALARM_MEMBERS                                       \
                cyg_thread *thread CYGPKG_HAL_ALIGNED ;

It wasn't pretty, but it worked and we had to meet a deadline...

(BTW, I couldn't readily cut and paste from the source to this note, so I 
typed in the above.  It may contain errors!)

Stephen P. Morgan





Larice Robert <larice@vidisys.de>
06/14/2002 04:03 AM

 
        To:     Stephen Morgan/Almaden/IBM@IBMUS
        cc:     ecos-discuss@sources.redhat.com
        Subject:        Re: [ECOS] bug allert, variable alignment problem in ecos

 

Hello Stephen,

  how did you deal with this, did you stop the project, did you find
  a solution, or did you just live with the linker lottery.
  most of the time you wont notice the problem, because most global 
objects
  are aligned to 4 byte. so if there are just few in-between, you have
  a good chance to be lucky.

  actually the problem i've described is not C++ specific. though
  the want to allocate space for some class object, and the want
  to avoid constructor calling, has led to some
     char space[sizeof(class ..)];
  in the ecos tree, which is another manifestation of the alignment 
problem.

  to extend your aside, for me too, the decision to use C++ for the
    bit-tiddling internals of an embedded realtime os is a bit
    unexpected. but with great care can be done, and has merits too.

  anyway, i've sent a patch for almost 200 dangerous global variables
  to ecos-patches. (though most of them are in some test directories, and
  thus of minor significance. those will even be helpfull to get
  accustomed with the debugger)

Robert Larice

> Yes.  We saw the problem in debugging eCos on a MIPS32 processor and it 
> drove us crazy.  It showed up especially in threads structures as these 
> are shared between C and C++ code, which apparently have different 
> alignment rules.
> 
> As an aside, I'm a dyed in the wool C programmer, and find C++ a 
miserable 
> language.  Why would anyone mix C and C++ within an operating system? Of 

> course, I use vi as I find emacs incomprehensible, which may indicate 
> something about my sensibilities -- or merely my abilities...  8-)
> 
> Stephen P. Morgan




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

Re: [ECOS] bug allert, variable alignment problem in ecos

[Larice Robert]

Hello Stephen,

  how did you deal with this, did you stop the project, did you find
  a solution, or did you just live with the linker lottery.
  most of the time you wont notice the problem, because most global objects
  are aligned to 4 byte. so if there are just few in-between, you have
  a good chance to be lucky.

  actually the problem i've described is not C++ specific. though
  the want to allocate space for some class object, and the want
  to avoid constructor calling, has led to some
     char space[sizeof(class ..)];
  in the ecos tree, which is another manifestation of the alignment problem.

  to extend your aside, for me too, the decision to use C++ for the
    bit-tiddling internals of an embedded realtime os is a bit
    unexpected. but with great care can be done, and has merits too.

  anyway, i've sent a patch for almost 200 dangerous global variables
  to ecos-patches. (though most of them are in some test directories, and
  thus of minor significance. those will even be helpfull to get
  accustomed with the debugger)

Robert Larice

> Yes.  We saw the problem in debugging eCos on a MIPS32 processor and it 
> drove us crazy.  It showed up especially in threads structures as these 
> are shared between C and C++ code, which apparently have different 
> alignment rules.
> 
> As an aside, I'm a dyed in the wool C programmer, and find C++ a miserable 
> language.  Why would anyone mix C and C++ within an operating system?  Of 
> course, I use vi as I find emacs incomprehensible, which may indicate 
> something about my sensibilities -- or merely my abilities...  8-)
> 
> Stephen P. Morgan

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

Re: [ECOS] bug allert, variable alignment problem in ecos

[Stephen Morgan]

Yes.  We saw the problem in debugging eCos on a MIPS32 processor and it 
drove us crazy.  It showed up especially in threads structures as these 
are shared between C and C++ code, which apparently have different 
alignment rules.

As an aside, I'm a dyed in the wool C programmer, and find C++ a miserable 
language.  Why would anyone mix C and C++ within an operating system?  Of 
course, I use vi as I find emacs incomprehensible, which may indicate 
something about my sensibilities -- or merely my abilities...  8-)

Stephen P. Morgan





Larice Robert <larice@vidisys.de>
Sent by: ecos-discuss-owner@sources.redhat.com
06/12/2002 07:03 AM

 
        To:     ecos-discuss@sources.redhat.com
        cc: 
        Subject:        [ECOS] bug allert, variable alignment problem in ecos

 

Hello,

  some time ago, i've reported a CPU access alignment problem caused by
    static char idle_thread_stack[][]
  in
    packages/kernel/current/src/common/thread.cxx

  (see http://sources.redhat.com/ml/ecos-discuss/2002-05/msg00333.html)


  i've spend some time to track this down further.
  the following testfile.C was compiled with several different gcc's

     static char idle_thread_stack[1][2048];
     static char another_try[2048];
 
     void *preseve1 = idle_thread_stack;
     void *preseve2 = another_try;

  compilation is done with:
    gcc -c -S -o - testfile.C
  so you get the intermediate assembler output on stdout.

  the two dimensional array idle_thread_stack is compiled for
    1 byte alignment
  by the following gcc's:
    egcs-2.91.66      arm-unknown-coff-gcc, h8300-unknown-hms-gcc
    gcc-2.95.2        i960-intel-coff-gcc
    gcc-2.95.3        sh-elf-gcc, arm-elf-gcc, m32r-elf-gcc
    gcc-3.0.4         sh-elf-gcc
  most do so with the following asm line
    .comm                _idle_thread_stack,2048,1
  (third parameter is the alignment)

  the one dimensional array another_try is compiled for
    4 byte alignment
  by most of them, but for 
    1 byte alignment
  by the following gcc:
    gcc-2.95.3        arm-elf-gcc
 

  a grep search through the sources of ecos reveals numerous instances
  of one and two dimensional char arrays. lots of them are used for
    cyg_thread_create()
  to provide stack space. this function DOES NOT align the provided
  space to word boundaries. thus there is real danger.
  but there are non stack related problems too.
  for example in sched.cxx:
    CYG_BYTE cyg_sched_cpu_interrupt
      [CYGNUM_KERNEL_CPU_MAX][sizeof(Cyg_Interrupt)] 
    CYGBLD_ANNOTATE_VARIABLE_SCHED;
  which suffers the same problem.


  there is even a notion in ecos/packages/kernel/current/ChangeLog
                 * tests/testaux.hxx: 
                 thread_obj[][] and stack[][] are now 8-byte aligned like 
certain
                 processors require; Cyg_Thread contains cyg_tick_count 
which is
                 64-bit so any "standalone" C++ object would be so 
aligned.  These
                 dynamically allocated ones should be too.

  in test/testaux.hxx the following is used instead of the popular
    static char []:

    static CYG_ALIGNMENT_TYPE thread_obj[NTHREADS] [
     (sizeof(Cyg_Thread)+sizeof(CYG_ALIGNMENT_TYPE)-1)
       / sizeof(CYG_ALIGNMENT_TYPE)                     ];
 
    static CYG_ALIGNMENT_TYPE stack[NTHREADS] [
     (STACKSIZE+sizeof(CYG_ALIGNMENT_TYPE)-1)
       / sizeof(CYG_ALIGNMENT_TYPE)                     ];


any comments ?

  Robert Larice

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





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