This is the mail archive of the
mailing list for the binutils project.
RE: extract ELF load address with binutils?
- From: "Radouch, Zdenek" <zradouch at irobot dot com>
- To: Alan Modra <amodra at gmail dot com>
- Cc: "Paul_Koning at Dell dot com" <Paul_Koning at Dell dot com>, "binutils at sourceware dot org" <binutils at sourceware dot org>
- Date: Wed, 19 Mar 2014 12:04:18 +0000
- Subject: RE: extract ELF load address with binutils?
- Authentication-results: sourceware.org; auth=none
- References: <7ADBB2DB4DC7CF4CB641E9ADA826E5E2AAC571BC at HQ-MBX-01 dot wardrobe dot irobot dot com> <m3a9i3s8s1 dot fsf at pepe dot airs dot com> <7ADBB2DB4DC7CF4CB641E9ADA826E5E2E1FBDF7F at hq-mbx-02 dot wardrobe dot irobot dot com> <m3siqgw32g dot fsf at pepe dot airs dot com> <7ADBB2DB4DC7CF4CB641E9ADA826E5E2E1FC0FF6 at hq-mbx-02 dot wardrobe dot irobot dot com> <m3k3brwvew dot fsf at pepe dot airs dot com> <7ADBB2DB4DC7CF4CB641E9ADA826E5E2E1FC2052 at hq-mbx-02 dot wardrobe dot irobot dot com> <C75A84166056C94F84D238A44AF9F6AD16C83E5D at AUSX10MPC103 dot AMER dot DELL dot COM> <7ADBB2DB4DC7CF4CB641E9ADA826E5E2E1FC207A at hq-mbx-02 dot wardrobe dot irobot dot com>,<20140318234418 dot GC9145 at bubble dot grove dot modra dot org>
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".
From: Alan Modra [firstname.lastname@example.org]
Sent: Tuesday, March 18, 2014 7:44 PM
To: Radouch, Zdenek
Cc: Paul_Koning@Dell.com; email@example.com
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
Australia Development Lab, IBM