public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Erik Christiansen <dvalin@internode.on.net>
To: binutils@sourceware.org
Subject: Re: extract ELF load address with binutils?
Date: Wed, 19 Mar 2014 13:24:00 -0000	[thread overview]
Message-ID: <20140319132404.GA1915@ratatosk> (raw)
In-Reply-To: <7ADBB2DB4DC7CF4CB641E9ADA826E5E2E1FC30E1@hq-mbx-02.wardrobe.irobot.com>

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 <Your_start_address_symbol>),
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.

  reply	other threads:[~2014-03-19 13:24 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <7ADBB2DB4DC7CF4CB641E9ADA826E5E2AAC571BC@HQ-MBX-01.wardrobe.irobot.com>
     [not found] ` <m3a9i3s8s1.fsf@pepe.airs.com>
     [not found]   ` <7ADBB2DB4DC7CF4CB641E9ADA826E5E2E1FBDF7F@hq-mbx-02.wardrobe.irobot.com>
     [not found]     ` <m3siqgw32g.fsf@pepe.airs.com>
     [not found]       ` <7ADBB2DB4DC7CF4CB641E9ADA826E5E2E1FC0FF6@hq-mbx-02.wardrobe.irobot.com>
     [not found]         ` <m3k3brwvew.fsf@pepe.airs.com>
2014-03-18 17:02           ` Radouch, Zdenek
2014-03-18 17:13             ` Paul_Koning
2014-03-18 17:44               ` Radouch, Zdenek
2014-03-18 23:44                 ` Alan Modra
2014-03-19 12:05                   ` Radouch, Zdenek
2014-03-19 13:24                     ` Erik Christiansen [this message]
2014-03-20 18:12                     ` Radouch, Zdenek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140319132404.GA1915@ratatosk \
    --to=dvalin@internode.on.net \
    --cc=binutils@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).