Re: Importance of GNAT.Source_Info

[Niklas Holsti <niklas.holsti@tidorum.invalid>]

On 2020-01-07 4:29, Optikos wrote:
> On Monday, January 6, 2020 at 4:03:56 PM UTC-6, Jere wrote:
>> I'm working on a baremetal RTS and while looking at
>> https://wiki.osdev.org/Ada_Bare_bones, one of the files
>> it suggests is part of the minimum set of RTS files is
>> g-souinf.ads which contains the package GNAT.Source_Info.
>>
>> Does anyone know what part of the compiler requires this?
>> So far I haven't had GNAT barf at me for not having it
>> while compiling the files I do have, but I don't want to
>> leave it out if it is indeed necessary for something.  I
>> didn't see any info on why it is necessary.  It's definitely
>> useful in that it gives a lot of compile time values, but
>> not sure why it would be a "required" file.  I'm assuming
>> something will break without it, but don't know what.
>>
>> Sorry that this isn't a pure "Ada" question and is more
>> focused on GNAT specifically, but thought one of yall
>> might know why.
GNAT might use GNAT.Source_Info in code generated to raise exceptions 
with strings. However, as all subprograms in GNAT.Source_Info are marked 
"Intrinsic", it seems that GNAT could as well generate that "intrinsic" 
code without calling GNAT.Source_Info. So I don't really know.

> https://www.radford.edu/~nokie/classes/320/std_lib_html/gnat-source_info.html
> 
> Speaking in general from RTOS knowledge not specific to GNAT or Ada,
> I observe that GNAT.Source_Info.Enclosing_Entity (utilized
> transitively to the task's entry point) would provide information
> useful to knowing the complete call tree

No, from its description Enclosing_Entity uses the static (lexical) 
nesting and returns the name of the immediately lexically enclosing 
subprogram (the one in which Enclosing_Entity is called). It does not 
return the name of the callee of that subprogram nor can it be used 
transitively.

It is a simple, static, query of the compiler's compile-time knowledge 
of which program part the compiler is compiling now.

> for maximum execution-time
> analysis in static analyzers of static machine code or in empirical
> analysis tools of a running system or hybrids thereof.

I don't think one can discover call-trees with Enclosing_Entity, not 
even by running the program and displaying the results of 
Enclosing_Entity calls. Such Enclosing_Entity calls would have to be 
inserted everywhere in the source code by some automatic instrumentation 
tool, which would also have to insert code to trace subprogram calls and 
returns, so this tool would for sure itself know the name of the 
subprogram it is instrumenting and would not have to use Enclosing_Entity.

> The A#1 goal
> of hard realtime systems is to definitively know (via mathematical
> proof of worst-case) the maximum (not typical) execution time of each
> subroutine invocation—especially this analysis for each  required
> use-case from system engineering (but in lieu of each use-case, then
> the absolute maximum execution-time of each subroutine). 

Indeed.

> Often this
> analysis starts with a table of all system calls in an RTOS plus all
> subroutines in a realtime system (including app-domain) that is
> derived from the map file of each executibile as output at link-time.

Or from the executable file (code + debug info).

To find the call-tree (or call-graph, really) the analysis tool 
generally has to scan the binary code and find all call instructions.

Source-level call-graphs can of course be found by static analysis of 
the source code, but the binary compiled code often has a different 
structure which means that source-level call-graphs are not so useful 
for static WCET analysis.

> It appears that GNAT.Source_Info.Enclosing_Entity provides a dynamic
> walk with software assist that would otherwise be a manual or
> semi-manual walk of the map file of subroutine names & their entry
> points.

No, that is a misunderstanding of Enclosing_Entity.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .