This is the mail archive of the mailing list for the newlib project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Configuring for bare hw ia32 PC's

Luke A. Guest wrote:
On Tue, 2008-05-13 at 08:49 -0500, Joel Sherrill wrote:
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
No need to have this. I'm going to be implementing my own tasking model,
so that when I come to port GNAT to work on top of my kernel, then I'll
have full Ada :D

Good luck.  Your tasking implementation has to match their
expectations on semantics or you can get some weird issues.
I remember them at one point depending on a particular
way threads got queued in a particular situation where I
didn't think POSIX was that specific.  And that's a defined
standard -- not just a random API.

I'm not saying it can't be done -- just the the Ada run-time
has its own assumptions and you will have to be careful.
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.

The IO is all based on POSIX calls, so open, close, read, write, etc.
We have all of that and newlib so I never bothered to care what
they call. :-D
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.

There are options that you can set inside, so I'd have to
create a runtime directory in my build tree and copy over the parts I
need. I would then modify the file to say what I want to
include in the runtime.
You can also put your own in the source tree
if you like.
I did actually do this already:

Nice so far.

FWIW RTEMS is in C. :-D

Out of curiousity, how big it your hello world?
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.

Ah, but I won't be using tasking so it shouldn't generate those either,
this is a flag in as well, IIRC.
There are lots of flags in there. :-D
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.

Yes, but don't you use gnatmake for your build? This requires a full toolset which you won't get until you've ported GNAT over to your OS for that platform. The way I did it was to use the cross tool i386-elf-gcc and ïi386-elf-gnatbind programs, I then link by hand.

Yes we use CPU-rtems-gnatmake for the build. Just takes
care to pass in the right -cargs, -largs, etc.

I don't see why you can't use gnatmake and gnatbind.  Just
a matter of getting the arguments right.


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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]