This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: Configuring for bare hw ia32 PC's
Luke A. Guest wrote:
On Mon, 2008-05-12 at 14:17 -0400, Jonathan S. Shapiro wrote:
This is problematic with Ada as the language is huge and the compiler
adds some stuff into the code which references the runtime. Now, what
this stuff is, depends on what features you have available.
Then either the Ada compiler is busted or there is some command line
option that you need to add.
Er, no. This is the way that Ada works. There are parts of the language
which when compiled, the compiler adds in extra bits of support.
Right. It assumes a lot of things exist. For the tasking to
work, you need a lot. RTEMS uses the POSIX threads port
which by default assumes pthreads, mutexes, condition
variables and keys. The GNAT run-time also includes
a socket binding. The Ada run-time has a lot of nice
formatted IO support which I have no idea how it is
implemented in GNAT.
FWIW GNAT/RTEMS supports the full Ada tasking model
on a bare PC including file IO and sockets. I posted
ACATS results for i386, powerpc, sparc, and mips last week
to gcc-testresults. All looked very good. The i386 was on
qemu booting a raw elf image. The main issues there are
that qemu doesn't have accurate enough floating point to
make the tests happy.
If you disable the filesystem, about 300 of the ACATS tests
fail if I remember things right. They assume a filesystem.
Back up a second. You are, in effect, compiling Ada code to run on a
bare board. The "hosted" specification of the standard C library assumes
that you are running on top of an operating system. The "freestanding"
version does not.
It is okay if the Ada compiler emits things that rely on the
freestanding version of libc. Pragmatically, it is also okay if it
Do you mean, "is it?" I would say, no that's fine. I want a basic
runtime, just not the extra bits. Unfortunately, the way the GNAT source
is built, there doesn't seem (I could be wrong) to be a way to say, I
only want this and this and this, not that.
They used to and may still have a bare non-tasking configuration.
relies on a few additional, commonly provided OS procedures such as
memcpy. But if it relies on much more than that you have a fairly
fundamental disconnect in compilation models, and you need to consider
whether the Ada compiler is generating code for the appropriate model.
Given what you say above, I suspect that you need to start by turning
off every Ada feature that you can, and then see what is happening.
Can you give an example of what the Ada compiler is referencing that is
causing a problem? If possible, also state why the Ada compiler is
referencing this -- that is, is it being called from user-provided
source code, or is it being called from within the Ada runtime library?
As an example, say I have an array and I want to initialise it:
package Something is
...
private
type My_Array(1 .. 3) of Integer;
My_Instance : My_Array := (3, 5, 2);
end Something;
The initialisation code will generate a call to memcpy. This is
something I will most probably want to include in *my runtime*.
And it is not uncommon to find it automatically generating
calls to lock a run-time structure either.
Also, to actually get the gnat tools (e.g. gnatmake, gnatclean, etc) you
have to build the runtime. Also, I suspect that to get ASIS (which may
be necessary) you also need the runtime and the tools. :(
You can cross compile. That's what we do.
Thanks,
Luke.
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherrill@OARcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985