From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14869 invoked by alias); 12 Jun 2002 14:01:09 -0000 Mailing-List: contact ecos-discuss-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@sources.redhat.com Received: (qmail 14825 invoked from network); 12 Jun 2002 14:01:04 -0000 Received: from unknown (HELO blackstar.vidisys.com) (194.25.115.114) by sources.redhat.com with SMTP; 12 Jun 2002 14:01:04 -0000 Received: from doms.vidisys.com (doms.vidisys.com [192.168.3.4]) by blackstar.vidisys.com (8.11.3/8.11.3/SuSE Linux 8.11.1-0.5) with ESMTP id g5CE35L18414 for ; Wed, 12 Jun 2002 16:03:05 +0200 Received: (from larice@localhost) by doms.vidisys.com (8.11.3/8.11.3/SuSE Linux 8.11.1-0.5) id g5CE35F12921 for ecos-discuss@sources.redhat.com; Wed, 12 Jun 2002 16:03:05 +0200 From: Larice Robert Message-Id: <200206121403.g5CE35F12921@doms.vidisys.com> To: ecos-discuss@sources.redhat.com Date: Wed, 12 Jun 2002 07:01:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: [ECOS] bug allert, variable alignment problem in ecos X-SW-Source: 2002-06/txt/msg00192.txt.bz2 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