From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31735 invoked by alias); 19 Mar 2014 12:05:11 -0000 Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org Received: (qmail 31701 invoked by uid 89); 19 Mar 2014 12:05:10 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.2 X-HELO: tx2outboundpool.messaging.microsoft.com Received: from tx2ehsobe003.messaging.microsoft.com (HELO tx2outboundpool.messaging.microsoft.com) (65.55.88.13) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Wed, 19 Mar 2014 12:05:09 +0000 Received: from mail53-tx2-R.bigfish.com (10.9.14.229) by TX2EHSOBE010.bigfish.com (10.9.40.30) with Microsoft SMTP Server id 14.1.225.22; Wed, 19 Mar 2014 12:05:07 +0000 Received: from mail53-tx2 (localhost [127.0.0.1]) by mail53-tx2-R.bigfish.com (Postfix) with ESMTP id 6B9CD1E015A; Wed, 19 Mar 2014 12:05:05 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.238.211.235;KIP:(null);UIP:(null);IPV:NLI;H:hq-edge-02.wardrobe.irobot.com;RD:66.238.211.235.ptr.us.xo.net;EFVD:NLI X-SpamScore: -2 X-BigFish: VPS-2(zz98dI9371Id87dhzz1f42h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hz8dhz1de098h8275dh1de097hz2dh109h2a8h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h1b0ah2222h224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h2216h22d0h2336h2438h2461h2487h24ach24d7h2516h2545h255eh25f6h2605h262fh2668h1155h) Received: from mail53-tx2 (localhost.localdomain [127.0.0.1]) by mail53-tx2 (MessageSwitch) id 1395230701618297_22461; Wed, 19 Mar 2014 12:05:01 +0000 (UTC) Received: from TX2EHSMHS015.bigfish.com (unknown [10.9.14.244]) by mail53-tx2.bigfish.com (Postfix) with ESMTP id 7D16A4400B7; Wed, 19 Mar 2014 12:05:01 +0000 (UTC) Received: from hq-edge-02.wardrobe.irobot.com (66.238.211.235) by TX2EHSMHS015.bigfish.com (10.9.99.115) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 19 Mar 2014 12:05:01 +0000 Received: from hq-cas-01.wardrobe.irobot.com (192.168.172.181) by hq-edge-02.wardrobe.irobot.com (10.70.6.42) with Microsoft SMTP Server (TLS) id 14.2.347.0; Wed, 19 Mar 2014 08:04:18 -0400 Received: from hq-mbx-02.wardrobe.irobot.com ([fe80::1cd:dd22:52a4:4eb3]) by hq-cas-01.wardrobe.irobot.com ([192.168.172.181]) with mapi id 14.02.0347.000; Wed, 19 Mar 2014 08:04:19 -0400 From: "Radouch, Zdenek" To: Alan Modra CC: "Paul_Koning@Dell.com" , "binutils@sourceware.org" Subject: RE: extract ELF load address with binutils? Date: Wed, 19 Mar 2014 12:05:00 -0000 Message-ID: <7ADBB2DB4DC7CF4CB641E9ADA826E5E2E1FC30E1@hq-mbx-02.wardrobe.irobot.com> References: <7ADBB2DB4DC7CF4CB641E9ADA826E5E2AAC571BC@HQ-MBX-01.wardrobe.irobot.com> <7ADBB2DB4DC7CF4CB641E9ADA826E5E2E1FBDF7F@hq-mbx-02.wardrobe.irobot.com> <7ADBB2DB4DC7CF4CB641E9ADA826E5E2E1FC0FF6@hq-mbx-02.wardrobe.irobot.com> <7ADBB2DB4DC7CF4CB641E9ADA826E5E2E1FC2052@hq-mbx-02.wardrobe.irobot.com> <7ADBB2DB4DC7CF4CB641E9ADA826E5E2E1FC207A@hq-mbx-02.wardrobe.irobot.com>,<20140318234418.GC9145@bubble.grove.modra.org> In-Reply-To: <20140318234418.GC9145@bubble.grove.modra.org> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: irobot.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-SW-Source: 2014-03/txt/msg00200.txt.bz2 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-relat= ed pading" and now I've been corrected -- it's not "padding" :-)). What I am after is improving the back end of the embedded development proce= ss, 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 diff= erently 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 projec= ts.=20 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 "ca= rried along" with the object file. I do know that all of the necessary info is in the ELF fil= e, objcopy knows that, too, and successfully extracts the data, the only problem is that obj= copy is silent about what it did. So my question is: Can I get the load address (i.e., the address corresponding to the first se= ction 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 qu= estion 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 loade= d 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