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: bug allert, variable alignment problem in ecos


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


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