This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

ELF and Linking for heterogeneous multicore embedded systems

The custom embedded processor I develop tools for has 2 different processor
types, one is a Sparc Leon and the other our own proprietary design.  There
are multiple cores of each type on the chip, using a single shared memory
space (simple 32-bit Von Neumann address space).

But linking to create a single static ELF memory image is tricky, and we
have had to use tricks to make this happen.  In this case I supplemented the
Sparc relocations with the small number of additional relocations needed for
the other processor type, and "lied" to the assembler and linker that the
input and output sections from the proprietary sections are also Sparc.

This is woefully inelegant, but it does address the issue of creating a
single static image for the heterogeneous nature of creating a the device.
To address contention across cores (even homogeneous cores) we use 'objcopy'
to perform symbol and section name prefixing to allow the contributors for
each core to be kept separate.

There is no capability for supporting any kind of dynamic loading or "in
system" fixups and relocations, so the static approach is best for our

What I would like to know, is whether ELF and Binutils have evolved better
strategies for creating a single ELF image that has contributions from more
than one processor type, and have there been changes to better support
namespace separation between contributors for multiple cores?

It would seem that the need to support multicore embedded system linking is
very important nowadays, and supporting heterogeneous multicore just adds a
twist to the complexity.

How do other people address these kinds of issues for their multicore
systems, homogeneous or heterogeneous?

Originally I developed the solution I currently use with Binutils v2.16, but
there has been a lot of development since then and I could easily have
failed to realise that there are now better ways of achieving this kind of
result using builtin capabilities of Binutils v2.28 (my current version) or
in the latest v2.29.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]