arm scatter file

No, an ELF file is not ready for execution just like that. For starters, because it's still a _file_, not a memory image of a runnable program.

Among the reasons for that is that ELF files usually contain a whole lot of stuff that the CPU neither needs to see, nor should it, like debug information. And that those pieces of data that the CPU _is_ supposed to see are still in multiple pieces, at places inside the file that have little to nothing to do with the actual place they need to be in CPU memory space.

An ELF file is supposed to be loaded from some kind of storage external to the CPU (e.g. a hard disk drive), by something like a full-blown operating system. As their most prominent example, Unix / Linux programs on disk are ELF files, these days.

No. That ELF files are not usable as raw executable is pretty much a universal fact. It is in no way related to the ARM architecture.

Hi Hans, thanks so much for the information. So the ELF generated by the linker is s till not ready for execution but atleast as far as the ARM specification is concerned, they called the linked elf executable. Here is what the ARM Lin ker utilities guide says "Output from a successful invocation of armlink is one of the following: ? an executable image in ELF executable format ".

In any case, my question is what is difference between, load view and execu tion view of the image?

thanks regards ashu

It is common to call an ELF file "executable", because it *contains* the executable machine code. But it also contains a lot of *other* information, so you cannot just put the ELF file, byte per byte, into the processor memory and boot.

There must be a program loader that reads the ELF file, extracts the machine-code instructions and other memory-initialization data, and puts the instructions and data in the processor memory, at their correct addresses (also specified in the ELF file). *Then* execution can start.

See

Or, for a bare-metal embedded system, one can convert the elf to a binary image which can be directly executed. For example, for ARM and gcc toolchain, might be

arm-elf-objcopy -O binary program.elf program.bin

This would convert program.elf to a directly executable file program.bin which could be loaded into flash memory and executed.

Hi all, thanks for all the precious information. Why do we need two separate views for the image i.e. load view and executio n view. Can anyone give me an example where we need two separate load regio ns and corresponding multiple execution regions?

regs ashu

Well, one thing is that .elf would typically contain all the debug information. You don't want that on a small embedded target because it takes up too much memory. So you program the .bin binary file into the target and load up your debugger with the .elf.

The ARM CPUs I have come across have some sort of built-in bootloader that interprets a certain format of data in flash. In its simplest form: the program image is 0x12345 bytes, and starts at 0x23456. Such a thing in flash is "executable" to the CPU. An ELF file is not executable for the CPU alone, it needs some support programs to load.

The load (linking) view describes what's needed for linking (symbol names, section names, possible debug information). The execution view describes what's needed for execution (memory segment attributes, and that's about all it describes unless you have an executable for an operating system, where it also refers to shared libraries).

If you make a program to convert an ELF file into that "certain format of data in flash", you'll probably read the execution view, just because that's a little simpler.

Stefan

view. Can anyone give me an example where we need two separate load regions and corresponding multiple execution regions?

For something like an ELF executable, there's an expectation that there are going to be relocations at load times, and fixups for calls to shared libraries, etc. Until those happen, the image is not actually executable. The ELF file contains the information needed to do that. It can also include things like debug information.

When you're running without an OS, you need to get the executable relocated and whatnot before you put it on the device, since there's no one there to do it later.

Op Tue, 12 Mar 2013 17:29:42 +0100 schreef ashu =

te =

This sounds like a homework question. If you know anything about the =

current range of microcontrollers you know that they can have different = =

(and separate) address spaces and different memory regions which may or = =

may not allow execution.

-- =

Gemaakt met Opera's revolutionaire e-mailprogramma: =

The way the OP ignored the response they were replying to and went straight back to asking the same question also made me think it was homework as well.

The original question was sufficiently unclear that I also wondered if the OP was thinking more about the need to relocate .data from flash address space (assuming a flash based boot) to ram. However, I see that as having too obvious a answer to be asking about so it's probably not that.

If it was the OP's actual question however, then I won't answer it directly in case it's homework, but instead I will ask the OP to think about the difference between .rodata and .data and what is actually stored in those sections. _If_ that was your question, it should now be obvious why .data needs to be relocated to a different, ram based, address during execution.

Simon.

IIRC, the idea of a scatter file belongs to the now-discontinued old ARM toolkit. The toolkit was superseded by the Keil tools, when ARM bought Keil.

The question about an old toolkit has a strong whiff of homework and a slightly obsolete professor.

There _can_ be those expectations. An ELF file could also contain nothing but absolutely located sections with no unresolved externals. In that case it doesn't need to be relocated or linked -- it just needs to have the section contents copied into memory and is similar in usage to a hex file or a uImage file.

Actually, it's the other way round. As the primary consequence of that merger, it was Keil's ARM C compiler that was discontinued and superseded by (a limited edition of) ARM's own "RealView" compiler.

And I think they still use linker scripts (a.k.a. scatter files) --- the main difference being that in most simple situations Keil's IDE can generate them on the fly, without the user even knowing about it.

OK - Thanks. I abandoned both in favour of the GNU tools.