public inbox for ecos-maintainers@sourceware.org
 help / color / mirror / Atom feed
From: John Dallaway <john@dallaway.org.uk>
To: Jonathan Larmour <jifl@ecoscentric.com>
Cc: ecos-maintainers@sourceware.org
Subject: Re: update ARM platform HALs
Date: Tue, 27 Jan 2009 12:41:00 -0000	[thread overview]
Message-ID: <497F00F5.6070306@dallaway.org.uk> (raw)
In-Reply-To: <497EF9B6.2030009@eCosCentric.com>

Jifl

Jonathan Larmour wrote:

> John Dallaway wrote:
>
>> Jonathan Larmour wrote:
>>
>>> John Dallaway wrote:
>>>
>>>> The eCosCentric arm-eabi pre-built toolchains do not include StrongARM
>>>> multi-libs. AFAIK, users who want to build eCos for these targets will
>>>> therefore need to either build their own arm-eabi-gcc or revert to
>>>> CYGBLD_GLOBAL_COMMAND_PREFIX == "arm-elf" and use the older arm-elf-gcc
>>>> 3.2.1. Can you please let me know what the intention is here so I can
>>>> mention this in the eCos 3.0 release notes?
>>>
>>> This was discussed before IRL, and I believe until I hear to the
>>> contrary that strongarm should probably still work. It just won't be
>>> perfectly optimal as it will fall back to the arm7tdmi multilib (the
>>> default); but now actually looking at GCC sources, I think it may have
>>> only a virtually perceptible effect even then.
>>
>> IIRC, Bart observed a SIGTRAP in libgcc (udivsi3?) when running up eCos
>> built with arm-eabi-gcc 4.3.2 on the ipaq target. So perhaps users would
>> be better off sticking with arm-elf-gcc 3.2.1 for StrongARM? I'm not
>> proposing that we spend any further time investigating the problem, just
>> seeking clarification as to what we should recommend to users.
> 
> Well, I've had a closer look, and indeed the prebuilt tools won't just
> work after all, because, even if thumb interworking is disabled, gcc
> uses ARMv4t insns like 'bx', which aren't available on strongarm's ARMv4.
> 
> If people want to use strongarm, they can indeed either use the older
> tools, or rebuild the current tools with strongarm multilibs added.

OK. Thanks for the clarification.

> Of course, I don't expect anyone to be using strongarm in new designs as
> they've been discontinued.

Yes, I appreciate that this is unlikely to affect many users. The set of
multi-libs in the pre-built arm-eabi tools seems perfectly reasonable
for eCos in 2009.

John Dallaway

      reply	other threads:[~2009-01-27 12:41 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <pny6wyx7p8.fsf@delenn.bartv.net>
2009-01-27  9:21 ` John Dallaway
2009-01-27 10:26   ` Jonathan Larmour
2009-01-27 10:33     ` Gary Thomas
2009-01-27 10:41       ` Jonathan Larmour
2009-01-27 11:16     ` John Dallaway
2009-01-27 11:35       ` Bart Veer
2009-01-27 12:10       ` Jonathan Larmour
2009-01-27 12:41         ` John Dallaway [this message]

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=497F00F5.6070306@dallaway.org.uk \
    --to=john@dallaway.org.uk \
    --cc=ecos-maintainers@sourceware.org \
    --cc=jifl@ecoscentric.com \
    /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).