Stackusage at runtime

Stackusage at runtime

[andi.vontobel]

Hi.

Is it possible to figure out how much of the stack is used at a
specific moment?
-> Ada95 Crosscompiler to PPC
(It is a little bit hard to optimize the stacksize ...)

Thanks,
Andy

Re: Stackusage at runtime

[Georg Bauhaus]

andi.vontobel@gmx.ch schrieb:
> Hi.
> 
> Is it possible to figure out how much of the stack is used at a
> specific moment?
> -> Ada95 Crosscompiler to PPC
> (It is a little bit hard to optimize the stacksize ...)

I'd guess that your debugger can stop the program at
that specific moment and tell you about the stack.

Re: Stackusage at runtime

[Andy]

On 4 Nov., 12:44, Georg Bauhaus <rm.dash-bauh...@futureapps.de> wrote:
> andi.vonto...@gmx.ch schrieb:
>
> > Hi.
>
> > Is it possible to figure out how much of the stack is used at a
> > specific moment?
> > -> Ada95 Crosscompiler to PPC
> > (It is a little bit hard to optimize the stacksize ...)
>
> I'd guess that your debugger can stop the program at
> that specific moment and tell you about the stack.

The debugger is not really usable ... is there a possibility read the
value
in the code and to print out?

Re: Stackusage at runtime

[Stuart]

<andi.vontobel@gmx.ch> wrote in message 
news:bf764407-9606-4ee4-aa22-cbb6d00dd84c@d36g2000prf.googlegroups.com...

> Is it possible to figure out how much of the stack is used at a
> specific moment?
> -> Ada95 Crosscompiler to PPC
> (It is a little bit hard to optimize the stacksize ...)

Compare the value of the stack pointer to its base value!

For a PowerPC it is very likely that the code will be conforming to the 
Embedded Application Binary Interface (EABI), so the stack pointer will be 
register r1 (aka gpr1).  Reading this will require a bit of machine code - 
either use package machine code or call out to an assembler routine 
depending on how 'pure' you want to be.

Making this a subprogram would allow you to quickly find the stack pointer 
value anywhere in your program.  Depending on what you actually need you 
might need to make adjustments for the stack frame of the subprogram 
returning the value (but I would suspect this is quite small and the 
discrepancy introduced to be of minimal interest if you are optimizing the 
programme).

The base value of the stack is often defined by a symbol (you will need to 
check your compiler's documentation) though take care as to whether you need 
the address represented by the symbol or the value at that address (in my 
experience it is usually the former).

As a pedagogical point - the Ada language does not really define what the 
stack (if any) is used for, so your results may not be universally 
applicable (but I suspect that is not a significant concern).

-- 
Stuart

Re: Stackusage at runtime

[Andi]

Thank you Stuart for the help.
Stuart wrote:

> As a pedagogical point - the Ada language does not really define what the 
> stack (if any) is used for, so your results may not be universally 
> applicable (but I suspect that is not a significant concern).
But every task has it's own memory (probably the name "stack" is not 
correct.

for my_task'size use 16*1024 (as I remember)
and it runs ....

Now I can make a couple of trial to figure out how mucch is really 
needed and than I have to do that for all the other tasks .... not my 
favorit job ;-)

Andy

Re: Stackusage at runtime

[Niklas Holsti]

Andi wrote:
> Thank you Stuart for the help.
> Stuart wrote:
> 
>> As a pedagogical point - the Ada language does not really define what 
>> the stack (if any) is used for, so your results may not be universally 
>> applicable (but I suspect that is not a significant concern).
> 
> But every task has it's own memory (probably the name "stack" is not 
> correct.
> 
> for my_task'size use 16*1024 (as I remember)
> and it runs ....
> 
> Now I can make a couple of trial to figure out how mucch is really 
> needed and than I have to do that for all the other tasks .... not my 
> favorit job ;-)
> 
> Andy

Oh, you want to know how much stack-space a task needs overall 
(worst case), not how much is in use at a particular point in the 
execution? If so, how about GNATstack:

http://www.adacore.com/home/gnatpro/add-on_technologies/stack_analysis/

Or AbsInt's StackAnalyzer:

http://www.absint.com/stackanalyzer/

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

Re: Stackusage at runtime

[Niklas Holsti]

Andi wrote:
> Now I can make a couple of trial to figure out how mucch is really 
> needed and than I have to do that for all the other tasks .... not my 
> favorit job ;-)

And later Andy wrote:

 > We are using Apex ... Probably we think about adacores static
 > analysis tool ...

As I understand it, AdaCore's GNATstack is coupled with GNAT, and 
uses compile-time information from GNAT; it may not be possible to 
use it with the Apex compiler. Of course, code generated by GNAT 
may not use the same amount of stack space as code generated by Apex.

The AbsInt StackAnalyzer works on the machine code alone, I 
believe, so it should in principle work with any compiler. However, 
I don't know if it handles the "secondary stack" used by some Ada 
compilers. Apex is not listed as a supported compiler on AbsInt's 
web, but it may well work.

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

Yes it is possible. Re: Stackusage at runtime

[anon]

GNAT maintain two internal stacks but both uses the allocated system
stacks from the System.Memory package that can be monitored.  Will 
work for all version of GNAT with the understanding that the "Alloc" 
function may look a little different. 

To monitor the main (system) stack that GNAT uses, you need to alter the 
System.Memory package to include some monitoring information like in 
the following code. Some may not like it but it get the job done.  In this 
version I only show how to monitor allocations, but if you need to monitor 
Free allocation as well you can either add another variable such as 
"Free_Stack_Value" and assoc statements or just insert a subtract
Alloc_Stack_Value statement in the Free procedure.


1. Create a Tempory dir or use your program dir. This way maintain GNAT 
system integrity.

2. Copy from your version of GNAT "System.Memory" package aka files
   s-memory.ad? (need both body amd specs files) to temp dir.

3. Alter the s-memory.adb file by adding the following lines before the Alloc 
   function:

   -- -- -- -- -- -- --
   -- Debuging links --
   -- -- -- -- -- -- --
   Alloc_Stack_Value : size_t := 0;
      pragma Export (Ada, Alloc_Stack_Value, "Alloc_Stack_Value");


4. then insert the following line in the Alloc function:

      Alloc_Stack_Value := Alloc_Stack_Value + Size;

5. An Example of how the code placement can look using GNAT Ada 3.15p
   aka a version of GNAT Ada 95. System.Memory package:


    ... -- removed to save space

   -- -- -- -- -- -- --
   -- Debuging links --
   -- -- -- -- -- -- --
   Alloc_Stack_Value : size_t := 0;
      pragma Export (Ada, Alloc_Stack_Value, "Alloc_Stack_Value");


   -----------
   -- Alloc --
   -----------

   function Alloc (Size : size_t) return System.Address is
      Result      : System.Address;
      Actual_Size : size_t := Size;

   begin
      if Size = size_t'Last then
         Raise_Exception (Storage_Error'Identity, "object too large");
      end if;

      --  Change size from zero to non-zero. We still want a proper pointer
      --  for the zero case because pointers to zero length objects have to
      --  be distinct, but we can't just go ahead and allocate zero bytes,
      --  since some malloc's return zero for a zero argument.

      if Size = 0 then
         Actual_Size := 1;
      end if;

      Abort_Defer.all;
      Result := c_malloc (Actual_Size);
      Abort_Undefer.all;

      if Result = System.Null_Address then
         Raise_Exception (Storage_Error'Identity, "heap exhausted");
      end if;

      --
      --  Insert monitoring code after all error checking is done
      --
      Alloc_Stack_Value := Alloc_Stack_Value + Size;

      return Result;
   end Alloc;

    ... -- removed to save space


6. Compile the new "System.Memory" package:

     gcc -c -gnatpg s-memory.adb

7. Now a Test program to illustrate usage.  Needs to be in the same 
   temporary directory with the newly compiled s-memory package.

with Ada.Text_IO ;
use Ada.Text_IO ;

procedure Test is

                                                   -- copied from s-memory.ads
    type size_t is mod 2 ** Standard'Address_Size ;

    package S_IO is new Ada.Text_IO.Modular_IO ( size_t ) ;

    Stack_Monitor : size_t ;                     -- linked to s-memory.adb
    pragma Import ( Ada, Stack_Monitor, "Alloc_Stack_Value" ) ;


    type integer_access is access all integer ;
    type float_access is access all float ;

    A : Integer_access ;
    B : float_access ;

  begin
    Put ( "Before create Integer := " ) ;
    S_IO.Put ( Stack_Monitor ) ;
    A := new Integer ;
    Put ( " after create operation := " ) ;
    S_IO.Put ( Stack_Monitor ) ;
    New_Line ;
    --
    Put ( "Before create Float := " ) ;
    S_IO.Put ( Stack_Monitor ) ;
    B := new Float ;
    Put ( " after create operation := " ) ;
    S_IO.Put ( Stack_Monitor ) ;
    New_Line ;
  end ;



8: Compile test.  The compiler will use the newer version of System.Memory 
   package when linking.

    gnat make test.adb

9. Run Test program.

     test 


In <bf764407-9606-4ee4-aa22-cbb6d00dd84c@d36g2000prf.googlegroups.com>, andi.vontobel@gmx.ch writes:
>Hi.
>
>Is it possible to figure out how much of the stack is used at a
>specific moment?
>-> Ada95 Crosscompiler to PPC
>(It is a little bit hard to optimize the stacksize ...)
>
>Thanks,
>Andy

Re: Yes it is possible. Re: Stackusage at runtime

[Ludovic Brenta]

anon wrote:
> To monitor the main (system) stack that GNAT uses, you need to alter the
> System.Memory package to include some monitoring information like in
> the following code. Some may not like it but it get the job done.
[...]

>   begin
>     Put ( "Before create Integer := " ) ;
>     S_IO.Put ( Stack_Monitor ) ;
>     A := new Integer ;
>     Put ( " after create operation := " ) ;
>     S_IO.Put ( Stack_Monitor ) ;
[...]

As your example shows, your technique does not address the OP's
problem; it monitors heap allocations (done via new), not the stack
(done by declaring variables in subprograms).

--
Ludovic Brenta.

Re: Yes it is possible. Re: Stackusage at runtime

[anon]

Because a few questions here are from students, that may want to bypass the 
research, you should give a partial answer that leads them to learn how things 
work. And not the complete answer the first time around or send them to get 
a package that is going to cost them, unless they ask for it.

No one here even suggested looking at GNAT's documentation for an example of 
"Inline Assembler", did they. The only problem is that the correct Assembly 
statements or opcodes need to be inserted in the Ada "Asm" statement for 
the PPC. Now this version is for intel x86 version and not PPC because I did 
not want to dusty off my PPC assembly books, but one should be able to 
adopt the code for PPC. 


  -- Intel version 

  package Unsigned_32_IO is new Modular_IO ( Unsigned_32 ) ;

      ...

      --  routine returns SP (stack index reg) into a unsigned_32 variable 

      Asm ( Template => "movl %%eax,  %%esp",
             Outputs => Unsigned_32'Asm_Output ( "=a", Offset ),
             Volatile => True ) ;
      --
      Put ( "Intel SP Register := " ) ;  
      Unsigned_32_IO.Put ( Offset, Base => 16 ) ;  
      New_Line ;

      ...


And you can make this routine into a procedure like in a debug package, But 
in that case you would have to adjust the offset.  And you could even add a 
routine that can dump apart of the stack if needed by expanding the idea 
of using "System.Machine_Code" package.


But Ludovic Brenta is quick at doing nothing but cutting people down! Even 
if Brenta does not understand, also I see Ludovic Brenta had no answer to 
give. So Ludovic Brenta should get back and fix Annex -E for Debian and let 
people help those who need it.



In <3c9a589e-da1c-4d8c-b42e-e84bcde38739@g17g2000prg.googlegroups.com>, Ludovic Brenta <ludovic@ludovic-brenta.org> writes:
>anon wrote:
>> To monitor the main (system) stack that GNAT uses, you need to alter the
>> System.Memory package to include some monitoring information like in
>> the following code. Some may not like it but it get the job done.
>[...]
>
>> =A0 begin
>> =A0 =A0 Put ( "Before create Integer :=3D " ) ;
>> =A0 =A0 S_IO.Put ( Stack_Monitor ) ;
>> =A0 =A0 A :=3D new Integer ;
>> =A0 =A0 Put ( " after create operation :=3D " ) ;
>> =A0 =A0 S_IO.Put ( Stack_Monitor ) ;
>[...]
>
>As your example shows, your technique does not address the OP's
>problem; it monitors heap allocations (done via new), not the stack
>(done by declaring variables in subprograms).
>
>--
>Ludovic Brenta.

Re: Yes it is possible. Re: Stackusage at runtime

[Ludovic Brenta]

anon wrote:
> But Ludovic Brenta is quick at doing nothing but cutting people down!

Oh I don't have to cut you down. You do that yourself very well.
However, someone had to clear up the confusion you created by mixing
up stack and heap. Someone might have read your answer and been
misled.

> Even if Brenta does not understand,

I do understand. Your answer was wrong because you did not understand
the OP's question. Do you understand *that* now?

> also I see Ludovic Brenta had no answer to give.

I had not only one but two answers to give. Niklas Holsti and Stuart,
respectively, gave them before I did, so I did not repeat them. See? I
actually read threads before I reply. Apparently you fail to
understand *that*, too.

> So Ludovic Brenta should get back and fix Annex -E for Debian and let
> people help those who need it.

Ludovic Brenta should *nothing*; you seem to fail to understand
*that*, too. If you need Annex E for Debian, fix it yourself.

--
Ludovic Brenta.

Re: Yes it is possible. Re: Stackusage at runtime

[anon]

There was no confusion except your a fake that thinks he knows Ada. I am not 
sure how you became Debian Ada maintainer. And that was the saddest day in 
Debian history!


In <058e7ef3-2160-4134-9657-62ac194e6e45@s9g2000prm.googlegroups.com>, Ludovic Brenta <ludovic@ludovic-brenta.org> writes:
>anon wrote:
>> But Ludovic Brenta is quick at doing nothing but cutting people down!
>
>Oh I don't have to cut you down. You do that yourself very well.
>However, someone had to clear up the confusion you created by mixing
>up stack and heap. Someone might have read your answer and been
>misled.
>
>> Even if Brenta does not understand,
>
>I do understand. Your answer was wrong because you did not understand
>the OP's question. Do you understand *that* now?
>
>> also I see Ludovic Brenta had no answer to give.
>
>I had not only one but two answers to give. Niklas Holsti and Stuart,
>respectively, gave them before I did, so I did not repeat them. See? I
>actually read threads before I reply. Apparently you fail to
>understand *that*, too.
>
>> So Ludovic Brenta should get back and fix Annex -E for Debian and let
>> people help those who need it.
>
>Ludovic Brenta should *nothing*; you seem to fail to understand
>*that*, too. If you need Annex E for Debian, fix it yourself.
>
>--
>Ludovic Brenta.

Re: Yes it is possible. Re: Stackusage at runtime

[Georg Bauhaus]

anon schrieb:
> There was no confusion except your a fake that thinks he knows Ada. I am not 
> sure how you became Debian Ada maintainer. And that was the saddest day in 
> Debian history!

Hmm....

Is this a spoof of SNL, maybe?  The Chris Farley Ada Show is back!

Senator Debian doesn't seem to understand.

Could you comment on the Anon doctrine?



> In <058e7ef3-2160-4134-9657-62ac194e6e45@s9g2000prm.googlegroups.com>, Ludovic Brenta <ludovic@ludovic-brenta.org> writes:
>> anon wrote:
>>> But Ludovic Brenta is quick at doing nothing but cutting people down!
>> Oh I don't have to cut you down. You do that yourself very well.
>> However, someone had to clear up the confusion you created by mixing
>> up stack and heap. Someone might have read your answer and been
>> misled.
>>
>>> Even if Brenta does not understand,
>> I do understand. Your answer was wrong because you did not understand
>> the OP's question. Do you understand *that* now?
>>
>>> also I see Ludovic Brenta had no answer to give.
>> I had not only one but two answers to give. Niklas Holsti and Stuart,
>> respectively, gave them before I did, so I did not repeat them. See? I
>> actually read threads before I reply. Apparently you fail to
>> understand *that*, too.
>>
>>> So Ludovic Brenta should get back and fix Annex -E for Debian and let
>>> people help those who need it.
>> Ludovic Brenta should *nothing*; you seem to fail to understand
>> *that*, too. If you need Annex E for Debian, fix it yourself.
>>
>> --
>> Ludovic Brenta.
> 


-- 
--
Georg Bauhaus
Y A Time Drain  http://www.9toX.de

Re: Yes it is possible. Re: Stackusage at runtime

[Pascal Obry]

Ludovic Brenta a �crit :
> Oh I don't have to cut you down. You do that yourself very well.

Agreed 100% :)

Ludovic, just let this guy fall into your kill file, at this point I
think it is the best. I agree that it is very hard to refrain from
responding (I've done so too many times) to all the nonsenses he
spreads, but well I'm not sure there is other solutions as he is just
not listening.

My 2 cents!

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Yes it is possible. Re: Stackusage at runtime

[Georg Bauhaus]

Pascal Obry schrieb:
> Ludovic Brenta a �crit :
>> Oh I don't have to cut you down. You do that yourself very well.
> 
> Agreed 100% :)
> 
> Ludovic, just let this guy fall into your kill file, at this point I
> think it is the best. I agree that it is very hard to refrain from
> responding (I've done so too many times) to all the nonsenses he
> spreads, but well I'm not sure there is other solutions as he is just
> not listening.
> 
> My 2 cents!

Cents is interesting in this regard, as there are knowledge
selling sites such as experts exchange that sell helpful
answers.  Scanning "the internet" for free information provided
by helpful collegues, such as is found on c.l.ada,s can become
frustrating. The process finds repeated questions and answers
that answer a different question.

Maybe NNTP should be extended to include "X-Rating" and
"X-On_Topic" header lines, to be added by readers after
the fact?

Re: Yes it is possible. Re: Stackusage at runtime

[anon]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2109 bytes --]

Yeah, Right! He has stated that he would a few time, but he keep reading my 
post.

The problem is that a few people like Ludovic Brenta believe they are 
entitled to something like respect. But they MUST EARN that right each and 
EVERY DAY that they think they deserve it.  And when they are not doing 
their job that they elected to do then they should never ask or accept 
any respect at all, because they did not earn it.

Now, if someone writes a piece of software, well there are going to be some 
who likes it, and some who hates it, just like a painter and their painting 
for example.  And for those who hate the software the author must first 
understand they have that right to hate the author's software and the right to 
tell others they hate that software. As for the author, well they should use the 
criticism to aid them in creating a better product. That way some who at first 
hate the software may change their mind. And others that would not even look 
at this software might try it if they learn the author has proven that thry are 
willing to work with the end user, so the end user can get their job done.

Also, if a person can not handle the Criticism then they need to change jobs.



In <49133504.6040006@obry.net>, Pascal Obry <pascal@obry.net> writes:
>Ludovic Brenta a �crit :
>> Oh I don't have to cut you down. You do that yourself very well.
>
>Agreed 100% :)
>
>Ludovic, just let this guy fall into your kill file, at this point I
>think it is the best. I agree that it is very hard to refrain from
>responding (I've done so too many times) to all the nonsenses he
>spreads, but well I'm not sure there is other solutions as he is just
>not listening.
>
>My 2 cents!
>
>-- 
>
>--|------------------------------------------------------
>--| Pascal Obry                           Team-Ada Member
>--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
>--|------------------------------------------------------
>--|              http://www.obry.net
>--| "The best way to travel is by means of imagination"
>--|
>--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Stackusage at runtime

[Per Sandberg]

If you are running GNAT it is quite straight forward and described in 
detail in the top secret document (The GNAT users guide chapter 22. 
Stack Related Facilities)
In short
1 Compile the code with:
	gcc -c -fstack-check *.adb
2 Bind your executable with
	gnatbind -u0 file
3 Set environment variable GNAT_STACK_LIMIT
4 Run your program and terminate clean.
5 Done.

I expect that all targets behaves more ore less the same.


andi.vontobel@gmx.ch wrote:
> Hi.
> 
> Is it possible to figure out how much of the stack is used at a
> specific moment?
> -> Ada95 Crosscompiler to PPC
> (It is a little bit hard to optimize the stacksize ...)
> 
> Thanks,
> Andy

Re: Stackusage at runtime

[Andy]

On 4 Nov., 21:07, Per Sandberg <per.sandb...@bredband.net> wrote:
> If you are running GNAT it is quite straight forward and described in
> detail in the top secret document (The GNAT users guide chapter 22.
> Stack Related Facilities)
oops ... top secret? .... :-))


We are using Apex ... Probably we think about adacores static analysis
tool ...

I thought that ada itself has a possibility to report the memory-usage
at a specific time

Thank you all for your help
Andy

Re: Stackusage at runtime

[Per Sandberg]

Yes top secret because that the last place a lot people looks :)

Concerning APEX, once upon a time i the dark ages (80:ties & 90:ties) we 
was using apex as well for embedded systems.
What we did at that point in time was something along these lines:

* On program start fill the memory allocated for the stacks with 16#CACA#.
* After some time of execution query the operation system /Runtimes of 
the following, Stack start & Stack Size very very target dependent.
* Iterate from the free side of the allocated memory for each stack 
until no more "CACA" is found.
* Thats how we did it then.

And that is actually the the same basic method used in the more modern 
GCC/GNAT system to obtain the same result.

But if its possible to do static analysis with gnatstack that much better.

Concerning Ada and stacks as far as i know there is nothing defined in 
the language .

/Hope you will find a way in the dark labyrinth of memory:)
/Per


Andy wrote:
> On 4 Nov., 21:07, Per Sandberg <per.sandb...@bredband.net> wrote:
>> If you are running GNAT it is quite straight forward and described in
>> detail in the top secret document (The GNAT users guide chapter 22.
>> Stack Related Facilities)
> oops ... top secret? .... :-))
> 
> 
> We are using Apex ... Probably we think about adacores static analysis
> tool ...
> 
> I thought that ada itself has a possibility to report the memory-usage
> at a specific time
> 
> Thank you all for your help
> Andy

Re: Stackusage at runtime

[Jean-Pierre Rosen]

Per Sandberg a �crit :
> * Iterate from the free side of the allocated memory for each stack 
> until no more "CACA" is found.
Other commonly used values are 16#CAFE# and 16#DEADBEEF# (if you need 64 
bits) :-)

-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Stackusage at runtime

[Keith Thompson]

Jean-Pierre Rosen <rosen@adalog.fr> writes:
> Per Sandberg a �crit :
>> * Iterate from the free side of the allocated memory for each stack
>> until no more "CACA" is found.
> Other commonly used values are 16#CAFE# and 16#DEADBEEF# (if you need
> 64 bits) :-)

Um, #DEADBEEF# is 32 bits.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

Re: Stackusage at runtime

[nobody]

Per Sandberg wrote:
> 4 Run your program and terminate clean.

For most embedded systems I expect that to be impossible. When most of 
my companys applications terminate there will be very little hardware 
left to analyze.

Re: Stackusage at runtime

[sjw]

On Nov 4, 7:55 am, andi.vonto...@gmx.ch wrote:
> Is it possible to figure out how much of the stack is used at a
> specific moment?
> -> Ada95 Crosscompiler to PPC
> (It is a little bit hard to optimize the stacksize ...)

If your OS is VxWorks, there's checkStack (or perhaps it's
stackCheck :-)