2011-05-16 11:07:02     exploring the stack consumption with gcc - baremetal - windows

Document created by Aaronwu Employee on Oct 16, 2013
Version 1Show Document
  • View in full screen mode

2011-05-16 11:07:02     exploring the stack consumption with gcc - baremetal - windows

Prasanth Rajagopal (INDIA)

Message: 100672   

 

I am trying to understand the ways stack usage can be analysed with gcc run time - in bare metal development.                     I am not much of a regular programmer, but  here are my ideas (questions) -

 

1. if stack limit is crossed for any allocation, execution should be diverted to another soft handler, and if it can tell me how much of size was crossed and what function - might be good.

 

2. update the allocations for every function executed - in a seperate debug table.

 

3. max stack allocation after the program exits or a periodic update in a seperate debug variable.

 

Maybe there is a different perspective for some of the above cases. Perhaps in cases like cross compiling large open source codes, it might give me some picture of stack usage.

 

I looked in to docs and tried some gcc options, but I am not sure about the right options for bare metal and also with the fact that there is no MMU on Blackfin.

 

Are there options in gcc to achieve all of the above?

 

Thanks for any inputs / comments.

QuoteReplyEditDelete

 

 

2011-05-16 14:11:42     Re: exploring the stack consumption with gcc - baremetal - windows

Mike Frysinger (UNITED STATES)

Message: 100681   

 

gcc already supports stack checking.  simply use the -fstack-limit-symbol option when compiling code and give it a symbol name which represents the address of the start of the stack.  then gcc itself will emit code which makes sure the stack is not exceeded and if it does, trigger a soft exception via "EXCPT 3".

 

http://docs.blackfin.uclinux.org/doku.php?id=uclinux-dist:debugging_applications#flat_binaries

QuoteReplyEditDelete

 

 

2011-05-17 08:48:47     Re: exploring the stack consumption with gcc - baremetal - windows

Prasanth Rajagopal (INDIA)

Message: 100694   

 

Thanks, it works now.

 

I created a stack:

 

MEM_L1_SCRATCH    : ORIGIN = 0xFFB00000, LENGTH = 0x0100

 

  __stack_start = ORIGIN(MEM_L1_SCRATCH);

  __stack_end   = ORIGIN(MEM_L1_SCRATCH) + LENGTH(MEM_L1_SCRATCH);

 

And forced condition to fail with int check_stack[2000]; inside a function. It failed and when checking the Dis-assembly, I am now seeing the right conditions inserted to stack check:

 

ffa00554:   R3 = P2;

ffa00556:   P2.H = 0xffb0;          /* (-80)        P2=0x0xffb00005 */

ffa0055a:   P2.L = 0x1f48;          /* (8008)       P2=0x0xff801f48 */

ffa0055e:   CC = SP < P2;

ffa00560:   IF !CC JUMP 0x0xffa00564 <test_func+16> (BP);

ffa00562:   EXCPT 0x3;

ffa00564:   P2 = R3;

ffa00566:   LINK 0x1f40;

 

I was messing it up earlier; I think I got confused with toolchains and what gcc can support on them. For example, if I look at the toolchains listed:

 

bfin-elf     None     newlib     ELF/LDR

bfin-uclinux     Linux     uClibc     FLAT

bfin-linux-uclibc     Linux     uClibc     FDPIC ELF

 

Most of explanations are relative to Linux world, so I get confused if the bfin-elf can support what the FLAT toolchain can support. How can I know generally what options are supported/not in bare metal bfin-elf?

QuoteReplyEditDelete

 

 

2011-05-17 13:14:38     Re: exploring the stack consumption with gcc - baremetal - windows

Mike Frysinger (UNITED STATES)

Message: 100700   

 

if the documentation doesnt say, then you can just try it and see what happens.  i'm not aware of any specific documentation.

QuoteReplyEditDelete

 

 

2011-05-19 11:32:47     Re: exploring the stack consumption with gcc - baremetal - windows

Prasanth Rajagopal (INDIA)

Message: 100751   

 

When I look at the codes, it seems like stack consumption is identified compile-time rather than run-time. I was searching for some related options, and ended up in the following gcc options:

 

-fstack-usage

 

    Makes the compiler output stack usage information for the program, on a per-function basis. The filename for the dump is made by appending `.su' to the AUXNAME. AUXNAME is generated from the name of the output file, if explicitly specified and it is not an executable, otherwise it is the basename of the source file. An entry is made up of three fields:

 

    

 

        The name of the function.

        A number of bytes.

        One or more qualifiers: static, dynamic, bounded.

 

    The qualifier static means that the function manipulates the stack statically: a fixed number of bytes are allocated for the frame on function entry and released on exit; no stack adjustments are otherwise made, except for pushing and popping arguments around function calls. The second field is then an upper bound of the total amount of stack used by the function.

 

    The qualifier dynamic means that the function manipulates the stack dynamically: in addition to the static operations described above, stack adjustments are made in the body of the function. If the qualifier bounded is also present, the amount of these adjustments is bounded at compile-time and the second field is an upper bound of the total amount of stack used by the function. If it is not present, the amount of these adjustments is unbounded at compile-time and the second field only represents the bounded part.

 

    

-fcallgraph-info

    Makes the compiler output callgraph information for the program, on a per-file basis. The information is generated in the VCG format. It can be decorated with additional, per-node information if other debugging options are enabled (only works with -fstack-usage as of this writing).

 

It seems like we dont have it on bfin-elf toolchain. I think a graphical representation of stack usage after compile process would be a great tool. Can this be implemented on Blackfin toolchain?

 

If not, what other method can be employed for compile time stack analysis. The run-time stack check helps me know about violation. How about run a piece of code and collect the stack usage for every function?

QuoteReplyEditDelete

 

 

2011-05-19 11:42:15     Re: exploring the stack consumption with gcc - baremetal - windows

Mike Frysinger (UNITED STATES)

Message: 100755   

 

no, it is done at runtime.  otherwise there wouldnt be any point in generating code in prologue like it does now.  gcc will take the current sp, add the compiled stack requirement for the active func, and compare it to the stack symbol.  if it exceeds, it executes EXCPT.

QuoteReplyEditDelete

 

 

2011-05-19 11:49:54     Re: exploring the stack consumption with gcc - baremetal - windows

Prasanth Rajagopal (INDIA)

Message: 100756   

 

Actually, the same thing - compiled stack requirement. What I meant was this info of stack usage is generated compile time, and then validated run time.

 

ffa00554:   R3 = P2;

ffa00556:   P2.H = 0xffb0;          /* (-80)        P2=0x0xffb00005 */

ffa0055a:   P2.L = 0x1f48;          /* (8008)       P2=0x0xff801f48 */

ffa0055e:   CC = SP < P2;

ffa00560:   IF !CC JUMP 0x0xffa00564 <test_func+16> (BP);

ffa00562:   EXCPT 0x3;

ffa00564:   P2 = R3;

ffa00566:   LINK 0x1f40;

 

If so, isnt there a way to generate statistics of the stack usage compile time. I mean, if it can generate hardcoded instructions, I was wondering - why not a mechanism similar to the above gcc options I mentioned?

QuoteReplyEditDelete

 

 

2011-05-19 12:11:30     Re: exploring the stack consumption with gcc - baremetal - windows

Mike Frysinger (UNITED STATES)

Message: 100757   

 

it's not the same thing.  the code is verifying your stack didnt overflow.  the usage per-func is static, but the sp upon entering the func can be anything.

 

the kernel includes a small tool called checkstack.pl that looks at the LINK sizes and extracts the static stack usage for each function.  i'm not terribly familiar with the other stack options in gcc, so i'd have to play with them first.

QuoteReplyEditDelete

 

 

2011-05-19 12:26:58     Re: exploring the stack consumption with gcc - baremetal - windows

Prasanth Rajagopal (INDIA)

Message: 100758   

 

I got it, sorry I confused you on what I tried to ask. I was just looking at statistical part of generating stack usage.

 

Thanks

QuoteReplyEditDelete

 

 

2011-05-26 14:15:47     Re: exploring the stack consumption with gcc - baremetal - windows

Mike Frysinger (UNITED STATES)

Message: 100876   

 

the -fstack-usage flag is new to gcc-4.6.  it isnt in any old version such as the ones we're shipping via this website.

 

i dont see -fcallgraph-info anywhere, so i dont know where you're finding that.  it's probably a newer option too.

 

you can already get callgraph information now, but not with stack usage.  see the egypt tool (ive used this in the past so i know it works):

http://www.gson.org/egypt/

Attachments

    Outcomes