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,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.52.243.10 with SMTP id wu10mr32680769vdc.9.1433876269527; Tue, 09 Jun 2015 11:57:49 -0700 (PDT) X-Received: by 10.182.242.20 with SMTP id wm20mr134952obc.3.1433876269490; Tue, 09 Jun 2015 11:57:49 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!news.glorb.com!q107no229880qgd.0!news-out.google.com!n7ni5401igk.0!nntp.google.com!h15no646105igd.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Tue, 9 Jun 2015 11:57:49 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=105.210.1.171; posting-account=orbgeAkAAADzWCTlruxuX_Ts4lIq8C5J NNTP-Posting-Host: 105.210.1.171 References: <6d5f352b-d886-4cd4-8f88-4116fe34129a@googlegroups.com> <4bc35d01-158d-48bb-b241-d4e3c3ce4344@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <373a8c7e-8538-4de3-9647-dead707b8a88@googlegroups.com> Subject: Re: gnat compiler issues with a partial build From: jan.de.kruyf@gmail.com Injection-Date: Tue, 09 Jun 2015 18:57:49 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Xref: news.eternal-september.org comp.lang.ada:26241 Date: 2015-06-09T11:57:49-07:00 List-Id: On Tuesday, June 9, 2015 at 3:03:55 PM UTC+2, Mark Lorenzen wrote: > On Tuesday, June 9, 2015 at 1:28:01 PM UTC+2, jan.de...@gmail.com wrote: > > On Tuesday, June 9, 2015 at 12:21:28 PM UTC+2, Mark Lorenzen wrote: > > > On Thursday, June 4, 2015 at 1:12:27 PM UTC+2, jan.de...@gmail.com wr= ote: > > >=20 > > > > jan@janDell:~/MMS/programs-KERNEL/ec-master/obj$ nm memory_copy.o > > > > U __gnat_rcheck_CE_Access_Check > > > > 0000000000000000 T memcpy > > > > 0000000000000000 D memory_copy_E > > > > ------------------------------------- > > > >=20 > > > > They are all related to the Exception machinery and refer to about = 4 or 5 symbols in "Ada.Exeptions" in the standard "x86 Linux" runtime. > > > > They are caused by any construct where the compiler suspects that t= here might be a runtime error under certain conditions. And they have to do= with exception propagation I suspect, from looking at a disassembly. > > > > Now in an zfp runtime, any standard runtime references should be sw= itched off in the compiler, or else an alternative should be supplied in th= e custom runtime. But both ravenscar and zfp (ex Adacore) do not cater for = this eventuality. > > > >=20 > > > > Needless to say that I have been through all exception related prag= mas and restrictions. And I did make a 'gnat.adc' file that is duly noted i= n the project file. So that any pragmas are global. > > >=20 > > > I don't know what you are trying to achieve, but it seems to me, that= you want to build your module with a ZFP run-time that you don't have... > > >=20 > > > Can you build your module with run-time checks disabled? This should = ensure that the access check code is not emitted and therefore does not ref= er to the undefined symbol __gnat_rcheck_CE_Access_Check. > > >=20 > > > Regards, > > >=20 > > > MarkL > >=20 > > Any simple runtime is easily cooked, when you understand the gnat way o= f doing things. And yes I could compile with runtime checks disabled. But t= hen there are simpler ways of doing that (like programming in C)=20 > > The issue seems to me (and I could be mistaken of course) that there is= an anomaly in the compiler and/or the gnat ravenscar runtime and/or the do= cumentation.=20 > >=20 > > I am posting mostly to jog my own brains and to document a dark corner = in the process of kernelmodule building in Ada, since preciously little lit= erature is available. So yes, most definitely thanks for your contribution = :) Perhaps the light will shine someday. > >=20 > > cheers, > >=20 > > j. >=20 > I am using the GNAT Ravenscar runtime library on LEON3 and it works very = well and I cannot see that there is any anomaly in the compiler and/or runt= ime library. >=20 > It seems to me that you have cooked your own runtime library (a stripped = version of the full runtime library for Linux native) that simply does not = provide the subprograms (i.e. symbols) needed. If you choose to compile wit= h runtime checks enabled, then you must of course ensure that your runtime = library supports these checks. >=20 > Regards, >=20 > MarkL you would not see anything because as I said above your program will run un= til you call the undefined symbol. and that chance is very small. (Only whe= n you have been dumb that happens) But a kernel module will not load when there are undefined symbols, period. And perhaps ask, yes, how I cook my runtimes . . . It helps the discussion. cheers, j.