From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19822 invoked by alias); 19 Mar 2014 13:24:10 -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 19810 invoked by uid 89); 19 Mar 2014 13:24:09 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: ipmail06.adl6.internode.on.net Received: from ipmail06.adl6.internode.on.net (HELO ipmail06.adl6.internode.on.net) (150.101.137.145) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 19 Mar 2014 13:24:07 +0000 Received: from ppp118-209-96-193.lns20.mel4.internode.on.net (HELO ratatosk) ([118.209.96.193]) by ipmail06.adl6.internode.on.net with ESMTP; 19 Mar 2014 23:54:05 +1030 Received: by ratatosk (Postfix, from userid 1000) id 3ED4660729; Thu, 20 Mar 2014 00:24:05 +1100 (EST) Date: Wed, 19 Mar 2014 13:24:00 -0000 From: Erik Christiansen To: binutils@sourceware.org Subject: Re: extract ELF load address with binutils? Message-ID: <20140319132404.GA1915@ratatosk> Reply-To: dvalin@internode.on.net References: <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> <7ADBB2DB4DC7CF4CB641E9ADA826E5E2E1FC30E1@hq-mbx-02.wardrobe.irobot.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <7ADBB2DB4DC7CF4CB641E9ADA826E5E2E1FC30E1@hq-mbx-02.wardrobe.irobot.com> User-Agent: Mutt/1.5.21+145 (2a1c5d3dd72e) (2012-12-30) X-IsSubscribed: yes X-SW-Source: 2014-03/txt/msg00202.txt.bz2 On 19.03.14 12:04, Radouch, Zdenek wrote: > 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 ... > 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: Since you can run a script at the programming site, is there any reason not to just send the elf file, so the script can extract address(es), (E.g. from "objdump -h xxx.elf" and a line or two of awk, or nm xxx.elf | grep ), as well as run the "objcopy -O binary"? For myself, I've always just sent intel or motorola hex files for loading to the platform - then the load address is also included, though not so easily human-readable. (But the programming tools handle it without human intervention, since that's what these formats are for.) Erik -- "No one, however smart, however well-educated, however experienced, is the suppository of all wisdom." - Tony Abbott, then Australian opposition leader, now PM.