[PATCH] arm: add buildsys support for arm926ej-s

[Yann E. MORIN]

Bernhard, Carmelo, Khem, All,

On Wednesday 05 January 2011 092303 Bernhard Reutner-Fischer wrote:
> On Tue, Jan 04, 2011 at 09:30:21PM +0100, Carmelo Amoroso wrote:
> >On 04/01/11 20:41, Yann E. MORIN wrote:
> >> On Tuesday 04 January 2011 20:07:00 Khem Raj wrote:
> >>> On Tue, Jan 4, 2011 at 10:18 AM, Yann E. MORIN
> >>> <yann.morin.1998 at anciens.enib.fr> wrote:
> >>>> Back some time ago, it had been discussed that it was up to the user to
> >>>> properly configure his/her compiler to the desired target system:
> >> [--SNIp--]
> >>>> I'm ready to rebase this patchset in the near future (say, ready before
> >>>> FOSDEM) if that is still deemed a good way to go.
> >>> Please rebase and submit again. I will take a look at them
> >Fine. At least this patch was useful to reopen that old thread ;-)

Yes, it's been a while that I had been sitting on this, and that it was
lying somewhere on my HDD. I was always telling myself "OK, next WE,
I'll update it and resubmit", and then, I had other things to do, and
there it was yet postponed another week... Now, it on the rails, with
ARM mostly converted (see below).

> ISTR that SPARC was a bit tricky to get right.

And I was told at the time that this had been solved on IRC:
  http://lists.uclibc.org/pipermail/uclibc/2010-January/043546.html

<quote>
  I think what he means is that gcc doesn't provide explicit
  builtin_define's to let anyone but it know what version of the
  architecture is currently selected. So this breaks us selecting the
  correct optimized version of string and math functions.

  However after discussing on IRC, I think we can figure out what is
  selected implicitly via the builtin_define's it does provide to an
  acceptable level so that we won't break anything.
</quote>

I will dig in the archives when I'm back home tonight to see what the
discussed solution was.

> Overall we still want to 
> get rid of these mtune settings and rely on either the compiler to be
> bootstrapped with the correct --with-cpu and --with-tune or flags to be
> passed in via UCLIBC_EXTRA_CFLAGS.

And by the way... One for you, Khem:

For ARM we currently have a "use BX" option that when turned on uses BX to
return from functions. From what I understand, BX is "Branch and eXchange",
and is used to switch ARM <-> Thumb (based on low-order bits in the adress).
So I believe this is usefull only when doing interworking, right?

If the target is Arm-only mode, or Thumb-only mode, then there is no reason
to use BX at all (although in Thumb-only, this might be the only way). Care
to comment?

I was thinking in changing this as thus:
  [ ] Use BX (if available)
      help
        If available on your target processor, use BX to return from functions.
        Say 'y' if you need to use interworking. Say 'n' if not.
        It is safe to say 'y' even if you're not doing interworking.

And then detect availability of BX at build time, as per:
  http://lists.uclibc.org/pipermail/uclibc/2009-April/042301.html

On the other hand, if BX is only used in case we're interworking, then
we could/should rename the option to something like:
  [ ] Build interworking-safe functions.
      help
        Build a library whose functions are safe to call from interworking
        context. This will use BX to return from functions (if your target
        processor has it).

And in the code, detect if BX is available, and #error out if not and the
user asked interworking.

Any comments?

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +0/33 662376056 | Software  Designer | \ / CAMPAIGN     |   ^                |
| --==< O_o >==-- '------------.-------:  X  AGAINST      |  /e\  There is no  |
| http://ymorin.is-a-geek.org/ | (*_*) | / \ HTML MAIL    |  """  conspiracy.  |
'------------------------------'-------'------------------'--------------------'