[EMAIL PROTECTED] wrote: > Dear all: > We are now porting eCos kernel to our platform, EVB named > spaca556g(arm926ej-s). We choose a gcc4.2 eabi > compiler(http://www.codesourcery.com/gnu_toolchains/arm/download.html). The > reason of choosing this compiler is that an EABI compiler can be completely > compatible with ARM RealView libraries. With this arm-eabi compiler, > libraries built from realview can be used. > But there are some problems using this eabi compiler. Because of different > constructing method between arm-elf compiler and eabi compiler, > constructors of global instances can't be invoked automatically when using > the eabi compiler. As a result, we have to make changes to arm.ld and > hal_misc.c files. > > NOTE: arm-elf compiler use .ctor section and 2 labels(__CTOR_LIST__, > __CTOR_END__) to invoke constructors, BUT arm-eabi compiler use .init_array > section and lables(__init_array_start, __init_array_end) > > arm-eabi compiler's linker script has different sections from arm-elf > compiler's, e.g: .ARM.extab, .ARM.exidx and .ARM.attributes 0, these 3 > sections are own in arm-eabi compiler. These sections should be added to > arm.ld, aren't they? If so, there are 2 ways to achieve this goal. One is > making direct changes to arm.ld and adding corresponding sections' > definitions. The other is setting up a new arch-eabi directory in hal/arm, > which is only for arm-eabi compiler. Which is the best?
Add a CDL option to the ARM arch which controls this. Then you can have everything be automatic; compiler names (arm-elf-gcc vs. arm-eabi-gcc, etc), linker script, how the constructors are handled, etc. The rest of the code should stay the same; it will still be the same ARM hardware underneath. n.b. if you were to split into an arm-eabi directory, I think there would have to be *way* too much duplication (which inevitably leads to code-rot) BTW, in my mind, this is a development question (hence I changed the mailing list). The eCos maintainer list is for questions/issues dealing with licensing, distribution, etc. -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------
