From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: buffer1.nntp.dca1.giganews.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!goblin2!goblin.stu.neva.ru!newsfeed1.swip.net!81.169.171.211.MISMATCH!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: Simon Wright Newsgroups: comp.lang.ada Subject: Re: gnat compiler issues with a partial build Date: Thu, 11 Jun 2015 06:01:01 +0100 Organization: A noiseless patient Spider Message-ID: References: <6d5f352b-d886-4cd4-8f88-4116fe34129a@googlegroups.com> <4bc35d01-158d-48bb-b241-d4e3c3ce4344@googlegroups.com> <373a8c7e-8538-4de3-9647-dead707b8a88@googlegroups.com> <1e1e5cf8-5535-4e9f-9d85-261466ad9ce2@googlegroups.com> <295e0eb8-4779-4c72-ba98-3fb0c507640d@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: mx02.eternal-september.org; posting-host="2c7d8f71a176d2eaa78ec9fbd86e1d4a"; logging-data="22882"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX186IqeN4VHPW+ki1rgslboeV0T/5/mpwfY=" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (darwin) Cancel-Lock: sha1:PqAzWFUzVaT3d74ofj5XAt2hj5k= sha1:0fX6POGu2ZxGDiOr8PYTbQ/3w/M= Xref: number.nntp.giganews.com comp.lang.ada:193572 Date: 2015-06-11T06:01:01+01:00 List-Id: 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)).