[ECOS] RE: issues about linking order

Chris Zimman czimman@bloomberg.com
Thu Jul 10 11:13:00 GMT 2008


> 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



More information about the Ecos-discuss mailing list