RE: extract ELF load address with binutils?

["Radouch, Zdenek" <zradouch@irobot.com>]

I'll re-phrase my question to make it clear what I am looking for.

First some background -- while I never looked at any of the BFD code
I do have a pretty good idea about both the linking process and ARM/ELF
issues, including the 0x8000 page size (OK, so I called it "alignment-related
pading" and now I've been corrected --  it's not "padding" :-)).

What I am after is improving the back end of the embedded development process, the
firmware loading at manufacturing or (as in my case) at run time.
The commonly used paradigm today (I have seen it on numerous  ARM
projects, and I always set it up the same way, too) is the following:

1. Hard-code the memory load address in the linker script
2. Build and link (often with back-box environment - forget ld -n -N)
    or as in my case don't link, get an already linked file from someone
3. Run objcopy -O binary to extract the memory image
4. Load the memory image using the hard-coded address from the step #1

That's the reality of the embedded life. Asking people to change/ link differently
when they can see that what they produce works fine won't fly, they wouldn't
do it even if they were willing since the linking and linker scripts in the embedded
space are typically not understood even by the people who set up the projects. 

I am simply questioning whether or not I could, with some moderate effort (i.e., shell/python)
fix the very fragile last step (4) that requires the load address to be "carried along" with
the object file. I do know that all of the necessary info is in the ELF file, objcopy knows
that, too, and successfully extracts the data, the only problem is that objcopy is silent
about what it did. So my question is:

Can I get the load address (i.e., the address corresponding to the first section
that went into the image objcopy made)?
And yes it is THE address, as objcopy produces a single image.

If the answer is no, not with binutils as they are today, then my second question is what is the
algorithm objcopy uses? I can duplicate it on the output of "readelf -S".

Thanks
-Z


________________________________________
From: Alan Modra [amodra@gmail.com]
Sent: Tuesday, March 18, 2014 7:44 PM
To: Radouch, Zdenek
Cc: Paul_Koning@Dell.com; binutils@sourceware.org
Subject: Re: extract ELF load address with binutils?

On Tue, Mar 18, 2014 at 05:44:11PM +0000, Radouch, Zdenek wrote:
> But as I (and objcopy) have illustrated:
> 1. Not all LOAD types get loaded

Correct, only those with p_filsiz (readelf -l FileSize column)
non-zero.  p_memsiz specifies a bss type area that is usually cleared
to zero by a program loader.

> 2. The address where the segment is loaded can be "wrong", when the loaded segment
>    has been padded.

The address you showed isn't due to padding.  You're seeing 0x158000
when .text starts at 0x15f000 because you linked the object for
dynamic paging with a page size of 0x8000.  That imposes constraints
on p_vaddr.  You will also be loading the ELF file header and program
headers, which may not be what you want..  See ld -n and ld -N
options.

--
Alan Modra
Australia Development Lab, IBM