| [cdt-dev] Integrating a non-standard toolchain in to a CDT plugin |
|
Hello all, 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. Regards, Matthew
|
