From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20563 invoked by alias); 18 Mar 2014 17:44:24 -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 20549 invoked by uid 89); 18 Mar 2014 17:44:23 -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: co9outboundpool.messaging.microsoft.com Received: from co9ehsobe003.messaging.microsoft.com (HELO co9outboundpool.messaging.microsoft.com) (207.46.163.26) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Tue, 18 Mar 2014 17:44:20 +0000 Received: from mail7-co9-R.bigfish.com (10.236.132.233) by CO9EHSOBE012.bigfish.com (10.236.130.75) with Microsoft SMTP Server id 14.1.225.22; Tue, 18 Mar 2014 17:44:18 +0000 Received: from mail7-co9 (localhost [127.0.0.1]) by mail7-co9-R.bigfish.com (Postfix) with ESMTP id CF70A120240; Tue, 18 Mar 2014 17:44:18 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.238.211.235;KIP:(null);UIP:(null);IPV:NLI;H:hq-edge-01.wardrobe.irobot.com;RD:66.238.211.235.ptr.us.xo.net;EFVD:NLI X-SpamScore: -3 X-BigFish: VPS-3(zz98dI9371I542Izz1f42h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1de098h8275bh8275dh1de097hz2dh109h2a8h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h1b0ah2222h224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h2216h22d0h2336h2438h2461h2487h24ach24d7h2516h2545h255eh25f6h2605h262fh2668h1155h) Received: from mail7-co9 (localhost.localdomain [127.0.0.1]) by mail7-co9 (MessageSwitch) id 1395164656826111_4499; Tue, 18 Mar 2014 17:44:16 +0000 (UTC) Received: from CO9EHSMHS014.bigfish.com (unknown [10.236.132.254]) by mail7-co9.bigfish.com (Postfix) with ESMTP id AF6D54C010C; Tue, 18 Mar 2014 17:44:16 +0000 (UTC) Received: from hq-edge-01.wardrobe.irobot.com (66.238.211.235) by CO9EHSMHS014.bigfish.com (10.236.130.24) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 18 Mar 2014 17:44:14 +0000 Received: from hq-cas-02.wardrobe.irobot.com (192.168.172.182) by hq-edge-01.wardrobe.irobot.com (10.70.6.41) with Microsoft SMTP Server (TLS) id 14.2.347.0; Tue, 18 Mar 2014 13:44:11 -0400 Received: from hq-mbx-02.wardrobe.irobot.com ([fe80::1cd:dd22:52a4:4eb3]) by hq-cas-02.wardrobe.irobot.com ([192.168.172.182]) with mapi id 14.02.0347.000; Tue, 18 Mar 2014 13:44:12 -0400 From: "Radouch, Zdenek" To: "Paul_Koning@Dell.com" CC: "binutils@sourceware.org" Subject: RE: extract ELF load address with binutils? Date: Tue, 18 Mar 2014 17:44:00 -0000 Message-ID: <7ADBB2DB4DC7CF4CB641E9ADA826E5E2E1FC207A@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> In-Reply-To: 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/msg00187.txt.bz2 But as I (and objcopy) have illustrated: 1. Not all LOAD types get loaded 2. The address where the segment is loaded can be "wrong", when the loaded = segment has been padded. I agree about the multiple segments, but I can't make it work even for one. The padding clearly comes from the non-embedded world where throwing away 3= 2k of memory may be OK; I don't have that luxury. Objcopy says: "When objcopy generates a raw binary file, it will essentially produce a me= mory dump of the contents of the input object file." Memory dump is what I want, to m= e "undumping" the dump is synonymous with loading the right data in the right place in me= mory.=20 It is my understanding that the LOAD segment itself can contain an ELF head= er so it can be loaded without additional metadata. I have no idea how (or whether) = I can make readelf give me the actual data to be loaded.=20 That's where I see a big difference between objcopy and readelf. -Z =20 -----Original Message----- From: Paul_Koning@Dell.com [mailto:Paul_Koning@Dell.com]=20 Sent: Tuesday, March 18, 2014 1:13 PM To: Radouch, Zdenek Cc: binutils@sourceware.org Subject: Re: extract ELF load address with binutils? On Mar 18, 2014, at 1:02 PM, Radouch, Zdenek wrote: > I am writing a firmware updater that takes an ELF executable and needs=20 > to extract the RAM data and the address to where the data should be loade= d. ... > The question is can I somehow convince one of the binutils to give me=20 > the load address alone, so that I don't have to invent an algorithm extra= cting the address from the section dump? I'm not sure the notion of "THE load address" makes sense. It may be valid= for your specific case, but not in general. ELF files can have multiple l= oad sections, each of which has a load address. Normally I would say: look in the program headers. Each header of type LOA= D describes something that's loaded, and it shows the addresses. paul