Re: gnat compiler issues with a partial build

[Simon Wright <simon@pushface.org>]

jan.de.kruyf@gmail.com writes:

> On Wednesday, June 10, 2015 at 7:01:26 PM UTC+2, Simon Wright wrote:
>> 
>> > You need to be careful about the Ada features you use in the RTS. Stick
>> > to Ada95, only include packages under Ada, Interfaces, and GNAT.
>> 
>> and of course System.
>
> Yes Simon, but this is not where the problem originates. Sure this is
> how it should be done once a person gets there, but at the moment I am
> still trying to find out how to proceed from "bare metal Ada" with no
> runtime at all to some small runtime that will work in the kernel.
>
> So for the time being I have the "runtime" as part of the project and
> I basically use the ada compiler as a "small language compiler"
> without all the trappings.

In my opinion, this approach is *exactly* why you are having problems.

> Now the gnat compiler looks for certain symbols (read: routines to
> call) when it is compiling. Example: for NEW it needs "__gnat_malloc"
> to get some memory from the pool or heap.
> So there will a 'U __gnat_malloc' in the object file for any package
> where you asked for 'NEW'
>
> In your runtime the 'System.Memory' package  has 
> pragma Export (C, Alloc, "__gnat_malloc");
>
> And in the final full linking phase these two are matched, and your
> program will call that routine when it needs memory off the heap.

Yes, and the compiler checks in the runtime it is building against
whether s-memory.ads is present and contains the expected features
(Alloc etc).

If you build using an RTS framework, it will either use the version it
finds inside the RTS you build against or the compilatin will fail.

Since you aren't doing that, the compiler looks at the code you are
working on, including the parts that should be in the RTS. If it doesn't
find what it wants there, it will look in the RTS it is in fact compiling
against, which in your case is the Linux GNAT GPL 2014 RTS, and generate
code that expects to find those features at link time. And since your
eventual link is in a kernel module context, it doesn't find them.

I can see two routes:

(1) use pragma Restrictions (No_Allocators), which prevents use of
'new', and write your own bindings to kalloc() etc. I think
No_Allocators prevents all allocations, but to be sure you might also
use the other allocation-related restrictions, for example
No_Implicit_Heap_Allocations.

(2) work in an RTS framework, as I have described, and write your own
System.Memory. I think you can get away with the standard spec and just
modify the body (to use the same bindings as you'd have written for
(1)).