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: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: Importance of GNAT.Source_Info Date: Tue, 7 Jan 2020 08:12:39 +0200 Organization: Tidorum Ltd Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Trace: individual.net vzilcKJbJaYBpddaH4XZwQJNk6ko1qYFAFeyYNe475QS9e2+Rj Cancel-Lock: sha1:bBgVA/eMjIxAcVOYI6kphBdyLgA= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.3.1 In-Reply-To: Content-Language: en-US Xref: reader01.eternal-september.org comp.lang.ada:57799 Date: 2020-01-07T08:12:39+02:00 List-Id: 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 . @ .