Re: gnat compiler issues with a partial build

[jan.de.kruyf@gmail.com]

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.