|[cdt-dev] Integrating a non-standard toolchain in to a CDT plugin|
I am currently investigating how to integrate a proprietary toolchain in to the eclipse CDT and would appreciate any comments existing developers have on my proposed implementation.
The reason I would like some guidance is that our toolchain, although standard up to the point of building an ELF, includes some unusual aspects. Below is a description of how our toolchain works, followed by the way in which I think it could be integrated in CDT.
The end product of our toolchain is a multi-application binary to load on an embedded processor. This is constructed from a series of relocatable ELFs and a (form of) linker script. The tool that does this is called LDLK.
The input ELFs to LDLK come in 4 variants.
1) ‘overlays’. These are constructed from C/C++/ASM sources, compiled assembled then linked (using options specific to an ‘overlay’) with relevant static libraries. The end product of this is a relocatable ELF and a file listing all unresolved symbols
2) One or more applications. Each of these is constructed from C/C++/ASM sources compiled and assembled then linked along with any lists of unresolved symbols from overlays that the application uses and relevant static libraries. The end product of this is a relocatable ELF and a file listing all unresolved symbols.
3) ‘shared’ ELFs. These are ‘shared’ by multiple applications but contain code that is in fact linked statically by LDLK. Each of these is constructed from C/C++/ASM sources compiled and assembled then linked (using options specific to ‘shared ELFs’) along with static libraries and lists of unresolved symbols from overlays or applications that the shared ELF supports.
4) ‘global’ ELFs. These are constructed from C/C++/ASM sources compiled and assembled then linked (using options specific to ‘global’ ELFs).
The static libraries mentioned above refer to the standard definition of a static library. Below is a sketch of a relatively simple full system. The circles show files that are fed from one stage of a build to the next. I.e the result of building overlay 1 is an ELF and a symbol file. The symbol file is fed in to the build of Application 2 along with the symbols from overlay 2 and so on. All the ELFs are fed in to the final build stage (LDLK) that creates the final binary.
I’m hoping that the rather brief description of the toolchain above gives enough information for you to see how things link together. I have omitted discussion of compiler, assembler and linker to build an ELF as these behave like standard tools.
As far as I understand the CDT, a ‘normal’ project would provide a static library, shared library or application, and an application project could ‘depend’ on a number of static and/or shared library projects. I believe the best implementation of our toolchain is to create several new types of project, one for each of: static library, Application ELF, Shared ELF, Overlay ELF, Global ELF and Final Binary and use the dependency mechanism to link these together. I assume in doing that, the outputs of one project become available as inputs to projects that depend on it. Furthermore I assume there is a way to access the settings of one project from another (where a dependency exists).
So I am just hoping someone can comment as to whether my approach to this is sensible? I am an absolute newbie to eclipse and the PDE/CDT but will hopefully learn quickly!
Thanks in advance.
Back to the top