Hi Peter, thank you very much! It works for me both in the test case and in the real application!
Thanks again, Tobias On 2011-02-10 16:20, Peter Bigot wrote: > Thanks for providing the reproducing source code. Yes, > gas/config/tc-msp430.c defines a MAX_OP_LEN of 256 characters which causes > symbols to get truncated. To work around this, edit that file, increase the > length, and rebuild/reinstall binutils. A proper fix that removes > hard-coded limits on symbol lengths will be in an upcoming release. > > Interested parties can follow this tracker > item<https://sourceforge.net/tracker/?func=detail&atid=1177287&aid=3177314&group_id=277223> > . > > Peter > > On Wed, Feb 9, 2011 at 7:51 PM, Peter Bigot<p...@peoplepowerco.com> wrote: > >> I'm not immediately aware of any such limitation that would be due to the >> msp430-specific code. If the same code works built with the same version of >> gcc for a different target, then there's a problem that needs to be fixed. >> >> Can you submit a bug tracker entry on the mspgcc4 sourceforge project, >> including a demonstration program (that doesn't require Contiki, please)? >> >> Peter >> >> >> On Wed, Feb 9, 2011 at 4:39 PM, Tobias >> Baumgartner<tb...@ibr.cs.tu-bs.de>wrote: >> >>> Hi, >>> >>> I have a linker problem when my templates are getting too big (e.g., >>> many template parameters). The problem already occurred with mspgcc >>> 3.2.3, but still occurs with the latest build of 4.4.4. >>> >>> A linker error looks as follows: >>> out/routing_test.o: In function >>> `wiselib::DsrRouting<wiselib::ContikiOsModel, >>> wiselib::StaticArrayRoutingTable<wiselib::ContikiOsModel, >>> wiselib::ContikiRadio<wiselib::ContikiOsModel>, 10u, >>> wiselib::DsrRtValue<wiselib::ContikiRadio<wiselib::ContikiOsModel>, >>> wiselib::vector_static<wiselib::ContikiOsModel, unsigned int, 8> > >, >>> wiselib::ContikiRadio<wiselib::ContikiOsModel>, >>> wiselib::ContikiDebug<wiselib::ContikiOsModel> >::enable_radio()': >>> >>> /home/tbaum/develop/wiselib.svn/wiselib.stable/algorithms/routing/dsr/dsr_routing.h:138: >>> undefined reference to >>> >>> `_ZN7wiselib12ContikiTimerINS_14ContikiOsModelEE9set_timerINS_10DsrRoutingIS1_NS_23StaticArrayRoutingTableIS1_NS_12ContikiRadioIS1_EELj10ENS_10DsrRtValueIS7_NS_13vector_staticIS1_jLi8EEEEEEES7_NS_12ContikiDebugIS1_EEEEXadsrSF_NSF_13timer_elapsedEPvEEEimPT_' >>> out/routing_test.o: In function >>> >>> `_ZN7wiselib12ContikiRadioINS_14ContikiOsModelEE17reg_recv_callbackINS_10DsrRoutingIS1_NS_23StaticArrayRoutingTableIS1_S2_Lj10ENS_10DsrRtValueIS2_NS_13vector_staticIS1_jLi8EEEEEEES2_NS_12ContikiDebugIS1_EEEEXadsrSD_NSD_7receiveEjhPhEEEiPT_': >>> >>> What I have observed so far is the following: >>> * When I reduce template parameters, or even simplify class names, >>> the problem does not occur (I think, because the mangled "function" name >>> gets smaller - however, that is not a solution for the long run) >>> * Each name of such a function has a size of>= 256 characters >>> >>> With other compilers (other than msp430-g++), the problem does also not >>> occurr. >>> >>> Do I get it right that there is a problem with mangled names greater >>> than 255 bytes? If so, is there a possibility to get rid of that limit? >>> (e.g., a parameter when compiling mspgcc4) >>> >>> Or do I get something completely wrong? >>> >>> >>> >>> Best, >>> Tobias >>> >>> >>> ------------------------------------------------------------------------------ >>> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: >>> Pinpoint memory and threading errors before they happen. >>> Find and fix more than 250 security defects in the development cycle. >>> Locate bottlenecks in serial and parallel code that limit performance. >>> http://p.sf.net/sfu/intel-dev2devfeb >>> _______________________________________________ >>> Mspgcc-users mailing list >>> Mspgcc-users@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/mspgcc-users >>> >> >> > Viele Gruesse, Tobias -- | Tobias Baumgartner | Office IZ 245 | | IBR, Abteilung Algorithmik | Phone 0531 / 391 - 3116 | | Technische Universitaet Braunschweig | Mail tb...@ibr.cs.tu-bs.de | | Muehlenpfordtstr. 23 | Skype t.baum | | 38106 Braunschweig | | ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
