[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Ada support in current RTEMS versions ?



On 05/25/2011 06:37 AM, Ralf Corsepius wrote:
> On 05/25/2011 01:14 PM, Simon Clubley wrote:
>> I noticed in another message Joel posted (about ARM multilib not
>> building on head) that his configure flags included dsabling Ada
>> support.
>>
I was testing GCC's head.  Building RTEMS multilib and
installing it puts the .h files in places where the various
gcc scripts and probes can see them.

When building multilib, it builds for a LONG time so as part
of the tool building cycle for Ada and Go, you install
RTEMS multilib for various posix and networking .h files,
then install the BSP with real options for actual testing.
The test  sequence is something like this:

+ build native for C, C++, and Ada
+ for each RTEMS target being tested
     - binutils
     - gdb
     - GCC C/C++ with newlib
     - run C/C++ tests
     - RTEMS multilib
     - RTEMS for BSP used for testing
     - GCC Ada
     - run GCC Ada tests
     - GCC Go
     - run GCC Go tests

I was actually trying to test a fix for a GCC Ada ARM PR I filed
on the head but wasn't able to build enough to test. :(
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48971

That one eventually also showed up on GNU/Linux.
>> Is this due to Ada's long standing problems with multilib support or
>> does Ada in general have problems in current RTEMS versions ?
> It's a bit of both with an emphasize on the former: Ada has long
> standing problems with multilibs and probably hardly anybody but Joel is
> actively supporting it.
>
Yes.  I am the person in the RTEMS community who
devotes the most time to it.  I gave GNAT/RTEMS tutorials
at the past two ACM SIGAda conferences.

It is part of my testing cycle on gcc which now includes C,
C++, Ada, and Go.  I am (slowly) tinkering with Objective-C and
it looks like it all the non-tasking tests are passing on RTEMS
now.  The rest is a matter of providing a more complete
gthr-rtems.h in RTEMS.

So Ada gets tested and bugs reported on any platform
that will build it.  This includes SPARC, ARM, MIPS, PowerPC,
m68k, and i386.
> The premiere issue with Ada however is still building the toolchain.
>
It has built its libraries multilib for multiple gcc releases.  That
was one of your biggest complaints about Ada.

It is built different from C and C++ because it is written in Ada
so you have to have a native Ada compiler.  Also, like Go, it
requires RTEMS to be built and installed multilib so thelanguage
run-time build process can find the networking .h files (and
maybe others).
>> (I'm probably going to write a new BSP in a month or two and as I am
>> currently using RTEMS 4.9.2, I am thinking about moving forward to a
>> more recent RTEMS version at the same time.)
> Independently of Ada (The Ada issues basically are the same with both
> versions), I'd recommend to use at least RTEMS-4.10 (or even CVS-HEAD)
> for new developments, because the rtems-4.9.x series is "in deep freeze".
>
Definitely agree there.  Don't jump to the head for this unless
something forces you to. A couple of cases I know where you
would end up on the head are for a new CPU model which is only
supported on the head, you might have to use the head.
You require a feature which is only supported on the head.

Hopefully neither apply.
> Ralf
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users