Dear all: I was wondering if anybody has had a chance to look at this mistery... As this message had the unfortune of being posted roughly at the same time as another bug report about data types that generated a lively discussion (...) I am afraid it got lost under the pile.
Any comments as to what the problem might be? TIA, /dima ---------- Forwarded message ---------- From: Dima Diall <dimadi...@gmail.com> Date: 10-Aug-2005 19:26 Subject: Fwd: C compiler segfaults: BUG? To: mspgcc-users@lists.sourceforge.net My attachment exceeded the maximum allowed size and was rejected... I posted the file at http://www.cs.ucl.ac.uk/students/d.diall/mspgcc/app.i.bz2 Please let me know if you have difficulties in downloading the file. The details about the bug are in the message forwarded. ---------- Forwarded message ---------- From: Dima Diall <dimadi...@gmail.com> Date: Aug 10, 2005 5:40 PM Subject: C compiler segfaults: BUG? To: mspgcc-users@lists.sourceforge.net Cc: Kishore Raja <k.r...@cs.ucl.ac.uk>, Ioannis Daskalopoulos <ucab...@ucl.ac.uk> Hello list: I believe to have found a bug in msp430-gcc compiled from CVS on 25-05-2005 (binutils-2.15.96, gcc-3.2.3) running on GNU/Linux 2.6.12. I double checked this on a Windows XP with msp430-gcc 3.2.3 packaged by www.tinyos.net (binutils 041130 20041130). Below I include details in the format given by 'msp430-gccbug': >Confidential: no >Synopsis: <synopsis of the problem (one line)> >Severity: serious >Priority: medium >Category: c >Class: sw-bug >Release: 3.2.3 >Environment: System: Linux ojango 2.6.12-suspend2-r3 #1 Thu Jul 28 13:04:39 BST 2005 i686 Intel(R) Pentium(R) M processor 1.60GHz GenuineIntel GNU/Linux Architecture: i686 <machine, os, target, libraries (multiple lines)> host: i686-pc-linux-gnu build: i686-pc-linux-gnu target: msp430-unknown-none configured with: ./configure --prefix=/usr/local/msp430 --target=msp430 >Description: The nature of the bug is very, very weird (at least to me) as the C compiler crashes with segmentation fault apparently depending on the size of a struct (please, refer to an excerpt of the relevant code at the end of this message). There is #define'd constant that controls the size of an array inside the struct -- if the value is increased beyond a given threshold (>20 in this case) we have a segfault, otherwise compilation goes fine... The size of the array can be "traded" with other members of the struct, e.g. if I set the size of the array to 21 and remove an 8-bit field it works; now if I increase to 22 it breaks again (unless I remove another struct field :-) >How-To-Repeat: Please find the pre-processors output attached and the command line is the following: msp430-gcc -B/usr/local/lib/ncc -mmcu=msp430x149 -O -Wall -Wshadow -v -o /tmp/ccAH2Ya1.o -c -fdollars-in-identifiers build/imec/app.c Perhaps it should be noted that the app.c file is generated by nesC -- "an extension to the C programming language designed to embody the structuring concepts and execution model of TinyOS" (http://nescc.sf.net/) from a plethora of .nc and .h files. >Fix: None, except keeping the size of the struct below the "magic threshold" as described above. In my understanding the compiler should never fail with a segfault irrespective of what garbage might be fed in. I hope somebody can shed some light over this problem... Thanks! -- /dima /*...*/ #define TOSH_DATA_LENGTH 21 typedef struct TOS_Msg { uint16_t addr; uint16_t s_addr; uint8_t type; uint8_t group; uint8_t length; uint8_t seqNo; int8_t data[TOSH_DATA_LENGTH]; uint16_t crc; uint16_t strength; uint8_t ack; uint16_t time; } TOS_Msg; /*...*/
