> Hi Chris, > once in your mail you said, > "If you are using the CodeSourcery toolchain, there's a bug in the linker that's waiting to be fixed. ld -r is used to combine the .o's, and it > reorders the __init_array sections incorrectly. There is an easy workaround though, you need to add '-T /dev/null' to the 'ld -r' step so it > doesn't use the default linker script." > I followed your suggestion, but there is still something wrong. when using arm-none-eabi instead of arm-elf to build ecos, the constructors with > diverse priorities were sorted in opposite order, while those with the same priority was arranged in ordinal order! so caused the constructors can > not be invoked correctly, and some objects did not be created. So I changed the priority of some constructors and make it run. However, is there any > other way to void changing the source code but make it work?? > and Gary, maybe it's a bug of eCos. while constructors have the same priority? Are there reasons and necessities for that? > > details about the order constructors were called, > constructors with arm-elf called in below order: > _GLOBAL__I.10100_diag... > _GLOBAL__I.11000_cyg_scheduler... > _GLOBAL__I.12000__ZN13Cyg_... > _GLOBAL__I.12000__Z26cyg_null... > _GLOBAL__I.14000__ZN9Cyg... > _GLOBAL__I.15000__ZN18Cyg_... > _GLOBAL__I.47000_cygmem... > _GLOBAL__I.49000__home... > _GLOBAL__I.52000__ZN20Cyg_libc_studio_files > _GLOBAL__I.52000_cyg_libc_main... > _GLOBAL__I.52000_cyg_iso_c_start > _GLOBAL__I.52001_cyg_libc_... > > constructors with arm-none-eabi called in the order: > _GLOBAL__I.10100_diag... > _GLOBAL__I.11000_cyg_scheduler... > _GLOBAL__I.12000__Z26cyg_null... > _GLOBAL__I.12000__ZN13Cyg_... > _GLOBAL__I.14000__ZN9Cyg... > _GLOBAL__I.15000__ZN18Cyg_... > _GLOBAL__I.47000_cygmem... > _GLOBAL__I.49000__home... > _GLOBAL__I.52000_cyg_iso_c_start > _GLOBAL__I.52000_cyg_libc_main... > _GLOBAL__I.52000__ZN20Cyg_libc_studio_files > _GLOBAL__I.52001_cyg_libc_... > > Please take a look at the highlight part, that's the reason caused the program wrong.
Hi Ray I think what's going on here is that you have CYG_INIT_PRIORITY values duplicated. As you know, initialization relies on the linker ordering the constructors. Try modifying the CYG_INIT_PRIORITY values for the areas you suspect are causing init order problems and see if that fixes your issue. When I did my port, I didn't have issues with equivalent values causing init order problems. --Chris -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
