I found an esoteric bug in the X (20bit) version of mspgcc (based 3.2 gcc compiler) that probably won't effect anyone but may effect a future implementation of an X compiler. The problem is with switch statements (i.e. jumptable).
The compiler decides whether to use long jumps or short jumps based on the "far" attribute of a function, but emits code for these based on the "in_text_section()" setting when code is generated. Normally these two are the same, but in my case they are not. I am writing code that I want to run from RAM. I do this by putting the code into a section, lets call it .text_run_from_ram. In the linker I include .text_run_from_ram in the .data section. Everything works fine until you have a switch statement that uses a jumptable (8 or more cases). The upper levels of the code generator think that the table is based on 2 byte addresses (based on no "far" attribute), which is right, but the low level code generator generates 4 byte addresses based on the fact that the segment is not ".text", it is ".text_run_from_ram". A quick fix of setting the ISR to be "far" doesn't work because "far" overrides the .section attribute. So I implemented a better but hackier solution of teaching the low level code to treat any segment that starts with ".text_" the same as ".text", so the low level code generator outputs a proper vector table. I've included a patch file http://old.nabble.com/file/p32353894/gcc_text_.patch gcc_text_.patch that can be run by: cd sf/gcc/gcc-3.3 patch -p0 < gcc_text_.patch before you start the whole build process. It would have liked to check in these changes but I don't have write access to the CVS repository. -- View this message in context: http://old.nabble.com/Bug-in-X-version-of-compiler-tp32353894p32353894.html Sent from the MSP430 gcc - Users mailing list archive at Nabble.com. ------------------------------------------------------------------------------ EMC VNX: the world's simplest storage, starting under $10K The only unified storage solution that offers unified management Up to 160% more powerful than alternatives and 25% more efficient. Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev _______________________________________________ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
