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

GNAT/RTEMS hassles with bit_ada




lange92 at 2067.resnet.uni.edu wrote:
> 
> Hello all,
> 
>    Well after applying the patch in the gnat-3.12p/src directory for
> gcc-281 (level p0), I managed to get the tools to compile. After that, I
> went on to build the i386-rtemself target and pc386 bsp.


If your ultimate target is the i386, then you will run into trouble
because in gcc 2.8.1 i386-rtems was coff.  i386-rtems is now elf.
The linker scripts are a bit different.  

> During the build
> of the bsp, I had to copy the files crti.o and crtn.o from "/usr/lib" on my
> system; crtbegin.o and crtend.o from "/usr/lib/gcc-lib/i686-pc-linux-gnu/2.8.1"
> to each of the sample test programs (hello, paranoia, ticker, unlimited,
> base_sp) built.

I recall doing a similar with some version of the native gnat binaries 
to make them work on some Linux hosts.

>   Having decided that I'd have to rewrite the Makefile for the
> hello_world_ada package, I chose the Makefile.score603e as a base
> makefile, made the changes at the top, and attempted to build it. The
> first time I received an error from gnatlink about the "-r" option, so
> after a quick removal of the "-bargs -r \" line from the Makefile, I
> compiled again, and received the following error:
> 
> i365-rtemself-gcc: file path prefix: `/users/lange92/illinoiscentral/rtems-i386/pc386//lib' never used
> init.o: In function `start_gnat_main':
> /users/lange92/illinoiscentral/tools/hello_world_ada/init.c:37: undefined reference to `gnat_main'
> i386-rtemself-gnatmake: *** link failed.
> make: *** [all] Error 4

There have been changes in how gnat deals with environments that do
not have a real main.
 
According to the 3.13p docs, you need a "-n" option and the RTEMS thread
starting the Ada application needs to call adainit and adafinal.  This
is
in the GNAT User's Guide.

> Again, I had to copy the files "crti.o crtn.o crtbegin.o crtend.o" to the
> hello_world_ada directory to perform a make this successful. Having to
> copy files from the base system makes me suspicious of an error in the
> installation. So this brings up a few questions:

Although it appears to be the same as what you did with the native
compiler
binary, it isn't.  You are including a native Linux crt* with embedded 
code and it should NOT be used with the RTEMS targets.  

The root problem is that the bsp_specs and linkcmds are setup for ELF.
I THINK you can simply remove the references to them in bsp_specs and
be OK.  This is because i386-rtems with gcc 2.8.1 is COFF!!!  i386-rtems
with gcc 2.9x and newer is ELF.  

GNAT hanging back with gcc 2.8.1 has really caused a disruption to
GNAT/RTEMS.  I eagerly await them releasing a gnat for use with gcc 3.0.
This will solve these weird issues and we will include Ada in the RPMs
as soon as we can.
 
>   1. should I have taken the time during/before/after running the bit_ada
> script to build the rts-fsu and rts-native thread libraries?

This is a native compiler issue.  Doesn't matter at all to the cross.


>   2. Question of documentation:
> http://www.oarcorp.com/rtems/releases/4.5.0/rtemsdoc-4.5.0/share/rtemsdoc/html/started_ada/started_ada00024.html
> "ENABLE_RTEMS_POSIX
>     is set to "yes" if you want to enable the RTEMS POSIX API
>     support. At this time, this feature is not supported by the
>     UNIX ports of RTEMS and is forced to "no" for those targets.
>     This corresponds to the configure option --enable-posix.
> 
>     This must be enabled to support the GNAT/RTEMS run-time."
> 
>   Would linux qualify, in this case, of a UNIX port? If so, does that
> mean that linux can't host GNAT/RTEMS? Should I switch to Cygwin or
> something that's better supported that can handle the POSIX API?

You are misreading this.  RTEMS is completely independent of Linux.
RTEMS can be built on any UNIX-ish environment.  RTEMS may or may not
be built with support for POSIX threads, mutexes, etc.  GNAT/RTEMS
assumes the underlying RTEMS was configured with --enable-posix.

The Linux environment is a great one to use as a host.

And remember -- no Linux code is in the RTEMS binary.

>    3. During the build of the tools (bit_ada) I still get errors about not
> finding the files regex.h, reg_types.h, and lc_core.h.

I don't know about this without more details.  

>    4. During the bit_ada script execution, twice the script flashed a
> message about the necessity of linking with the -LLIBDIR flag, and including
> the <toolsdir>/lib directory. Does the bit_rtems script handle this, or is
> it something I need to handle myself? I didn't see anything along these
> lines in any of the documentation.

This is just a general warning that it is putting libraries places you
normally wouldn't look for them.

>    5. Any recommendations on the ideal host environment for GNAT/RTEMS? I
> would imagine that I would be able to install Cygwin or whatever without
> any difficulties if I could get this runtime to function. It may be a good
> deal more difficult to set up than our old runtime, but that one doesn't
> have anywhere near the functionality that RTEMS appears to have.

Linux is great.

> Thanks again, for all the help and words of advice and inspiration. I
> appreciate it.
> 
> DanL

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985