Some additional information that might be relevant: In current mspgcc, the vector table is linked with a crtXivtbl.o file, with the correct one selected by the -mivcnt option to msp430-gcc. The value is set to the appropriate default (16, 32, 64) based on the mmcu option; in most cases you won't need to use the option explicitly.
The names of global functions automatically linked into the vector table changed about a year ago, and no longer encode an address. The new format is "__isr_X" where X is the base-zero vector index from the start of the vector table. For backwards compatibility, the reset vector is not called __isr_N (N=15, 31, or 63) but retains its legacy name of _reset_vector__. The compiler will generate the correct name, but since it's derived programmatically from the value of the VECTOR macro from the header the assembler cannot do so (the preprocessor won't support the operations required). This was discussed at https://sourceforge.net/projects/mspgcc/forums/forum/138167/topic/4885778 but AFAIK the original poster never opened a ticket, and until that's done it won't get worked. Either of those might be relevant to your vector table size problem. It may also be worth reviewing msp430/lib/ldscripts/msp430.x (relative to wherever the toolchain was installed), as the linker sections (especially those related to initialization) have been significantly modified. Some of that may have affected how static initializers and destructors are processed, and you may need to replicate those changes in your custom scripts. Peter 2012/2/16 Stefan Nürnberger <s...@zelle79.org> > > Linking with msp430-gcc and omitting the -nostdlib flag (needed when > linking with msp430-g++) indeed solved the startup code problem. Thank > you. I still have some issues with our custom interrupt vector table > being double the size it was with mspgcc4, but I will try to figure that > out tomorrow. > > Stefan > > Am 16.02.2012 20:20, schrieb Peter Bigot: > > To help the compiler stay consistent with the C startup code, that code > > moved from msp430-libc to the compiler, and lives in a different object > > file now. Use msp430-gcc instead of msp430-ld to perform the link step. > > Make sure you include the -mmcu argument so the linker uses the right > > memory and peripheral data. > > > > I suggest building a simple hello.c program with msp430gcc -v to see the > > steps that are performed and the corresponding arguments to the tools if > > you need to customize something. > > > > Peter > > > > 2012/2/16 Stefan Nürnberger <s...@zelle79.org> > > > >> Hello, > >> > >> I am currently migrating a project from mspgcc4 to the new mspgcc > >> toolchain. I am using the msp430-gcc (GNU GCC patched mspgcc-20110716) > >> 4.5.3 from the official debian repositories. I am missing some hints on > >> what changed between those versions. Here are my questions: > >> > >> In our project we are using a custom linker script and we would like to > >> keep it this way. But mspgcc will not link the executables out of the > >> box. At first I noticed that in our linker script we had explicitly set > >> the output architecture with OUTPUT_ARCH(msp:16) or (msp:54) which I > >> understand is no longer supported. The linker should take the correct > >> information from the -mmcu switch. Is this correct? > >> > >> And what is more of a problem: The linker won't link the default startup > >> code like it did with mspgcc4. We are missing all of the __do_copy_data, > >> __do_clear_bss, __do_global_ctors and __jump_to_main. Also the > >> _reset_vector__ is not defined. When we define it in the linker script, > >> the program will link correctly but without the default startup code. > >> What switches are likely to cause this behaviour? Is this expected with > >> custom linker scripts? How can we force the default startup code to be > >> linked in? > >> > >> BTW this is a C++ project compiled and linked with msp430-g++. > >> > >> Thanks > >> Stefan > >> > >> P.S. sorry if this is a double post. It seems the mailing list does not > >> like my other mail address. > >> > >> > >> > >> ------------------------------------------------------------------------------ > >> Virtualization & Cloud Management Using Capacity Planning > >> Cloud computing makes use of virtualization - but cloud computing > >> also focuses on allowing computing to be delivered as a service. > >> http://www.accelacomm.com/jaw/sfnl/114/51521223/ > >> _______________________________________________ > >> Mspgcc-users mailing list > >> Mspgcc-users@lists.sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/mspgcc-users > >> > > > ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
