gnat compiler issues with a partial build

gnat compiler issues with a partial build

[jan.de.kruyf]

Hallo,
Back from working hard :)

First the good news: I was able to load and unload a mixed C and Ada kernel module last night for the first time.

But I think I found a subtle problem in the compiler (gnat-gcc 4.7.4) while doing my Linux kernel module.

I have been struggling for a while already with undefined random symbols turning up in the symbol list of the partial Ada compile. And these then progress to the module into the final build and link. (with the kernel module build machinery, this is why I do a partial link of the Ada stuff).

So last night they had all disappeared, but this morning after adding a totally irrelevant module (sort of a little "hallo world" thing) one of them was back in a total different place, like this: (this is from the standard memory_copy in any runtime)
-------------------------------------
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
-------------------------------------

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 there 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 switched off in the compiler, or else an alternative should be supplied in the custom runtime. But both ravenscar and zfp (ex Adacore) do not cater for this eventuality.

Needless to say that I have been through all exception related pragmas and restrictions. And I did make a 'gnat.adc' file that is duly noted in the project file. So that any pragmas are global.

Other than that I have been through all the target parameters in the private part of the System package in the runtime.
By the way the documentation for those things is in "targparm.ads" in the gcc source.

The bottom line is that, no-matter what I all switch off, the compiler sometimes emits random subroutine calls in its error detection section. Normally they don't bite you, because you would almost never hit them in a well constructed program. But a kernel module with those simply will not load; end.

The only vague reference to such a scenario might be in the "-gnatp" description in the gnat_ug.

So if any of the compiler theologians has any light on this: please feel welcome to comment.

Besides that, I think I must just construct some dummy procedures for those symbols, that put the  module into eternal sleep, with a message of course.

Thanks,

j.

Re: gnat compiler issues with a partial build

[Lucretia]

This is the gnat.adc I used for bare_bones kernel https://github.com/Lucretia/bare_bones/blob/master/gnat.adc

Luke.

Re: gnat compiler issues with a partial build

[jan.de.kruyf]

Morning Luke,
I just went through you .adc again just to make sure, but any Exceptions restrictions there I also got in my list. And I do not see any others that, even vaguely, might apply.
I did not restrict myself as much as you did. If a library package is easy to implement in a zfp environment then I did so, if I felt I needed it. 
The issue at the moment (because I did not code anything complex yet) is mostly in the system memory packages, which I need one way or another to be able to get kernel memory for some big data structures. There are some rough and ready things being done there. Mainly to get the hardware / C interfacing right.

Thanks for your reply anyway.

j.

Re: gnat compiler issues with a partial build

[Mark Lorenzen]

On Thursday, June 4, 2015 at 1:12:27 PM UTC+2, jan.de...@gmail.com wrote:

> 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
> -------------------------------------
> 
> 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 there 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 switched off in the compiler, or else an alternative should be supplied in the custom runtime. But both ravenscar and zfp (ex Adacore) do not cater for this eventuality.
> 
> Needless to say that I have been through all exception related pragmas and restrictions. And I did make a 'gnat.adc' file that is duly noted in the project file. So that any pragmas are global.

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...

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 refer to the undefined symbol __gnat_rcheck_CE_Access_Check.

Regards,

MarkL

Re: gnat compiler issues with a partial build

[jan.de.kruyf]

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 wrote:
> 
> > 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
> > -------------------------------------
> > 
> > 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 there 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 switched off in the compiler, or else an alternative should be supplied in the custom runtime. But both ravenscar and zfp (ex Adacore) do not cater for this eventuality.
> > 
> > Needless to say that I have been through all exception related pragmas and restrictions. And I did make a 'gnat.adc' file that is duly noted in the project file. So that any pragmas are global.
> 
> 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...
> 
> 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 refer to the undefined symbol __gnat_rcheck_CE_Access_Check.
> 
> Regards,
> 
> MarkL

Any simple runtime is easily cooked, when you understand the gnat way of doing things. And yes I could compile with runtime checks disabled. But then there are simpler ways of doing that (like programming in C) 
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 documentation. 

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 literature is available. So yes, most definitely thanks for your contribution :) Perhaps the light will shine someday.

cheers,

j.

Re: gnat compiler issues with a partial build

[Mark Lorenzen]

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 wrote:
> > 
> > > 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
> > > -------------------------------------
> > > 
> > > 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 there 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 switched off in the compiler, or else an alternative should be supplied in the custom runtime. But both ravenscar and zfp (ex Adacore) do not cater for this eventuality.
> > > 
> > > Needless to say that I have been through all exception related pragmas and restrictions. And I did make a 'gnat.adc' file that is duly noted in the project file. So that any pragmas are global.
> > 
> > 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...
> > 
> > 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 refer to the undefined symbol __gnat_rcheck_CE_Access_Check.
> > 
> > Regards,
> > 
> > MarkL
> 
> Any simple runtime is easily cooked, when you understand the gnat way of doing things. And yes I could compile with runtime checks disabled. But then there are simpler ways of doing that (like programming in C) 
> 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 documentation. 
> 
> 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 literature is available. So yes, most definitely thanks for your contribution :) Perhaps the light will shine someday.
> 
> cheers,
> 
> j.

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 runtime library.

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 with runtime checks enabled, then you must of course ensure that your runtime library supports these checks.

Regards,

MarkL

Re: gnat compiler issues with a partial build

[jan.de.kruyf]

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 wrote:
> > > 
> > > > 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
> > > > -------------------------------------
> > > > 
> > > > 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 there 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 switched off in the compiler, or else an alternative should be supplied in the custom runtime. But both ravenscar and zfp (ex Adacore) do not cater for this eventuality.
> > > > 
> > > > Needless to say that I have been through all exception related pragmas and restrictions. And I did make a 'gnat.adc' file that is duly noted in the project file. So that any pragmas are global.
> > > 
> > > 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...
> > > 
> > > 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 refer to the undefined symbol __gnat_rcheck_CE_Access_Check.
> > > 
> > > Regards,
> > > 
> > > MarkL
> > 
> > Any simple runtime is easily cooked, when you understand the gnat way of doing things. And yes I could compile with runtime checks disabled. But then there are simpler ways of doing that (like programming in C) 
> > 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 documentation. 
> > 
> > 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 literature is available. So yes, most definitely thanks for your contribution :) Perhaps the light will shine someday.
> > 
> > cheers,
> > 
> > j.
> 
> 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 runtime library.
> 
> 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 with runtime checks enabled, then you must of course ensure that your runtime library supports these checks.
> 
> Regards,
> 
> MarkL

you would not see anything because as I said above your program will run until you call the undefined symbol. and that chance is very small. (Only when 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.

Re: gnat compiler issues with a partial build

[Mark Lorenzen]

On Tuesday, June 9, 2015 at 8:57:51 PM UTC+2, jan.de...@gmail.com wrote:

> you would not see anything because as I said above your program will run until you call the undefined symbol. and that chance is very small. (Only when 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.

I just checked using the nm utility (leon3-elf-nm) and there are no undefined symbols in the executable when building with the GNAT Ravenscar runtime library (otherwise it of course would'nt succeed to link), so I still think you must be configuring your runtime wrong.

Regards,

MarkL

Re: gnat compiler issues with a partial build

[jan.de.kruyf]

On Wednesday, June 10, 2015 at 12:11:43 PM UTC+2, Mark Lorenzen wrote:
> On Tuesday, June 9, 2015 at 8:57:51 PM UTC+2, jan.de...@gmail.com wrote:
> 
> > you would not see anything because as I said above your program will run until you call the undefined symbol. and that chance is very small. (Only when 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.
> 
> I just checked using the nm utility (leon3-elf-nm) and there are no undefined symbols in the executable when building with the GNAT Ravenscar runtime library (otherwise it of course would'nt succeed to link), so I still think you must be configuring your runtime wrong.
> 
> Regards,
> 
> MarkL

I will follow that up Mark, on the stm32 Arm board and Ravenscar, but that _is_ 
a different compiler in the sense that it is a cross compiler. I am working native.

In any case: the runtime cooking business is like this (in its most basic form)
1. extract something very basic from ravenscar or zfp.
2. compile little test programs with (1) in a subdirectory and no libraries.
3. run nm to look for 'U' symbols. and use grep to find where they originate and where they are defined in any runtime.
4. Then adapt that piece of code where they are defined, one way or another, to you new runtime.
   Normally of course either ravenscar or zfp will have a piece of code that   fits without hacking too much. 
only for heap memory I had to modify s-memory quite a bit to fit the kernel environment so it is all strictly controlled and not pageable. (one of my requirements)
5. repeat 2,3,4 until satisfied that it is usable now. Then you can build the runtime subdirectory into a runtime library.

So in that process I discovered those pesky undefined symbols, that _should_ disappear with some compiler switch, either in System.ads or on the command line. Since it is superfluous code that is generated by the compiler, for which there are no symbols in the arm ravenscar profile, that I am sure of.

---- Ah, the talking worked. I should next make the compiler commandline visible in the arm cross compile environment. Good. Thank you.

Ok, at the moment I am on another mission, but in some idle half hour I will do that.

Thanks again

j.

Re: gnat compiler issues with a partial build

[Simon Wright]

jan.de.kruyf@gmail.com writes:

> In any case: the runtime cooking business is like this (in its most
> basic form)
> 1. extract something very basic from ravenscar or zfp.
> 2. compile little test programs with (1) in a subdirectory and no libraries.
> 3. run nm to look for 'U' symbols. and use grep to find where they
> originate and where they are defined in any runtime.
> 4. Then adapt that piece of code where they are defined, one way or
> another, to you new runtime.
>    Normally of course either ravenscar or zfp will have a piece of
> code that fits without hacking too much.
> only for heap memory I had to modify s-memory quite a bit to fit the
> kernel environment so it is all strictly controlled and not
> pageable. (one of my requirements)
> 5. repeat 2,3,4 until satisfied that it is usable now. Then you can
> build the runtime subdirectory into a runtime library.
>
> So in that process I discovered those pesky undefined symbols, that
> _should_ disappear with some compiler switch, either in System.ads or
> on the command line. Since it is superfluous code that is generated by
> the compiler, for which there are no symbols in the arm ravenscar
> profile, that I am sure of.

The compiler needs to know that it's compiling against a runtime system,
which is a complete set of Ada units for your purposes. This means it
won't look anywhere else for units it needs.

You could try a structure like

  top/kernel/adainclude
            /adalib
     /proj

kernel will be your RTS, adainclude is where the Ada source goes, adalib
is where the library and ALI files end up. adainclude and adalib are the
default names; don't use anything else or it won't be recognised as an
RTS (there are some bells & whistles here, not needed to start with).

proj is where your test code goes.

In kernel you need a GPR file to build the RTS. I'm not sure what the
minimum needed is, but looking at the one I use in the STM32F4 RTS,
it'll be something like

   library project Build_Runtime is

       for Library_Name use "gnat";
       for Library_Kind use "static";
       --  Results in libgnat.a. This should be OK since the RTS will be
       --  linked into your module.

       for Library_Dir use "adalib";
       for Object_Dir use ".build";

       for Source_Dirs use ("adainclude");

       package Builder is
          --  An RTS that has built with this package will build without
          --  it; it may prevent picking up missing units from your
          --  host compiler's RTS; that may also be why -nostdinc is in
          --  ADAFLAGS below
          for Switches ("Ada") use ("--RTS=" & Project'Project_Dir);
       end Builder;

       package Compiler is
          ADAFLAGS :=
            ("-gnatpgn", "-gnatqQ", "-O2", "-nostdinc");
          --  Do you need -fpic or -fPIC? probably
          --  I'm not sure about the -nostdinc here

          for Switches ("Ada") use ADAFLAGS;
      end Compiler;

   end Build_Runtime;

As I said, your source files go in kernel/adainclude. I don't know about
gnat.adc; what I (and AdaCore) have done is put all the restrictions in
package System, seems to work just fine barring compiler errors.

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.

Strongly recommend doing all your builds with gprbuild rather than
gnatmake; if you have any C or C++ code, you must use gprbuild.

To test out your RTS, use code in the proj directory, and a project
file. You can say

   gprbuild --RTS=../kernel -P foo.gpr

or you can include this in foo.gpr:

   package Builder is
      for Default_Switches ("ada") use ("--RTS=../kernel");
   end Builder;

It's possible you might need an absolute path to find the RTS.

Re: gnat compiler issues with a partial build

[Simon Wright]

Simon Wright <simon@pushface.org> writes:

> 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.

Re: gnat compiler issues with a partial build

[jan.de.kruyf]

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.

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.

This holds true for all Unknown symbols the compiler spits out. They will be found either in the runtime, and then you can find them back in the adainclude directory with grep. Or they are in some included systemlib.

So that is why it is important not to have systemlib calls in a setup where there are no system libs. And note on the side: I do not know if finalization perhaps needs some system lib!

So the bottom line is that if an unknown symbol is not "Pragma Exported" from the adainclude packages then you cannot use it if you have no systemlibs.

So then it is a feature in the language that cannot be used in that specific setup.


My issue is that no matter what I do in native, the compiler produces some unknown symols that _are_ exported by the full native runtime, but _not_ by zfp or ravenscar (but those are for small controllers in the gnat wold)

And Mark L found out that the arm cross compiler does not produce them, otherwise he would have unresolved symols which he has not. 
So I think this is at the moment the road to follow. Find out how the arm cross compiler compiles differently from the native compiler.


cheers, bedtime now.

j.

Re: gnat compiler issues with a partial build

[Simon Wright]

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)).

Re: gnat compiler issues with a partial build

[jan.de.kruyf]

On Thursday, June 11, 2015 at 7:01:25 AM UTC+2, Simon Wright wrote:


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

Since when is it, that when I point out something in the tools that does not seem kosher (or perhaps is not documented) that I ought to have a problem?

The issue I had, I have solved for myself long ago, because I do know my tools. 
And when it proves I dont, I will strive to get to know them better.

> 
> 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. 

Yes.

> it will look in the RTS it is in fact compiling
> against, which in your case is the Linux GNAT GPL 2014 RTS, 

No, for that it needs a library (or RTS as we call it in Ada). I have made sure it is not there, by setting the RTS essentially to null in the project file. And I  have tried to inform the compiler of that fact. 
But apparently I failed or there is a bug in the compiler.

> and generate
> code that expects to find those features at link time.

Possible, but the documentation as it stands says it ought not, if one uses the right restrictions. What is more, the arm cross environment does not suffer of it, according to Mark L. 
And in the olden days we had "No Runtime", which means exactly that.
Today gnat says that we can imitate that with the right restrictions etc.

> 
> (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)).

You have a wrong understanding of an RTS.

It is a collection of source files that are compiled and partially linked into a library.
This library is then linked with the final customer program (when it is a static lib) to make the executable. 
It is nothing more and also nothing less.
And where the firewall between the 2 lies is entirely unimportant. The linker just wants the symbols it needs in other parts of the program.

So I fail to see how an extra layer of obfuscation will make this issue (of wrong or accidental code go away. 
On the contrary _understanding the tools better_, including their failings will clear this issue up.

The issue is not my runtime (or immitation of it) The issue is that the compiler produces symbols that _ARE NOT_ in the ravenscar profile for arm.
Although I set all the switches to immitate that compile environment. (At least I hope I did).

Thanks for listening to me,

j.

Re: gnat compiler issues with a partial build

[rrr.eee.27]

On Thursday, June 4, 2015 at 1:12:27 PM UTC+2, jan.de...@gmail.com wrote:
> First the good news: I was able to load and unload a mixed C and Ada kernel module last night for the first time.
> 
> But I think I found a subtle problem in the compiler (gnat-gcc 4.7.4) while doing my Linux kernel module.
> 

> -------------------------------------
> 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
> -------------------------------------
> 
> 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 there might be a runtime error under certain conditions. And they have to do with exception propagation I suspect, from looking at a disassembly.

> The bottom line is that, no-matter what I all switch off, the compiler sometimes emits random subroutine calls in its error detection section. Normally they don't bite you, because you would almost never hit them in a well constructed program. But a kernel module with those simply will not load; end.
> 
> The only vague reference to such a scenario might be in the "-gnatp" description in the gnat_ug.
> 
> So if any of the compiler theologians has any light on this: please feel welcome to comment.


The symbol shown (__gnat_rcheck_CE_*) is generated for language required run time checks. Here it is an access check. They typically are range checks.

These checks are generated if you don't suppress them via -gnatp regardless of the capabilities of the RTS. Your coding style and the compiler switches must match the RTS capabilities. You don't suppress the run time checks by a pragma Restriction only, you also have to set the command line option -gnatp.

In another post you said that you don't wanted to use -gnatp as that would be like coding in C. That is not my experience at all!  The compiler still does a fantastic job at compile time to ensure range and access properties. Gnat found quite some subtle errors in my code even with checks suppressed (-gnatp).

RE

Re: gnat compiler issues with a partial build

[Simon Wright]

rrr.eee.27@gmail.com writes:

> These checks are generated if you don't suppress them via -gnatp
> regardless of the capabilities of the RTS.

Yes, but if you have pragma Restrictions (No_Exception_Propagation) and
don't have an immediate handler the compiler will call
Last_Chance_Handler directly instead of the __gnat_rcheck* subprograms.

Re: gnat compiler issues with a partial build

[jan.de.kruyf]

On Thursday, June 11, 2015 at 9:38:39 PM UTC+2, Simon Wright wrote:

> 
> > These checks are generated if you don't suppress them via -gnatp
> > regardless of the capabilities of the RTS.
> 
> Yes, but if you have pragma Restrictions (No_Exception_Propagation) and
> don't have an immediate handler the compiler will call
> Last_Chance_Handler directly instead of the __gnat_rcheck* subprograms.

right,
I did some digging over lunch.
The 'standard' gnat RTS builder, used elsewhere (which I probably copied from the ZFP package without checking) builds an RTS with '-gnatpg'. This, it appears, is what Adacore has taken as a standard way of doing things, if I understand the compiler source right.
And '-gnatp' indeed gets rid of the extra call-symbols. I cross-checked that by compiling one of the problem sources in various ways.

So Simon you were very right in saying that this is one of my alternatives.

However, I am not Adacore. I am just a casual programmer that builds a small RTS at odd times. moreover, I am not very precise. I need to test my doings extensively. This means to me that I must get all the help I can with finding my bugs. (You can never prove they are absent, only that they are present).

so then, I do not know how Adacore manages this, but it is a poor solution for me to just switch of runtime-checks for a first build of an RTS. (or in my case the files that eventually will constitute the RTS)

Ergo, I must put in dummies that trap those calls, and give some indication of what is happening. (Which is exactly what I did).

> Yes, but if you have pragma Restrictions (No_Exception_Propagation) and 
> don't have an immediate handler the compiler will call 
> Last_Chance_Handler directly instead of the __gnat_rcheck* subprograms. 

That is exactly the part that does not work. I have been through that now over and over with a nit comb.

In any case the whole issue is now documented in some way for whoever comes after us.

--

Besides I managed to get rid of the cruft in the building process of a partial compile for this kernel module that caused all this:

In the project file I now heave this:
---------------------------------------
package Builder is
      Global_Configuration_Pragmas := "gnat.adc";
      for Default_Switches ("ada") use
        ("-g", "-nostdlib",
         "--RTS=" & Project'project_dir);
      for Executable ("demo.adb") use "demo.x";
   end Builder;
---------------------------------------

the "-nostdlib" flag here causes the link process to forget about any regular libraries. In any other place (like in the linker package) did not work. Maybe I made a mistake then, I could not tell anymore.
The RTS points to nothing, because the lib is missing there.
The partial link file "demo.x" I use in the module building process downstream.

----------------------------------------
package Linker is
      for Default_Switches ("Ada") use ("-v", "-Xlinker","-r"); 
   end Linker;
----------------------------------------

the "-Xlinker","-r" passes '-r' to the linker program and causes a partial link.

Works like a dream now.

So thank you for your listening ear gentlemen. I highly appreciate it.
This type of interaction is for me often the only way to get out of a dark spot.

cheers,

j.

Re: gnat compiler issues with a partial build

[Simon Wright]

jan.de.kruyf@gmail.com writes:

> package Builder is
>       Global_Configuration_Pragmas := "gnat.adc";

I think this should be
      for Global_Configuration_Pragmas use "gnat.adc";

see
https://gcc.gnu.org/onlinedocs/gcc-5.1.0/gnat_ugn/Specifying-Configuration-Pragmas.html
and
http://docs.adacore.com/gprbuild-docs/html/share/gnat_project_manager.html#global-attributes

(the second refers to the attribute as
"Builder.Global_Configuration_Pragmas" which I think is misleading,
clearly should be "Builder'Global_Configuration_Pragmas").

>       for Default_Switches ("ada") use
>         ("-g", "-nostdlib",
>          "--RTS=" & Project'project_dir);
>       for Executable ("demo.adb") use "demo.x";
>    end Builder;

Re: gnat compiler issues with a partial build

[jan.de.kruyf]

On Friday, June 12, 2015 at 5:05:35 PM UTC+2, Simon Wright wrote:

> > package Builder is
> >       Global_Configuration_Pragmas := "gnat.adc";
> 
> I think this should be
>       for Global_Configuration_Pragmas use "gnat.adc";
> 

I was caught by that too :)
It is apparently a single value variable, and not an array, like others where you do say "for . . . ."
So this is what works.


Thank for your attentive reading.

j.

Re: gnat compiler issues with a partial build

[jan.de.kruyf]

On Thursday, June 11, 2015 at 6:10:30 PM UTC+2, rrr.e...@gmail.com wrote:
> On Thursday, June 4, 2015 at 1:12:27 PM UTC+2, jan.de...@gmail.com wrote:
> > First the good news: I was able to load and unload a mixed C and Ada kernel module last night for the first time.
> > 
> > But I think I found a subtle problem in the compiler (gnat-gcc 4.7.4) while doing my Linux kernel module.
> > 
> 
> > -------------------------------------
> > 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
> > -------------------------------------
> > 
> > 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 there might be a runtime error under certain conditions. And they have to do with exception propagation I suspect, from looking at a disassembly.
> 
> > The bottom line is that, no-matter what I all switch off, the compiler sometimes emits random subroutine calls in its error detection section. Normally they don't bite you, because you would almost never hit them in a well constructed program. But a kernel module with those simply will not load; end.
> > 
> > The only vague reference to such a scenario might be in the "-gnatp" description in the gnat_ug.
> > 
> > So if any of the compiler theologians has any light on this: please feel welcome to comment.
> 
> 
> The symbol shown (__gnat_rcheck_CE_*) is generated for language required run time checks. Here it is an access check. They typically are range checks.
> 

So I found out when I read the sources of the native RTS

> In another post you said that you don't wanted to use -gnatp as that would be > like coding in C. That is not my experience at all!  

It is a very good compiler, but per definition the compiler cannot catch runtime errors (like passing an out of bounds index to an array write routine for instance).

This is why some people like runtime checking, to catch their own stupidities I suppose.
C never had it, and it is the one big issue people have with it, except for the baroque syntax. 
Of course excellent software is also written in C, people learn to compensate for deficiencies. And Gcc has improved by leaps and bounds, also the C compiler part. 
But I suppose lazy people like me, like some language like Ada that does do runtime checking. The delays caused by it are very small compared to other issues that some languages (and compilers) have. 

So what I have done in the past when I really did not want runtime checking is first compile it in, and check where gnat puts them, and then put some form of 'assert' or 'if then' and / or review the code to see why gnat puts them.

cheers,

j.