This is the mail archive of the binutils@sourceware.org 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]

RE: ELF and Linking for heterogeneous multicore embedded systems


Thanks Carlos,

I'm glad I haven't just inadvertently missed something in the evolution of ELF and Binutils, although I was also kind-of secretly hoping that I had.

The solution I use currently, is to place the information for each core in its own section, with the symbols and sections renamed to avoid conflict.  This works fine for homogeneous multicore, but when you drop in more than one CPU technology, you are left with the problem of relocations and disassembly (at the very least).  If the CPU architectures have different endianness, the situation becomes really tricky.

For relocations and 2 x CPU architectures the choice is to supplement the relocations for architecture A with the relocations for B, or vice versa.  It’s a hack, and I'm not proud of it, but it works.  Disassembly is trickier, because it means that the person invoking the tool needs to know what CPU's assembly is in what section, and explicitly request disassembly of particular named sections for a particular processor.  Annoying, but workable.  Automating this in Eclipse or another agnostic IDE is much harder :-(

Regarding:

   > The notion of a multi-arch ELF binary doesn't exist, and
   > relocation numbers overlap between architectures, so you
   > would really really need to find a way to isolate the
   > architecture components.

   I was hoping that it might be possible to select the relocation
   set based on the input section information; so if for instance
   it said that it was a Sparc input section I could invoke the
   Sparc relocation engine, and if it was X86 I would select the
   X86 relocation engine; and so on.  This would avoid the need
   for an "Uber Managed Relocation Space".

I haven't seen "FatELF" before, thanks for this link and I will investigate it.

At the moment I am considering the possibility of supporting 3 or more architectures in the same ELF, so the "hack" relocations technique does not scale.

All the best and thanks again for the great feedback,

	MartinO

-----Original Message-----
From: binutils-owner@sourceware.org [mailto:binutils-owner@sourceware.org] On Behalf Of Carlos O'Donell
Sent: 04 August 2017 20:00
To: Martin J. O'Riordan <MartinO@theheart.ie>; binutils@sourceware.org
Subject: Re: ELF and Linking for heterogeneous multicore embedded systems

On 08/04/2017 06:21 AM, Martin J. O'Riordan wrote:
> How do other people address these kinds of issues for their multicore 
> systems, homogeneous or heterogeneous?

There are no elegant solutions because there has been no real need.

Today the biggest drivers are:

* CPU / FPGA combinations.
* CPU / GPU combinations.

They are all usually proprietary and use a single ELF binary with embedded data in specially named sections.

The notion of a multi-arch ELF binary doesn't exist, and relocation numbers overlap between architectures, so you would really really need to find a way to isolate the architecture components.

Your only option is probably FatELF [1], and it would be nice if we saw more universal acceptance of something like that.

--
Cheers,
Carlos.

[1] https://icculus.org/fatelf/


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