public inbox for ecos-devel@sourceware.org
 help / color / mirror / Atom feed
From: Gary Thomas <gary@mlbassoc.com>
To: Bert Thomas <bert@brothom.nl>
Cc: eCos development <ecos-devel@ecos.sourceware.org>
Subject: Re: bug in RedBoot ELF loader?
Date: Wed, 07 Jun 2006 11:55:00 -0000	[thread overview]
Message-ID: <1149681284.15359.76.camel@hermes> (raw)
In-Reply-To: <44869E8E.7070407@brothom.nl>

On Wed, 2006-06-07 at 10:38 +0100, Bert Thomas wrote:
> > Of course - the headers are just that; descriptions of stuff to come
> > _later_ in the file.  A sane ELF file (files created by GNU ld behave
> > this way) will have the various section headers first, followed by
> > the actual program segments.  There is no need for a loader (like
> > RedBoot which is what started this discussion) to ever load the
> > headers as part of the image, rather only process them to figure
> > out what needs to be loaded and where.  For example, a RAM program
> 
> I aggree with you on the sanity part. However, I bet that most if not 
> all Linux executables have a segment that include the headers. I assume 
> you are working on a Linux machine. Could you try readelf on ls for 
> example?
> 
> Again, it is not that I disaggree with you. It is just that I observe it 
> isn't the way you and I expected it to be.
> 
> I suspect the reason that your example doesn't have a segment that 
> includes the headers has something to do with the linker script you 
> wrote to link that program.

Fair enough, but I don't care about Linux executables (at least,
not in this context).  RedBoot loads programs to run on embedded
systems (including Linux kernels) and every one to date was
organized in this [sane] fashion.

All of that aside, if the program segments are not laid out in
strictly one-direction (i.e. can be processed from the start
of the file to the end), then RedBoot's loader can't handle them
anyway since it has virtually no way to position randomly within
the "file".  Remember that the most common "file" is actually a
stream of data (X-Modem, TFTP, etc) and RedBoot cannot afford to
have an entire copy of it in memory, hence no random jumping about.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

  reply	other threads:[~2006-06-07 11:55 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-06 12:14 Bert Thomas
2006-06-06 14:53 ` David Vrabel
2006-06-06 17:23   ` Bert Thomas
2006-06-06 17:34     ` Gary Thomas
     [not found]       ` <4485EE86.9040909@brothom.nl>
     [not found]         ` <1149624902.15359.55.camel@hermes>
     [not found]           ` <4485F487.6080000@brothom.nl>
2006-06-06 20:49             ` Gary Thomas
2006-06-07  8:39               ` Bert Thomas
2006-06-07 11:55                 ` Gary Thomas [this message]
2006-06-07 10:04 Daly, Jeffrey

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=1149681284.15359.76.camel@hermes \
    --to=gary@mlbassoc.com \
    --cc=bert@brothom.nl \
    --cc=ecos-devel@ecos.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).