This is the mail archive of the
mailing list for the binutils project.
RE: ELF and Linking for heterogeneous multicore embedded systems
- From: "Martin J. O'Riordan" <MartinO at theheart dot ie>
- To: "'Carlos O'Donell'" <carlos at redhat dot com>, <binutils at sourceware dot org>
- Date: Fri, 4 Aug 2017 21:16:34 +0100
- Subject: RE: ELF and Linking for heterogeneous multicore embedded systems
- Authentication-results: sourceware.org; auth=none
- References: <firstname.lastname@example.org> <email@example.com>
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 :-(
> 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,
From: firstname.lastname@example.org [mailto:email@example.com] On Behalf Of Carlos O'Donell
Sent: 04 August 2017 20:00
To: Martin J. O'Riordan <MartinO@theheart.ie>; firstname.lastname@example.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 , and it would be nice if we saw more universal acceptance of something like that.