From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13278 invoked by alias); 18 Mar 2014 17:02:43 -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 13261 invoked by uid 89); 18 Mar 2014 17:02:42 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 X-HELO: ch1outboundpool.messaging.microsoft.com Received: from ch1ehsobe004.messaging.microsoft.com (HELO ch1outboundpool.messaging.microsoft.com) (216.32.181.184) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Tue, 18 Mar 2014 17:02:37 +0000 Received: from mail182-ch1-R.bigfish.com (10.43.68.254) by CH1EHSOBE002.bigfish.com (10.43.70.52) with Microsoft SMTP Server id 14.1.225.22; Tue, 18 Mar 2014 17:02:35 +0000 Received: from mail182-ch1 (localhost [127.0.0.1]) by mail182-ch1-R.bigfish.com (Postfix) with ESMTP id 30E4B2A0255 for ; Tue, 18 Mar 2014 17:02:35 +0000 (UTC) X-Forefront-Antispam-Report: CIP:107.0.224.235;KIP:(null);UIP:(null);IPV:NLI;H:hq-edge-01.wardrobe.irobot.com;RD:107-0-224-235-ip-static.hfc.comcastbusiness.net;EFVD:NLI X-SpamScore: 2 X-BigFish: VPS2(zz4015I853kzz1f42h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1de097hz2dh109h2a8h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h1b0ah2222h224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h2216h22d0h2336h2438h2461h2487h24ach24d7h2516h2545h255eh25f6h2605h262fh2668h1155h) Received: from mail182-ch1 (localhost.localdomain [127.0.0.1]) by mail182-ch1 (MessageSwitch) id 1395162153963995_26634; Tue, 18 Mar 2014 17:02:33 +0000 (UTC) Received: from CH1EHSMHS019.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.245]) by mail182-ch1.bigfish.com (Postfix) with ESMTP id DB39B4A00E3 for ; Tue, 18 Mar 2014 17:02:33 +0000 (UTC) Received: from hq-edge-01.wardrobe.irobot.com (107.0.224.235) by CH1EHSMHS019.bigfish.com (10.43.70.19) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 18 Mar 2014 17:02:32 +0000 Received: from hq-cas-01.wardrobe.irobot.com (192.168.172.181) 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:02:31 -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; Tue, 18 Mar 2014 13:02:32 -0400 From: "Radouch, Zdenek" To: "binutils@sourceware.org" Subject: extract ELF load address with binutils? Date: Tue, 18 Mar 2014 17:02:00 -0000 Message-ID: <7ADBB2DB4DC7CF4CB641E9ADA826E5E2E1FC2052@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> 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/msg00185.txt.bz2 I am writing a firmware updater that takes an ELF executable and needs to e= xtract the RAM data and the address to where the data should be loaded. I create the data chunk= with objcopy -O binary, and need the address of the first section that went into that chunk. I'd li= ke to do that from a shell script invoking binutils (rather than writing my own version o= f a binutil), but can't figure out how. My first intuitive solution "readelf -l" does not= work at all. Here is an example file (b2.axf) I get from my vendor. [the file represents a RAM image with 3032 bytes @ 0x15f000] =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 $ file b2.axf=20=20=20=20=20=20=20=20=20=20=20=20=20 b2.axf: ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically linked= , not stripped $ arm-none-eabi-size b2.axf text data bss dec hex filename 3028 4 2052 5084 13dc b2.axf $ arm-none-eabi-objcopy -O binary b2.axf xxx $ wc -c xxx 3032 xxx $=20=20=20=20=20 So far, all is well. I got my 3032-byte chunk of data and confirmed its size (3028 text + 4 data). The question is where is this chunk loaded? $ arm-none-eabi-readelf -l b2.axf Elf file type is EXEC (Executable file) Entry point 0x15f001 There are 2 program headers, starting at offset 52 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x000000 0x00158000 0x00158000 0x07bd8 0x07bd8 RWE 0x8000 LOAD 0x00f000 0x2001f000 0x2001f000 0x00000 0x00804 RW 0x8000 Section to Segment mapping: Segment Sections... 00 .text .data=20 01 .bss .main_stack=20 $=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20 I don't understand the purpose of this output; it appears (certainly from t= he loading perspective) wrong, as the second segment should not be loaded at all, and = the first one includes some 28k of alignment-related padding loaded at addresses that= may not even exist (0x158000) within the hardware. Clearly, the ELF file has what I need: the Addr field of the .text section = ([1]) is the load address. See below =20=20 $=20 $ arm-none-eabi-readelf -S b2.axf There are 18 section headers, starting at offset 0x246a4: Section Headers: [Nr] Name Type Addr Off Size ES Flg Lk I= nf Al [ 0] NULL 00000000 000000 000000 00 0 = 0 0 [ 1] .text PROGBITS 0015f000 007000 000bd4 00 AX 0 = 0 4 [ 2] .data PROGBITS 0015fbd4 007bd4 000004 00 WA 0 = 0 4 [ 3] .bss NOBITS 2001f000 00f000 000004 00 WA 0 = 0 4 [ 4] .main_stack NOBITS 2001f004 00f000 000800 00 WA 0 = 0 1 [ 5] .debug_info PROGBITS 00000000 007bd8 00e4e3 00 0 = 0 1 [ 6] .debug_abbrev PROGBITS 00000000 0160bb 001a2a 00 0 = 0 1 [ 7] .debug_loc PROGBITS 00000000 017ae5 002e67 00 0 = 0 1 [ 8] .debug_aranges PROGBITS 00000000 01a94c 000690 00 0 = 0 1 [ 9] .debug_ranges PROGBITS 00000000 01afdc 000688 00 0 = 0 1 [10] .debug_line PROGBITS 00000000 01b664 0025eb 00 0 = 0 1 [11] .debug_str PROGBITS 00000000 01dc4f 005aeb 01 MS 0 = 0 1 [12] .comment PROGBITS 00000000 02373a 000030 01 MS 0 = 0 1 [13] .ARM.attributes ARM_ATTRIBUTES 00000000 02376a 000033 00 0 = 0 1 [14] .debug_frame PROGBITS 00000000 0237a0 000e4c 00 0 = 0 4 [15] .shstrtab STRTAB 00000000 0245ec 0000b7 00 0 = 0 1 [16] .symtab SYMTAB 00000000 024974 000bf0 10 17 1= 42 4 [17] .strtab STRTAB 00000000 025564 0003aa 00 0 = 0 1 Key to Flags: W (write), A (alloc), X (execute), M (merge), S (strings) I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown) O (extra OS processing required) o (OS specific), p (processor specific) $=20=20=20=20=20=20 The question is can I somehow convince one of the binutils to give me the l= oad address alone, so that I don't have to invent an algorithm extracting the address from the= section dump? Thanks, -Z