public inbox for ecos-devel@sourceware.org
 help / color / mirror / Atom feed
From: Gary Thomas <gary@mlbassoc.com>
To: taiyun@sunnorth.com.cn
Cc: eCos Development <ecos-devel@ecos.sourceware.org>
Subject: Re: eCos with arm eabi compiler
Date: Wed, 12 Sep 2007 04:10:00 -0000	[thread overview]
Message-ID: <46E766C2.3010307@mlbassoc.com> (raw)
In-Reply-To: <OF85D24AD2.200A9EC6-ON48257354.0011E634-48257354.0011E63C@sunnorth.com.cn>

taiyun@sunnorth.com.cn wrote:
> Dear all:
> We are now porting eCos kernel to our platform, EVB named
> spaca556g(arm926ej-s). We choose a gcc4.2 eabi
> compiler(http://www.codesourcery.com/gnu_toolchains/arm/download.html). The
> reason of choosing this compiler is that an EABI compiler can be completely
> compatible with ARM RealView libraries. With this arm-eabi compiler,
> libraries built from realview can be used.
> But there are some problems using this eabi compiler. Because of different
> constructing method between arm-elf compiler and eabi compiler,
> constructors of global instances can't be invoked automatically when using
> the eabi compiler. As a result, we have to make changes to arm.ld and
> hal_misc.c files.
> 
> NOTE: arm-elf compiler use .ctor section and 2 labels(__CTOR_LIST__,
> __CTOR_END__) to invoke constructors, BUT arm-eabi compiler use .init_array
> section and lables(__init_array_start, __init_array_end)
> 
> arm-eabi compiler's linker script has different sections from arm-elf
> compiler's, e.g: .ARM.extab, .ARM.exidx and .ARM.attributes 0, these 3
> sections are own in arm-eabi compiler. These sections should be added to
> arm.ld, aren't they? If so, there are 2 ways to achieve this goal. One is
> making direct changes to arm.ld and adding corresponding sections'
> definitions. The other is setting up a new arch-eabi directory in hal/arm,
> which is only for arm-eabi compiler. Which is the best?

Add a CDL option to the ARM arch which controls this.  Then
you can have everything be automatic; compiler names (arm-elf-gcc
vs. arm-eabi-gcc, etc), linker script, how the constructors are
handled, etc.  The rest of the code should stay the same; it
will still be the same ARM hardware underneath.

n.b. if you were to split into an arm-eabi directory, I think there
would have to be *way* too much duplication (which inevitably leads
to code-rot)

BTW, in my mind, this is a development question (hence I changed
the mailing list).  The eCos maintainer list is for questions/issues
dealing with licensing, distribution, etc.


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

           reply	other threads:[~2007-09-12  4:10 UTC|newest]

Thread overview: expand[flat|nested]  mbox.gz  Atom feed
 [parent not found: <OF85D24AD2.200A9EC6-ON48257354.0011E634-48257354.0011E63C@sunnorth.com.cn>]

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=46E766C2.3010307@mlbassoc.com \
    --to=gary@mlbassoc.com \
    --cc=ecos-devel@ecos.sourceware.org \
    --cc=taiyun@sunnorth.com.cn \
    /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).